Minutes IETF103: secevent
minutes-103-secevent-00

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!