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