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

From: Dave Tonge <[email-masked]>
Date: Thu, 3 Jun 2021 10:15:24 +0200

I support progressing this document forward.

On Thu, 27 May 2021 at 14:46, Yaron Sheffer <[email-masked]> wrote:

> 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]>
> *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
>
>
>
> 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
>
>
>
> ᐧ
> _______________________________________________
> Id-event mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/id-event
>

-- 
Dave Tonge
CTO
<http://www.google.com/url?q=http%3A%2F%2Fmoneyhubenterprise.com%2F&sa=D&sntz=1&usg=AFQjCNGUnR5opJv5S1uZOVg8aISwPKAv3A>
t: +44 (0)117 280 5120

Moneyhub Enterprise is a trading style of Moneyhub Financial Technology
Limited which is authorised and regulated by the Financial Conduct
Authority ("FCA"). Moneyhub Financial Technology is entered on the
Financial Services Register (FRN 809360) at fca.org.uk/register.
Moneyhub Financial
Technology is registered in England & Wales, company registration number
06909772 .
Moneyhub Financial Technology Limited 2018 ©

DISCLAIMER: This email (including any attachments) is subject to copyright,
and the information in it is confidential. Use of this email or of any
information in it other than by the addressee is unauthorised and unlawful.
Whilst reasonable efforts are made to ensure that any attachments are
virus-free, it is the recipient's sole responsibility to scan all
attachments for viruses. All calls and emails to and from this company may
be monitored and recorded for legitimate purposes relating to this
company's business. Any opinions expressed in this email (or in any
attachments) are those of the author and do not necessarily represent the
opinions of Moneyhub Financial Technology Limited or of any other group
company.

-- 

Moneyhub Enterprise is a trading style of Moneyhub Financial Technology 
Limited which is authorised and regulated by the Financial Conduct 
Authority ("FCA"). Moneyhub Financial Technology is entered on the 
Financial Services Register (FRN 809360) at https://register.fca.org.uk/ 
<https://register.fca.org.uk/>. Moneyhub Financial Technology is registered 
in England & Wales, company registration number 06909772. Moneyhub 
Financial Technology Limited 2020 © Moneyhub Enterprise, Regus Building, 
Temple Quay, 1 Friary, Bristol, BS1 6EA. 

DISCLAIMER: This email 
(including any attachments) is subject to copyright, and the information in 
it is confidential. Use of this email or of any information in it other 
than by the addressee is unauthorised and unlawful. Whilst reasonable 
efforts are made to ensure that any attachments are virus-free, it is the 
recipient's sole responsibility to scan all attachments for viruses. All 
calls and emails to and from this company may be monitored and recorded for 
legitimate purposes relating to this company's business. Any opinions 
expressed in this email (or in any attachments) are those of the author and 
do not necessarily represent the opinions of Moneyhub Financial Technology 
Limited or of any other group company.

---

From: Justin Richer <[email-masked]>
Date: Thu, 3 Jun 2021 15:40:02 -0400

I support this draft moving forward.

 — Justin

> On May 26, 2021, at 4:22 PM, Dick Hardt <[email-masked]> wrote:
> 
> Hello WG
> 
> https://datatracker.ietf.org/doc/html/draft-ietf-secevent-subject-identifiers-08 <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
> 
> ᐧ

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Fri, 11 Jun 2021 21:36:19 +0000

Apologies for the delayed response to this! Responses inline.

—
Annabelle Backman (she/her)
[email-masked]<mailto:[email-masked]>

On May 27, 2021, at 10:42 AM, Denis <[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.

I believe that this document should be enhanced on three aspects that are currently not addressed.

Section 3.1 (Identifier Formats versus Principal Types) states:
Identifier Formats define how to encode identifying information for a subject.  They do not define the type or nature of the subject itself.
 While this statement is correct, it should be remembered that the title of this document is:

" Subject Identifiers for Security Event Tokens"

and is not:

" Subject Identifiers Formats for Security Event Tokens".

Therefore it would be possible to add optional attributes/characteristics to Subject Identifiers which relate to two different topics:

-          the granularity of the identification and
-          the correlation operations that may be either performed or prevented using some values contained in a specific format.

1. Granularity of the identification

A subject identifier may be able to identify an entity either individually or as a member of a group.

In order to be able to make the difference, an optional class attribute should be defined which may take one out of two values:

  *   "ind" to indicate an individual identifier or
  *   "grp" to indicate a group identifier.

Examples:

 "format": "email",
     "class": "ind"
     "email": "[email-masked]"<mailto:[email-masked]>

"format": "email",
     "class": "grp"
     "email": "[email-masked]"<mailto:[email-masked]>

[richanna]
This seems like it should be a claim about the subject, rather than a part of the identifier. It only needs to be part of the identifier if it is necessary in order to sufficiently identify the subject given the context.
[/richanna]

2. Correlation operations that may be either performed or prevented

Currently, the Privacy Considerations section only addresses one correlation case where a JWT would have both "sub" and "sub_id" JWT claims.
While it is appropriate to mention such a case, other correlation cases exist.

These cases become visible if the "sub_id" contains an optional subject identifier type attribute.

A subject identifier type attribute would be able to support four values: guid, shared, unique and tmp.

-          a guid type indicates a globally unique identifier. Such subject identifier type allows service providers or other servers to link their accounts
        as soon as they use the same guid.

-          an issuer and subject pair (i.e. a subject identifier with the iss_sub format) where the subject identifier format would include :
-          a shared identifier type (shared) to indicate a subject identifier shared by several service providers
        (such subject identifier type allows service providers to link their accounts), or

-          a unique identifier type (unique) to indicate a subject identifier specific to a single service provider
        (such subject identifier type does not allow service providers or servers to link their accounts), or
-          a temporary identifier type (tmp) to indicate a subject identifier issued only once by the issuer (sometimes called session identifier).
        (such subject identifier type does not allow any service provider to perform any linkage between accounts, even on a single service provider). .

Examples:

"format": "opaque",
     "type": "guid"
     "id": "11112222333344445555"

"format": "iss_sub",
     "type": "shared"
     "iss": "http://issuer.example.com/"<http://issuer.example.com/>,
     "sub": "145234573"

"format": "iss_sub",
     "type": "unique"
     "iss": "http://issuer.example.com/"<http://issuer.example.com/>,
     "sub": "145234573"

"format": "opaque",
     "type": "tmp"
     "id": "11112222333344445555"

[richanna]
Are there use cases in which an event processor would behave differently based on this value?
[/richanna]

3. Hierarchical group memberships, functional group memberships and roles.

Examples of group identifiers are : hierarchical group memberships, functional group memberships and roles.
It would be useful to define one format for these common groups: one or more character strings separated by the character slash.
for both hierarchical (hgrp) and functional group memberships (fgrp) and roles (role):

Examples:

"format": "hgrp",
     "hgrp": "marketing/customer relationships"

"format": "fgrp",
     "fgrp": " university/science/teacher"

"format": "role",
     "role": "auditor"

[richanna]
These seem like principal types to me, not identifier formats.
[/richanna]

4. Two nits:
   (...) ways. (e.g., a host might be identified by an IP or MAC address,
   while a user might be identified by an email address) Furthermore,
The punctuation point should be moved after the closing parenthesis.
7.1.  Confidentiality and Integrity

   This specification does not define any mechanism for ensuring the
   confidentiality or integrityi of a Subject Identifier.
Change "integrityi" into "integrity".

Denis

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

Dick and Yaron

[Image removed by sender.]ᐧ

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

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Fri, 11 Jun 2021 22:26:42 +0000

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:

  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.

—

On May 27, 2021, at 5:46 AM, Yaron Sheffer <[email-masked]<mailto:[email-masked]>> wrote:

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

Dick and Yaron

---

From: Yaron Sheffer <[email-masked]>
Date: Sun, 13 Jun 2021 15:56:24 +0300

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": "[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

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.
—

[email-masked]

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

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

Dick and Yaron

ᐧ

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Mon, 14 Jun 2021 23:30:24 +0000

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. 😀

—

On Jun 13, 2021, at 5:56 AM, Yaron Sheffer <[email-masked]<mailto:[email-masked]>> wrote:

Hi Annabelle,

Existing Fig. 14:

  {
     "iss": "issuer.example.com<http://issuer.example.com/>",
     "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

—

Thanks,
                Yaron

Dick and Yaron

---

From: Tim Cappalli <[email-masked]>
Date: Mon, 28 Jun 2021 19:32:28 +0000

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

—

Hi Annabelle,

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]>"
     }
   }

Thanks,
                Yaron

—

Thanks,
                Yaron

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>

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>