Re: [Id-event] [UNVERIFIED SENDER] Re: Subject Identifiers - Working Group Last Call

[Yaron Sheffer <[e-mail]>]

Hi Annabelle,

 

I totally accept your two examples, and I suggest you consider including them in the text. But Fig. 14 (quoted below in full) does not clarify this intent IMO.

 

Existing Fig. 14:

 

  {

     "iss": "issuer.example.com",

     "sub": "[e-mail]",

     "sub_id": {

       "format": "email",

       "email": "[e-mail]"

     }

   }

 

Maybe change the “sub” to “[e-mail]” so that readers will understand this is the same person?

 

Thanks,

                Yaron

 

From: "Richard Backman, Annabelle" <[e-mail]>
Date: Saturday, June 12, 2021 at 01:26
To: Yaron Sheffer <[e-mail]>
Cc: Dick Hardt <[e-mail]>, SecEvent <[e-mail]>, Roman Danyliw <[e-mail]>, Marius Scurtescu <[e-mail]>
Subject: Re: [UNVERIFIED SENDER] Re: Subject Identifiers - Working Group Last Call

 

Sorry for the delayed response! 

 

Section 4.1 requires that both `sub` and `sub_id` claims identify the same subject. The only way to enforce that programmatically would be to require them to have the same value. Since the existing `sub` claim is unformatted and generally unconstrained, I don't see how we could do that. Here are a couple examples of cases where that breaks down:

 

I have been using phone numbers for `sub`, but have been omitting country codes because I only operate in the US. I want to migrate to `sub_id`, but the "phone_number" format requires me to prefix my identifiers with "+1".
I'm a client of an IdP, and use the IdP's subject identifier in JWTs sent back to the IdP. To work around the fact that `sub` is a single scalar string, I concatenate the IdP issuer and subject together with a "#", and use that as the `sub` in my tokens, with my issuer as the `iss`. I want to switch to using `sub_id`, using the `iss_sub` format, so the JWT can have my issuer, but the subject can have the IdP's issuer.
—

Annabelle Backman (she/her)

[e-mail]

 

 



On May 27, 2021, at 5:46 AM, Yaron Sheffer <[e-mail]> wrote:

 

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.

 

Thank you Dick and the authors.

 

With my co-chair hat off, I support progressing this document. I also have a couple comments:

 

3.2.2: The text refers twice to "alias" subject IDs, but the format is now named "aliases".

 

Fig. 14 seems to be in conflict with the requirement to have a single subject for the JWT ("a JWT has one and only one JWT Subject"). Yes, maybe Elizabeth has a second email address, but we cannot assume that applications have this kind of logic. Similarly, the subject-related discussion in Sec. 4.2 (which is arguably a bit vague) as well as Fig. 18 seems to allow two different subjects within the JWT.

 

Thanks,

                Yaron

 

From: Dick Hardt <[e-mail]>
Date: Wednesday, May 26, 2021 at 23:22
To: SecEvent <[e-mail]>
Cc: Yaron Sheffer <[e-mail]>, Richard Backman, Annabelle <richanna=[e-mail]>, Roman Danyliw <[e-mail]>, Marius Scurtescu <[e-mail]>
Subject: Subject Identifiers - Working Group Last Call

Hello WG

 

Thanks to Annabelle (and Marius) for the latest update:

 

https://datatracker.ietf.org/doc/html/draft-ietf-secevent-subject-identifiers-08

 

Yaron and I would like to make another working group last call on this draft. We are hopeful there will be enough feedback on this draft from people that have reviewed it for us to recommend the draft progressing to the next step. 

 

Please review and respond if you are supportive of this draft, and if you are not supportive, please clarify your concerns.

 

Dick and Yaron

 

ᐧ