* 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-105 secevent minutes

Session 2019-07-23 1330-1500: Sainte-Catherine - Audio stream - secevent chatroom


minutes-105-secevent-00 minutes

          Security Events (SECEVENT)
          IETF105 Montreal
          July 23, 2019
          Subject Identifiers for Security Event Tokebns
           -- Annabelle Backman
          Goal is to have a lightweight schema for all the different ways to
          uniquely identify a subject
           - spec defines a bunch of these and creates an IANA registry
          issuer/subject type
           - From OIDC
          Draft 4 is published
          in use in OIDF RISC
          Implementations in progress at Google and Amazon
           - interop in progress
          Updates in Draft 4:
              - privacy considerations for identifier correlation
              - prohibit nesting of aliases
           - subject type "aliases" allows multiple identifiers for the same subject
           - allows a single SET to identify a user in different ways
           - eg: iss/sub, email, phone
           - update keeps you from putting "aliases" inside of "aliases" ad
           - Q (Bjorn): is there a reason the claim is "phone" and not
          - A: "phone" is shorter but there's not a compelling reason to keep it
          - Mike: OIDC uses "phone_number"
          - A: That's a good reason to change it...
           - subject identifier in a JWT
           - "sub" is a single string, fine for OIDC but not for complex things
           - "sub_id" is an object that does the same thing as the "sub" claim
           - has to point to the same subject as "sub" if both in there
           - can be listed independently or together
           - don't have to have the same value (different emails for same type)
           - dont' have to have the same type
           - can put an alternate email in the sub_id
           - Correlation between "sub" and "sub_id" is subject to data agreements
           between transmitter and receiver of a SET/JWT
          - regulation of this is outside of scope of spec
            - for example the issuer should only include alternate identifiers if
            it knows it's appropriate for the receiver to get this data
          - issuer of the JWT vs. issuer in sub_id
          - values may or may not be the same
          - possible for a JWT to be issued by one entity but use a subject from
          another entity
          - ex: JWT issued by a client using a subject the client got from an IdP
          (iss_sub type)
               - Brian: "I like it"
               - RISC uses "subject" and not "sub"?
          - A: Claim is within the "event" payload not at "JWT" level, could
          be aligned
          Last call?
          - Mike to review
          - Justin to try to review as long as Annabelle keeps bugging him
          Poll-bsed SET Token Delivery
           - Mike Jones
          New in -03
          - align with push draft, reference push wherever possible instead of
          Last call?
          - Updates to be pushed and WGLC will be called
          New work for the WG?
           - nothing from the room
          If last calls go smoothly, no session anticipated at 106

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