Minutes IETF103: secevent
minutes-103-secevent-00
| Meeting Minutes | Security Events (secevent) WG | |
|---|---|---|
| Title | Minutes IETF103: secevent | |
| State | Active | |
| Other versions | plain text | |
| Last updated | 2018-11-11 |
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!