FYI: Forwarding this email to the list so that we can continue the conversation here.
Below, I am trying to find out whether there is room for improvement on the text regarding the uniqueness of the “sub” claim. Ciao Hannes From: Denis <denis.i...@free.fr> Sent: Thursday, September 24, 2020 12:29 PM To: Hannes Tschofenig <hannes.tschofe...@arm.com> Cc: vittorio.berto...@auth0.com Subject: Re: Subject claim ... was : [OAUTH-WG] About draft-ietf-oauth-access-token-jwt-10 Hi Hannes, You apparently missed my second email from this morning where I said that the oauth mailing list was not copied whereas it should. Hi Denis, I am trying to understand the text written below since I believe the old and the new text actually say something different. > When the "sub" claim is scoped to be locally unique in the context of the > issuer, in the event of resource servers collusion, it can be used to > correlate principals. When the "sub" claim is scoped to be locally unique in the context of the issuer then this does not automatically mean that two resource servers can find out that two subsequent requests are actually from the same principal. I am sorry but it does mean this. The current (old) text is making interpretations of section 4.1.2 from RFC 7519 that are not in accordance with it. This is a follow up of the "four flavours" I already mentioned that you were not able to understand. I don't argue that assigning different values to identify the principal would be a bad thing, but unfortunately the "sub" attribute cannot be used for this. The new text I propose is strictly sticking to the two "flavours" of the definition from RFC 7519 and hence cannot consider four flavours. A globally unique identifier cannot be a one-time identifier. A good example of a globally unique identifier is an email address. I hope this clarifies the issue. Since at this time, the whole mailing list has been kept ignorant of the exchanges we had this morning, I would recommend that you answer to the Comments 3 of my original email as if the exchanges we had this morning did not existed. Denis The old text explains how this works and says “ Similarly, if a solution requires preventing a resource server from correlating the principal’s activity within the resource itself, the authorization server should assign different "sub" values for every JWT access token issued. “ Your next text does not have that case anymore. Even the use of a globally unique identifier does not allow correlation if you issue one-time identifiers and use the access tokens only with the audience-restricted resource servers. I believe that the distinction between locally scoped to the issuer and globally scoped isn’t actually that relevant because even a locally scoped subject claim can easily be turned into a globally scoped one if you append the issuer identifier to it. Am I missing something here? Ciao Hannes From: Denis <denis.i...@free.fr><mailto:denis.i...@free.fr> Sent: Thursday, September 24, 2020 9:18 AM To: Hannes Tschofenig <hannes.tschofe...@arm.com><mailto:hannes.tschofe...@arm.com>; vittorio.berto...@auth0.com<mailto:vittorio.berto...@auth0.com> Subject: Re: Subject claim ... was : [OAUTH-WG] About draft-ietf-oauth-access-token-jwt-10 Hello Hannes, You have deleted the original text that I sent about Comment 3 and hence the thread has been broken. I am proposing to change the following text in section 6 (Privacy Considerations): This profile mandates the presence of the "sub" claim in every JWT access token, making it possible for resource servers to rely on that information for correlating incoming requests with data stored locally for the authenticated principal. Although the ability to correlate requests might be required by design in many scenarios, there are scenarios where the authorization server might want to prevent correlation. The "sub" claim should be populated by the authorization servers according to a privacy impact assessment. For instance, if a solution requires preventing tracking principal activities across multiple resource servers, the authorization server should ensure that JWT access tokens meant for different resource servers have distinct "sub" values that cannot be correlated in the event of resource servers collusion. Similarly, if a solution requires preventing a resource server from correlating the principal’s activity within the resource itself, the authorization server should assign different "sub" values for every JWT access token issued. In turn, the client should obtain a new JWT access token for every call to the resource server, to ensure that the resource server receives different "sub" and "jti" values at every call, thus preventing correlation between distinct requests. by the following text: This profile mandates the presence of the "sub" claim in every JWT access token, making it possible for resource servers to rely on that information for correlating incoming requests with data stored locally for the authenticated principal. The "sub" claim is scoped to be either locally unique in the context of the issuer or be globally unique (see section 4.1.2 from RFC 7519). When the "sub" claim is scoped to be locally unique in the context of the issuer, in the event of resource servers collusion, it can be used to correlate principals. When the "sub" claim is scoped to be globally unique, in the event of resource servers collusion, it can be used to correlate principals not only between resource servers but it can also be used to correlate principals between resource servers and other servers that do not implement this protocol but are using the same globally unique identifiers. Please re-use the original mail, to insert your comments. Denis Hi Denis, I am confused about what you are proposing here: ----- RFC 7519 defines the sub claim in the following way: 4.1.2. "sub" (Subject) Claim The "sub" (subject) claim identifies the principal that is the subject of the JWT. The claims in a JWT are normally statements about the subject. The subject value MUST either be scoped to be locally unique in the context of the issuer or be globally unique. The processing of this claim is generally application specific. The "sub" value is a case-sensitive string containing a StringOrURI value. Use of this claim is OPTIONAL. Change into: This profile mandates the presence of the "sub" claim in every JWT access token, making it possible for resource servers to rely on that information for correlating incoming requests with data stored locally for the authenticated principal. The "sub" claim is scoped to be either locally unique in the context of the issuer or be globally unique (see section 4.1.2 from RFC 7519). When the "sub" claim is scoped to be locally unique in the context of the issuer, in the event of resource servers collusion, it can be used to correlate principals. When the "sub" claim is scoped to be globally unique, in the event of resource servers collusion, it can be use d to correlate principals not only between resource servers but it can also be used to correlate principals between resource servers and other servers that do not implement this protocol but are using the same globally unique identifiers ----- The current text of the draft says the following: sub REQUIRED - as defined in Section 4.1.2 of [RFC7519]<https://tools.ietf.org/html/rfc7519#section-4.1.2>. In case of access tokens obtained through grants where a resource owner is involved, such as the authorization code grant, the value of "sub" SHOULD correspond to the subject identifier of the resource owner. In case of access tokens obtained through grants where no resource owner is involved, such as the client credentials grant, the value of "sub" SHOULD correspond to an identifier the authorization server uses to indicate the client application. See Section 5<https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-08#section-5> for more details on this scenario. Also, see Section 6<https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-08#section-6> for a discussion about how different choices in assigning "sub" values can impact privacy. The description about the scope of the value is found in RFC 7519 and why do we need to discuss this in this draft. What do we gain from doing so? Sorry if I am missing the point. Ciao Hannes IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
