Minutes IETF105: secevent
minutes-105-secevent-00

Meeting Minutes Security Events (secevent) WG
Title Minutes IETF105: secevent
State Active
Other versions plain text
Last updated 2019-07-23

Meeting Minutes
minutes-105-secevent

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 infinitum
 - Q (Bjorn): is there a reason the claim is "phone" and not "phone_number"?
- 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)

Feedback:
     - 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 duplicate

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