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

From: William Denniss <[email-masked]>
Date: Mon, 20 Jul 2020 14:55:53 -0700

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

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Mon, 20 Jul 2020 22:50:22 +0000

Thank you for the review, William. No inline comments or questions from me, as I agree with all of your feedback. :)

–
Annabelle Backman (she/her)
AWS Identity
https://aws.amazon.com/identity/

From: Id-event <[email-masked]> on behalf of William Denniss <wdenniss=[email-masked]>
Date: Monday, July 20, 2020 at 2:56 PM
To: ID Events Mailing List <[email-masked]>
Subject: [EXTERNAL] [Id-event] Review of Subject Identifiers for Security Event Tokens

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.

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:

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:

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