Minutes IETF104: secevent
minutes-104-secevent-00

SECEVENT Wednesday 0900-1100

Yaron Sheffer (Intuit, WG chair) convened the meeting at 9:04 a.m.

The interim meeting was cancelled because authors could not attend.  WGLC for
Push Delivery did not receive sufficient responses to claim consensus.  So, the
document is back to the WG for discussion of the way forward.

Annabelle Backman (Amazon) on Push-based SET Token Delivery.  Push is used for
a delivering SET Transmission Requests via HTTP.  The -04 draft was published
in January with a following WGLC not receiving enough input to claim WG
consensu.  A -05 draft has been published.  Implementations from Google and
Amazon exist in varying states.  Changes that have been made to the protocol
since the -03 draft: 1) description of validation has been clarified: the SET
recipient must validate that it is willing to receive SETs from the SET issuer
and from the transmitting SET Transmitter; 2) redefined some of the error codes
(invalid_request, invalid_key, authentication_failed, access_denied); 3)
clarifications around Accept-Language and Content-Language for error cases; 4)
allow TLS 1.2 and later versions (formerly this said TLS 1.2 only).  There were
no comments from the floor.  Review of the draft is needed!

Annabelle Backman on Subject Identifiers for Security Event Tokens.  As
background, Backmann explained what a Subject Identifier is.  The -03 draft was
published two weeks ago.  Google and Amazon are both implementing the draft. 
Updates made since the -02 draft include: 1) added account URI subject_type; 2)
replaced id_token_claims with aliases to provide a similar multiple identifiers
capability; 3) added discussion of email canonicalization (which is not handled
within this specification); 4) semantics clarifications.  One open item: using
a JTW claim for representing the subject via Subject Identifier has been
suggested instead of the sub claim, which is a simple string - is this
applicable to SET?  John Bradley (Yubico) noted that this need has come up in
other contexts, so it's probably useful here.  Ben Kaduk (Akamai, relevant
Security Area Director): what happens when a JWT claim and a sub claim are both
present - how do they take precedence, and why would you send both?  Sheffer:
this would be handy because the subject doesn't always know what identifier the
recipient prefers at the moment.  I don't like defining it by syntax vs.
semantics - we need to define the semantics as well.  Backmann: JWTs define
these as a string, so we might need to define a new claim instead.  Bradley:
this is kind of an alias, so it's not mutual exclusive to a sub claim. 
Backmann: in the event both are present, they must identify the same principal.
 As long as that's the case, there shouldn't be too much confusion over
processing and precedence.  Kaduk: different topic (aliases): Are there privacy
considerations with exposing varying different identifiers together?  Backmann:
the transmitter should be careful not to communicate information to which the
recipient should not be privy.  The subject identifier can be perceived as
sensitive information; there's guidance about this in the current draft. 
Sheffer: Ben, if you have more specific language to tune this topic in the
draft, please send it.

Mike Jones (Microsoft) on Poll-based SET Token Delivery Using HTTP.  The draft
defines a polling delivery mechanism for SETs for when you can't accept push
delivery of SETs.  Both push and poll can be used non-exclusively.  Since the
last meeting, the draft has been updated: 1) language improvements that align
with the base SET RFC (8417); 2) removed dependency between the semantics of
maxEvents and returnImmediately (this change should not affect any current
implementation); 3) now does not require TLS, but says that some encryption
should be used in the presence of PII.  The Poll draft is dependent on the Push
draft, so both need to move forward.  The Poll draft should be ready for WGLC. 
Note, Adobe has a Push implementation in deployment.  There really ought to be
more feedback on Push at this point, and perhaps others could do a review based
on their own experiences.  Sheffer: Are there implementations of Poll?  Tony
Nadalin: we are using this within Microsoft, for directory synchronization,
etc.  Sheffer: please add an implementation status section to the draft.  You
mentioned encryption requirements.  Are these in sync between Push and Poll? 
Backmann: almost - TLS version requirement language needs to be aligned. 
Jones: agreed.

Sheffer: are there other ideas for moving the Push draft forward.  Another WGLC
with few responses would not be a good thing.  The WG is empowered to declare
the work ready for publication, but are there good ways to do this that won't
receive pushback?  Kaduk: the chairs have the discretion to call consensus, as
long as they don't do something really crazy.  We are open to suggestions on
what the WG can do to demonstrate consensus.  Jones: other WGs have used the
face-to-face time of a meeting to draft volunteers into doing reviews.  There
might be some in the room who can be put on the spot to do skim reviews.  Like
Tony Nadalin.  Backmann: I would be curious to know if there are people in the
WG who have reviewed the draft and did not comment on the WGLC because they had
no comments.  Sheffer: Are there those who think the draft is not ready or
should not be published?  Bradley: I read it, found no issues, and was too lazy
to say so on the list.  Sheffer: could you chime in on the mailing list with a
+1 for publication before the end of this session?  Kaduk: maybe twist some
arms of those who have implemented it and see if they can comment.  Sheffer:
and I wouldn't worry about multiple people from the same organization chiming
in.  Jones: Adam Dawes (Google) says they are using it.  Sheffer: No one from
Adobe has chimed in.  Jones: does anyone know who the Adobe contact is?  I can
ping the RISC group about this.  Sheffer: it's not a problem if someone who is
not a regular says something on the list.  Let's try within the next two weeks
or so to get enough people to comment on the draft.  Backmann: to clarify, is
this for Push, Poll, or both?  Sheffer: Push.  Bradley: Google has this in
production.

Sheffer: back to the Poll protocol.  Any opinions on moving this to WGLC? 
Nadalin: I think it's ready for WGLC - it actually works and is deployed. 
Backmann: my only question is whether we have interoperable implementations -
is it all within Microsoft or with other partners.  Nadalin: we have partners,
but I can't disclose who they are.  Sheffer: I think we should actually wait
until we have closure on Push before calling WGLC on Poll, so I would prefer to
wait for the couple weeks we are taking input on Push.  Jones: I kind of
disagree procedurally.  I think we can get both, otherwise we might lose a
forcing function to get people to comment on Poll.  Sheffer: nothing stops them
from reviewing both if they are interested.  And informal Poll reviews could
count towards the actual WGLC.  Nadalin: I'd like to see WGLC on both now. 
Kaduk: No strong opinion, but it's sometimes convenient to review related
documents together so they can go to IETF LC together due to their
relationship.  Sheffer: speaking for the chairs, we will hold Poll but target
WGLC before the next IETF meeting.  I do hope to get Push to publication in the
next month and then move forward with Poll.

The meeting was adjourned at 9:41 a.m.