[Id-event] Review of Subject Identifiers for Security Event Tokens

[William Denniss <[e-mail]>]

I reviewed Subject Identifiers for Security Event Tokens v05 (
https://tools.ietf.org/html/draft-ietf-secevent-subject-identifiers-05
<https://tools.ietf.org/html/draft-ietf-secevent-subject-identifiers-05#ref-JWT>
).

Summary & Benefits:

The draft standardizes a way to represent the subjects when they may be of
different types (e.g. some with email, some with ID). It does this in a way
that allows the type and the value to be encoded together. JWT by itself
doesn't define the type of subjects (it's defined as a case-sensitive
string containing a StringOrURI value), leaving this to implementers which
works in many situations, but can cause problems for the application of
JWTs as security events. Also included is a way to present multiple
identifiers for the same subject. Standidizing this is relevant in Security
Event Token environments like RISC involving multiple parties where some
mapping of identifiers between the systems is needed. For example, when two
email systems share SETs to mitigate email recovery related risks, one
party might identify users by ID, whereas the other by email address. The
one-size-fits-all typeless "sub" can fall short in this situation.

Traditional use of JWT is unidirectional, with one issuer and multiple
consumers whereby the subject itself can be more or less an opaque index.
The SET application of JWT sees multiple issuers who consume each other's
tokens and need to identify subjects across identity provider boundaries.
Being able to communicate the subject type, as well as potentially multiple
subject identifiers for the same subject is useful in this type of
environment. Using JWT claims without the subject identifier approach
defined in this draft, the issuer may put an opaque value in "sub", and an
email address in "email", but without a way to indicate what the type of
the sub is, or if it's reasonable to use "email" as the subject rather than
just an attribute of the user. This draft allows for multiple subject
identifiers to be communicated as such and removes the guesswork by
consumers as to what should be considered a subject identifier and what
should not.

Feedback:

Abstract:

Nit: I normally see RFC's referred to by number, so rather than "within a
[JSON] object", I would  expect to see "within a JSON [RFC 7159] object".
Same for JWT and SET. I think this style reads better, as it separates the
name of the draft from the reference.

§ 3:

One thing that I feel is missing is an example of a full SET or JWT with
the subject identifier. I'm a big believer in examples, as it gives the
reader an easy way to picture the final application of what is being
specified. Like what we did in RFC 8417, Section 2.1.4:
https://tools.ietf.org/html/rfc8417#section-2.1.4.  There are some
non-normative examples in this draft later for non-SET JWTs, which is
great, so I think it would be useful to have ones for SET as well.

§ 3:

"   A Subject Identifier is a [JSON] object containing a "subject_type"
   claim"

Nit: I'm troubled slightly by the phrase "JSON object containing a claim"
here. In JSON terms, these are key/value pairs not "claims" which is a JWT
term. I think it's fine for the doc to mostly use "claims", since the
context is JWT, but since we're designing a new type here, I'd suggest at
first use to say something like "JSON object with multiple key/value pairs
representing the subject's claims", after which you can just use "claim".

§ 4.1:

Document defines a "sub_id" JWT claim, but it doesn't really explain why or
when to use it.

I think the doc would benefit from an introduction in this section that
talks about why this is a useful construct, and where we expect it to be
used. My understanding is that we expect subject identifiers to be used in
SETs  (e.g. in RISC) and in non-SET JWTs.  It makes sense to me to have a
"pure JWT" option here, and I'm sure it was added for good reason
(including perhaps some that I enumerated in my benefits summary above), I
think it would help to have those reasons listed.

§ 6:

I feel like there are always security considerations :-)

Maybe this could document some of the security considerations of sending
subject as JWT claims without using this spec (e.g. that maybe someone
could rely on a claim more strongly to identify a subject than was
intended).

§ 7:

Just a comment: I agree with the choice of "Expert Review" for IANA.
"Specification Required" would be too heavyweight here.


Best,
William