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.