[OAUTH-WG] FW: Subject claim ... was : About draft-ietf-oauth-access-token-jwt-10

[Hannes Tschofenig <[e-mail]>]

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 <[e-mail]>
Sent: Thursday, September 24, 2020 12:29 PM
To: Hannes Tschofenig <[e-mail]>
Cc: [e-mail]
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 <[e-mail]><mailto:[e-mail]>
Sent: Thursday, September 24, 2020 9:18 AM
To: Hannes Tschofenig <[e-mail]><mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
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.