IETF 103 Bangkok, SECEVENTS Chairs: Dick Hardt (DH), Yaron Sheffer (YS) Notes: Leif Johansson, with later edits by Yaron * Annabelle Backman (AB) presents Subject Identifiers for Security Event Tokens - Discussion about new definitions of email, phone, iss-sub - Leif Johansson (LJ) at mic: semantic less clear for phone: SMS vs. phone call - Ben Kaduk (BK): identifier may refer to a group, or an unspecified member of the group - Mike Jones (MJ) missing the acct: uri scheme which overlaps with the email semantics - replace email with acct: semantics, gives Twitter as an example, where you need to represent a user name [Edit: RFC 7565] - AB & chair: why replace ? - MJ: add a type acct: - DH: email & phone can often represent entites other than users, e.g. a company - MJ: is phone canonicalized? - AB: yes (E.164 notation) - DH: focus on semantics for email, phone, iss-sub - AB: the proposed new semantics shifts focus to how the values relate to the data subject - MJ: prefer "identified" over "communicate with" - will write to list, "subject is identified with the identifier". - BK: clarification on acct: - MJ: I am probably wrong on that point - YS: original semantic *wording* is better. Some people use Twitter for account verification. Unique identification is not a goal - send all identifiers, the receiver will decide what to do with the claims. - AB: should remove the "unique" word. - Torsten Loddersted (TL): email is both an identifier and an address. uniqueness as identifier is typically true. keep "uniquely identifies" please - TL: old defns are too specific. new definition should say email identifies and can be used to communicate with the data subject. An email address may be an alias to a user account. - YS: receiver may want to know about as much information as possible about a data subject even if not globally unique - DH: these are globally unique identifiers, but may not be unique to the subject. - AB: will work on the list. Like the idea of "identified with". - AB presents on suporting multiple identifiers, propose introduce aliases construct - Justin Richer (JR) (remote): is there an implied preferred order? - AB: all refer to the same data subject (no particular hierarchy, despite the word "aliases" being used) - JR: could this have been a parameter added to all subject types? - AB: this would result in a primary/secondaries... - JR: typically people are looking to have a primary identifier as well as secondary aliases that all refer to it. - DH: makes some point about openidc... - JR: lets be very careful about naling down semantics - three alternatives: aliases, equivalents, options (also: "alternatives") - CONCLUSION: settle naming on list - Email canonicalization - AB: Canonicalize? How? - Lucy Lynch (LL): role based accounts (eg abuse@) may not be canonical? - AB: eg not a canonical identifier for a mailbox - AB: concerned about canonicalized the expression of the email address - MJ: need better specification of email address - RFC2821 has multiple valid formats, possibly lowercase hostname - AB: currently AddressSpec from the RFC. - DH: most systems canonicalize in some way - MJ: if you try to impose general rules, this is a rathole. - (multiple): interest in canonicalization? - MJ: let's put non-normative language about why this is hard - BK: there be dragons - canonicalizing json is one issue, RFC5321/5322 abnf for domain-part includes i18n which adds lots of issues. not in scope for this WG - AB: add non-normative text - YS: is this important to implementers? Specifically, do we need email address hashing, which would require canonicalization. - Brett Jordan: maybe start the process of fixing the issues instead of punting on them. - MJ: we don't need canonicalization to sign JWTs - AB: lack of canonicalization does introduce its own issues - may rely on hashing & separate type - CONCLUSION: add non-normative text, no canonicalization specified - Other issues? - Brian Campbell (BC): no type for subject:... why? - AB: subject claim is defined but no JWT claim for "subject identifier" - AB a JWT level claim introuces issues ... bring up on list, might not play well with existing issuer-sub - DH: subject is used in other contexts for eg subscriptions, introduce possible confusion - BC: will raise on list, might want guidance on usage. - AB: possible value in specifying a standard claim type. - Push based SET token delivery using HTTP - AB summarizes draft - Open Issues - are there a list of JWT errors vs SET errors? - YS: this looks like bikeshedding, need to define error code, don't care which ones so long as they are generally applicable - YS: also add language tag to description (but no need for multiple languages) [Edit: requirement in RFC 2277] - MJ: should probably collapse number of errors into a smaller set. - MJ: errors are ok to define in the SET protocol - keep error definitions in the context of SET - BC: my parser will just throw parser exceptions, no easy (programmatic) access to why things fail. the description field is sufficient for developer work, and very general error codes. - BK: question if secevents is the right place to define JWT errors. only relevant if there are some interop needs which doesn't seem to exist - MJ: there are no error definitions in the JWT spec - MJ: oauth got this right: small number of error codes combined with text description field - AB: clarify that Description field is not prescriptive - YS: should be demonstrated by examples in the spec. - CONCLUSION: define what is needed in the WG, no need to consider other WGs, consider oauth as a model - CONCLUSION: move to WGLC * Mike Jones (MJ) on Poll-Based SET Token delivery using HTTP - MJ summarizes draft and changes since -00 - MJ overview of changes expected for the next version - focus on semantic "oddities" - MJ: more review needed esp of PUSH draft and the semantics of data structures in the PULL draft now pls - DH asking for volunteers to review PULL draft: Syed Sayyad * DH: will probably hold a virtual interim before Prague. * YS calls for new work to be considered in time for Prague or the WG will be done shortly after Prague - BK: close is good! * Wrap up!