Subject: [Id-event] Review of draft-ietf-secevent-subject-identifiers-05

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Fri, 10 Jul 2020 23:57:34 +0000

I’ve reviewed the current draft, and have a few novel comments/topics for discussion that haven’t been raised already by other reviewers:

  1.  Should we remove “for Security Event Tokens” from the title? Nothing about the spec is specific to SETs or even JWTs, except perhaps the definition of “subject”. It’s telling that while the abstract and introduction would need to be reworked, the rest of the text would not require any changes.

  2.  Section 4: Add context for why “sub_id” is needed, given that “sub” already exists. I.e., “sub” is a single string value so cannot represent complex subject identifiers.

  3.  Section 4.2: Clarify that the “iss” property of the Subject Identifier is REQUIRED regardless of whether its value is the same as the JWT’s “iss” claim.

  1.  Section 4.2: Is there a use case where the “iss” may be the same for the JWT and Subject Identifier, but “sub” may be different? More importantly, is there a reason why this would need to be prohibited?

  1.  Section 6: Call out that Subject Identifiers do not provide any mechanism for insuring confidentiality and/or integrity protection, and thus rely on the mechanisms offered by the containing formats and/or protocols within which they are used.

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

---

From: Phillip Hunt <[email-masked]>
Date: Fri, 10 Jul 2020 17:48:55 -0700

In line. 

Phil

> On Jul 10, 2020, at 4:57 PM, Richard Backman, Annabelle <richanna=[email-masked]> wrote:
> 
> 
> Should we remove “for Security Event Tokens” from the title? Nothing about the spec is specific to SETs or even JWTs, except perhaps the definition of “subject”. It’s telling that while the abstract and introduction would need to be reworked, the rest of the text would not require any changes.

This spec was supposed to solve the “sub” ambiguity problem for set and jwt. And the issue of collision around “iss” which is supposed to be the issuer of the SET. 

Opening the scope beyond that would delay finalizing this draft as broader considerations and need discussion. 
> 
> Section 4: Add context for why “sub_id” is needed, given that “sub” already exists. I.e., “sub” is a single string value so cannot represent complex subject identifiers.
Agreed. This needs more clarification. I remain concerned about duplication and interop issues. 
> 
> Section 4.2: Clarify that the “iss” property of the Subject Identifier is REQUIRED regardless of whether its value is the same as the JWT’s “iss” claim.

This is a serious problem is the “iss” of the set is not the “iss” of “sub”. I thought that was why we wanted a json object expression. 

This was also why way back when when i published the original draft proposal that I proposed sub and iss be embedded in the payload so as not to be confused by top level claims which are about the container (ie set) “message”. 
>  
> Section 4.2: Is there a use case where the “iss” may be the same for the JWT and Subject Identifier, but “sub” may be different? More importantly, is there a reason why this would need to be prohibited?
See above.
>  
> Section 6: Call out that Subject Identifiers do not provide any mechanism for insuring confidentiality and/or integrity protection, and thus rely on the mechanisms offered by the containing formats and/or protocols within which they are used.
>  
> –
> _______________________________________________
> Id-event mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/id-event

---

From: Yaron Sheffer <[email-masked]>
Date: Sat, 11 Jul 2020 11:50:13 +0300

Fully agree with Phil about the scope. If some other spec wants to reuse this document, they can refer to it after ensuring that this solution is appropriate for them. But let’s not try to boil the ocean with this draft.

Thanks,

                Yaron

From: Id-event <[email-masked]> on behalf of Phillip Hunt <[email-masked]>
Date: Saturday, July 11, 2020 at 03:49
To: "Richard Backman, Annabelle" <richanna=[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Id-event] Review of draft-ietf-secevent-subject-identifiers-05

In line. 

Phil

 

–

AWS Identity

_______________________________________________ Id-event mailing list [email-masked] https://www.ietf.org/mailman/listinfo/id-event