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

[Denis <[e-mail]>]

Hello Annabelle,

I am glad to be able to exchange with you for the very first time.

I am currently rather busy and I don't have the time available for a 
detailed response.

Nevertheless, I browsed through your comments and I picked one of them:

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

    I'm not sure I'm following what you're intending to represent with
    this, and what problem you're trying to solve.

Last August, I have posted a draft, that has expired, but that you can 
still find at:

    https://datatracker.ietf.org/doc/html/draft-pinkas-gnap-core-protocol-00.html

If you have some time available, please take a look at section 1.7. 
called "Short term and long term user accounts",
where you will get some information. In particular, the following text.

The four types used in the context of long-term user accounts managed by a RS are:

          (1) a unique user identifier used to identify a user for each User/ RS pair, or

              Note: this option cannot be implemented in the context of a "software-only" solution.
                    It requires the use, by the end-user, of a secure element with specific security
                    properties.  [This option is not detailed any further at the moment].

          (2) a unique user identifier used to identify a user for each AS / RS pair, or

          (3) a locally unique user identifier used to identify a user whatever RS is being involved, or

          (4) a globally unique user identifier.

    The last type used in the context of short-term user accounts managed by a RS is:

          (5) a short-term user unique identifier.

It would be valuable to be able to make a difference between these five 
types of user identifiers.

_Note_: the draft has been posted a few months after my original 
comment, hence at the time I made my original post
            my ideas where not yet fully stabilized. Now, they are !

Denis


>> On Mar 9, 2022, at 9:31 AM, Denis <[e-mail]> wrote:
>> ...
>>> 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".
>
> The draft formalizes the concept of a "Subject Identifier", and 
> provides a standard way to represent those as structured data. 
> Therefore I think the current name remains appropriate.
>
>>> *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.
>>>
> Whether or not a subject is an individual or group is a property of 
> the subject itself, not (generally speaking) a property of the subject 
> identifier. Subject identifiers are not general purpose containers for 
> claims about a subject – we already have JWTs for that. 😀
>
> Certainly there are systems out there that issue identifiers for 
> individuals (i.e., users) and groups that may collide with one another 
> (e.g., any system that uses 0-based SQL auto-incrementing integers for 
> its identifiers). However, I think it is rare for such identifiers to 
> be used in cases where interoperability is important, and where the 
> type of the subject is not made clear from context (e.g., a 
> "GetGroupMembers" API would expect an identifier for a group, not a 
> user). Further, I suspect any such system that did need to 
> disambiguate between individuals and groups within the identifier 
> itself would likely need to disambiguate between other types of 
> subjects as well, e.g., hosts, documents, various resources provided 
> by the service, etc. As such, this proposal would not solve their 
> problem, and they would be better off defining their own subject 
> identifier format for their use case.
>
>
>>> *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.
>
> The Privacy Considerations section is intended to address the 
> correlation risk generally. The JWT case is mentioned only as an 
> example. Any suggestions on how to make that more clear?
>
>>> 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*.
>
> I'm not sure I'm following what you're intending to represent with 
> this, and what problem you're trying to solve. Any subject identifier 
> transmitted from one party to another is by definition "shared". Once 
> the recipient receives that identifier, the transmitter has no 
> programmatic control over how it is used – that's the realm of /legal/ 
> contracts, not API contracts.
>
> A transmitter that wishes to prevent Recipient A from using the 
> transmitters subject identifiers to correlate records with Recipient B 
> may be able to do so by issuing directed identifiers that are unique 
> per subject+recipient pair. A system that does so is essentially 
> immune to this correlation risk; it is not clear to me what value 
> there is in advertising this fact within the subject identifier.
>
>>> *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*):
>
> Hierarchical groups and functional groups are both subject types, not 
> subject identifier types. I can imagine something like a `path` 
> subject identifier format that contains an ordered list of scalar 
> values describing a path within a graph. That graph could be a 
> filesystem directory tree, an org chart, a computer network, etc.
>
> It might look something like:
>
>     {
>
>       "format": "path",
>
>       "path": ["usr", "local", "bin", "sha512sum"]
>
>     }
>
>
>     or
>
>
>     {
>
>       "format": "path",
>
>       "path": ["Example University", "Faculty", "Computer Science",
>     "Ada Lovelace"]
>
>     }
>
>
> Note that the nature of the graph, and whether or not the subject 
> identifier identifies the entire path itself or just the final node 
> would depend on the context in which the identifier appears.
>
> While it is an interesting thought exercise, unless someone has a use 
> case for this kind of subject identifier format I don't think it 
> should go in this draft. It can always be defined by someone later, if 
> needed.
>
> —
> Annabelle Backman (she/her)
> [e-mail]
>
>
>
>
>> On Mar 9, 2022, at 9:31 AM, Denis <[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.
>>
>>
>> Dick,
>>
>> As a response to your inquiry, I repost the original email sent on 
>> 27/05/2021 at 19:42 (Paris local time) to the same recipients.
>>
>> Denis
>>
>>
>>> 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":"[e-mail]"
>>>
>>> "format": "email",
>>> "class": "grp"
>>> "email":"[e-mail]"
>>> *
>>> *
>>> *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. Suchsubject 
>>> identifiertype 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 sharedidentifiertype (*shared*) to indicate a subject
>>>         identifier shared by severalservice providers
>>>                 (suchsubject identifiertype allows service providers
>>>         to link their accounts), or
>>>
>>>         -a unique identifier type (*unique)*to indicate a subject
>>>         identifier specific to asingle service provider
>>>                 (suchsubject identifiertype 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).
>>>         (suchsubject identifiertype 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/",
>>> "sub": "145234573"
>>>
>>> "format": "iss_sub",
>>> "type": "unique"
>>> "iss":"http://issuer.example.com/",
>>> "sub": "145234573"
>>>
>>> "format": "opaque",
>>> "type": "tmp"
>>> "id": "11112222333344445555"
>>>
>>> *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"
>>>
>>>
>>> *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
>>>
>>>> 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
>>>> Image removed by sender.ᐧ
>>>>
>>>> _______________________________________________
>>>> Id-event mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/id-event
>>>
>>>
>>
>> _______________________________________________
>> Id-event mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/id-event
>