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

From: Justin Richer <[email-masked]>
Date: Fri, 23 Jul 2021 14:31:26 -0400

Hi Chairs et al,

It’s been over a month since the call, and with the IETF meeting next week, is there any update on finalizing this draft and wrapping up SECEVENTS?

Thanks,
 — Justin

> On Jun 28, 2021, at 3:32 PM, Tim Cappalli <Tim.Cappalli=[email-masked]> wrote:
> 
> I agree with the feedback thus far and would support moving this draft forward.
> 
> tim
> From: Id-event <[email-masked]> on behalf of Richard Backman, Annabelle <richanna=[email-masked]>
> Sent: Monday, June 14, 2021 19:30
> To: Yaron Sheffer <[email-masked]>
> Cc: Roman Danyliw <[email-masked]>; Marius Scurtescu <[email-masked]>; SecEvent <[email-masked]>; dick.hardt <[email-masked]>
> Subject: Re: [Id-event] [UNVERIFIED SENDER] Re: Subject Identifiers - Working Group Last Call
>  
>> Maybe change the “sub” to “[email-masked] <mailto:[email-masked]>” so that readers will understand this is the same person?
> 
> That's…such a simple change that would make it much clearer. Brilliant. 😀
> 
> —
> Annabelle Backman (she/her)
> [email-masked] <mailto:[email-masked]>
> 
> 
> 
> 
>> On Jun 13, 2021, at 5:56 AM, Yaron Sheffer <[email-masked] <mailto:[email-masked]>> 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.
>> 
>> 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 <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fissuer.example.com%2F&data=04%7C01%7Ctim.cappalli%40microsoft.com%7C3fe8446a702845aaf05308d92f8c6dd3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637593102475836741%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=RWYa2EC7xjr5gdmY7fruWoQoWxFoImcazmx89G5DHe0%3D&reserved=0>",
>>      "sub": "[email-masked] <mailto:[email-masked]>",
>>      "sub_id": {
>>        "format": "email",
>>        "email": "[email-masked] <mailto:[email-masked]>"
>>      }
>>    }
>>  
>> Maybe change the “sub” to “[email-masked] <mailto:[email-masked]>” so that readers will understand this is the same person?
>>  
>> Thanks,
>>                 Yaron
>>  
>> From: "Richard Backman, Annabelle" <[email-masked] <mailto:[email-masked]>>
>> Date: Saturday, June 12, 2021 at 01:26
>> To: Yaron Sheffer <[email-masked] <mailto:[email-masked]>>
>> Cc: Dick Hardt <[email-masked] <mailto:[email-masked]>>, SecEvent <[email-masked] <mailto:[email-masked]>>, Roman Danyliw <[email-masked] <mailto:[email-masked]>>, Marius Scurtescu <[email-masked] <mailto:[email-masked]>>
>> 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)
>> [email-masked] <mailto:[email-masked]>
>>  
>>  
>> 
>> 
>>> On May 27, 2021, at 5:46 AM, Yaron Sheffer <[email-masked] <mailto:[email-masked]>> 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 <[email-masked] <mailto:[email-masked]>>
>>> Date: Wednesday, May 26, 2021 at 23:22
>>> To: SecEvent <[email-masked] <mailto:[email-masked]>>
>>> Cc: Yaron Sheffer <[email-masked] <mailto:[email-masked]>>, Richard Backman, Annabelle <richanna=[email-masked] <mailto:richanna=[email-masked]>>, Roman Danyliw <[email-masked] <mailto:[email-masked]>>, Marius Scurtescu <[email-masked] <mailto:[email-masked]>>
>>> 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 <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-secevent-subject-identifiers-08&data=04%7C01%7Ctim.cappalli%40microsoft.com%7C3fe8446a702845aaf05308d92f8c6dd3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637593102475846699%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=EBKyE%2FtQwizQcD%2F3ro498WxiDN%2B27zAZI0c4XpxM7iw%3D&reserved=0>
>>>  
>>> 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
>>>  
>>> ᐧ
>> 
>>  
>> _______________________________________________
>> Id-event mailing list
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/id-event <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fid-event&data=04%7C01%7Ctim.cappalli%40microsoft.com%7C3fe8446a702845aaf05308d92f8c6dd3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637593102475846699%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=XsqzEQKNPxTP%2BNYytAN8zKdlVbPrk7bByv%2Br7jLLLLs%3D&reserved=0>
> _______________________________________________
> Id-event mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/id-event

---

From: Dick Hardt <[email-masked]>
Date: Fri, 23 Jul 2021 12:20:54 -0700

I think we are waiting for the SSE people to provide additional feedback
per Annabelle's last email. and then for a new draft to be published that
would address any of that feedback, and the feedback already provided.
ᐧ

On Fri, Jul 23, 2021 at 11:31 AM Justin Richer <[email-masked]> wrote:

> Hi Chairs et al,
>
> It’s been over a month since the call, and with the IETF meeting next
> week, is there any update on finalizing this draft and wrapping up
> SECEVENTS?
>
> Thanks,
>  — Justin
>
> On Jun 28, 2021, at 3:32 PM, Tim Cappalli <
> Tim.Cappalli=[email-masked]> wrote:
>
> ------------------------------
> *From:* Id-event <[email-masked]> on behalf of Richard
> Backman, Annabelle <richanna=[email-masked]>
> *Sent:* Monday, June 14, 2021 19:30
> *To:* Yaron Sheffer <[email-masked]>
> *Cc:* Roman Danyliw <[email-masked]>; Marius Scurtescu <
> [email-masked]>; SecEvent <[email-masked]>; dick.hardt <
> [email-masked]>
> *Subject:* Re: [Id-event] [UNVERIFIED SENDER] Re: Subject Identifiers -
> Working Group Last Call
>
>
> Maybe change the “sub” to “[email-masked]” so that readers will
> understand this is the same person?
>
>
> [email-masked]
> On Jun 13, 2021, at 5:56 AM, Yaron Sheffer <[email-masked]> 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.
>
> 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
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fissuer.example.com%2F&data=04%7C01%7Ctim.cappalli%40microsoft.com%7C3fe8446a702845aaf05308d92f8c6dd3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637593102475836741%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=RWYa2EC7xjr5gdmY7fruWoQoWxFoImcazmx89G5DHe0%3D&reserved=0>
> ",
>      "sub": "[email-masked]",
>      "sub_id": {
>        "format": "email",
>        "email": "[email-masked]"
>      }
>    }
>
> Maybe change the “sub” to “[email-masked]” so that readers will
> understand this is the same person?
>
> Thanks,
>                 Yaron
>
> *From: *"Richard Backman, Annabelle" <[email-masked]>
> *Date: *Saturday, June 12, 2021 at 01:26
> *To: *Yaron Sheffer <[email-masked]>
> *Cc: *Dick Hardt <[email-masked]>, SecEvent <[email-masked]>,
> Roman Danyliw <[email-masked]>, Marius Scurtescu <
> [email-masked]>
> *Subject: *Re: [UNVERIFIED SENDER] Re: Subject Identifiers - Working
> Group Last Call
>
> 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:
>
>
>    1. 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".
>    2. 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.
>
> —
> [email-masked]
> On May 27, 2021, at 5:46 AM, Yaron Sheffer <[email-masked]> 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.
>
> 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 <[email-masked]>
> *Date: *Wednesday, May 26, 2021 at 23:22
> *To: *SecEvent <[email-masked]>
> *Cc: *Yaron Sheffer <[email-masked]>, Richard Backman, Annabelle <
> richanna=[email-masked]>, Roman Danyliw <[email-masked]>,
> Marius Scurtescu <[email-masked]>
> *Subject: *Subject Identifiers - Working Group Last Call
> Hello WG
>
> https://datatracker.ietf.org/doc/html/draft-ietf-secevent-subject-identifiers-08
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-secevent-subject-identifiers-08&data=04%7C01%7Ctim.cappalli%40microsoft.com%7C3fe8446a702845aaf05308d92f8c6dd3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637593102475846699%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=EBKyE%2FtQwizQcD%2F3ro498WxiDN%2B27zAZI0c4XpxM7iw%3D&reserved=0>
>
> 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
>
> ᐧ
>
>
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fid-event&data=04%7C01%7Ctim.cappalli%40microsoft.com%7C3fe8446a702845aaf05308d92f8c6dd3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637593102475846699%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=XsqzEQKNPxTP%2BNYytAN8zKdlVbPrk7bByv%2Br7jLLLLs%3D&reserved=0>
>
>