* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Secevent Status Pages

Security Events (Active WG)
Sec Area: Roman Danyliw, Benjamin Kaduk | 2016-Oct-28 —  

IETF-104 secevent minutes

Session 2019-03-27 0900-1100: Berlin/Brussels - Audio stream - secevent chatroom


minutes-104-secevent-00 minutes

          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.

Generated from PyHt script /wg/secevent/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -