Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 2 Jun 2020 10:28:27 +0000

Let me try to jump in here in order to make a proposal for the text in the privacy consideration section:

FROM:
6<https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-04#section-6>.  Privacy Considerations

   As JWT access tokens carry information by value, it now becomes
   possible for requestors and receivers to directly peek inside the
   token claims collection.  The client MUST NOT inspect the content of
   the access token: the authorization server and the resource server
   might decide to change token format at any time (for example by
   switching from this profile to opaque tokens) hence any logic in the
   client relying on the ability to read the access token content would
   break without recourse.  Nonetheless, authorization servers should
   not assume that clients will comply with the above.  Whenever client
   access to the access token content presents privacy issues for a
   given scenario, the authorization server should take explicit steps
   to prevent it as described below.

   In scenarios in which JWT access tokens are accessible to the end
   user, it should be evaluated whether the information can be accessed
   without privacy violations (for example, if an end user would simply
   access his or her own personal information) or if steps must be taken
   to enforce cofidentiality.  Possible measures include: encrypting the
   access token, encrypting the sensitive claims, omitting the sensitive
   claims or not using this profile, falling back on opaque access
   tokens.

   In every scenario, the content of the JWT access token will
   eventually be accessible to the resource server.  It's important to
   evaluate whether the resource server gained the proper entitlement to
   have access to any content received in form of claims, for example
   through user consent in some form, policies and agreements with the
   organization running the authorization servers, and so on.

TO:

6<https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-04#section-6>.  Privacy Considerations
   The design of OAuth 2.0 envisions that access tokens are created by
   authorization servers and consumed by resource servers.
   As JWT access tokens, as described in this document, carry information by value, it is
   possible for OAuth clients to peek inside the access token.
   While this is technical possible, it is important to note that the
   OAuth 2.0 protocol does not aim to expose the content of the
   access token to the client. The access token is therefore, by design, considered to be
   opaque to the client.

   A number of cases may make it difficult or impossible for clients to
   inspect the token, for example, the access token may be encrypted,
   the access token may contain vendor-specific claims that have not been
   standardized or have been standardized in other consortia making parsing
   of the token difficult. Additionally, there is no guarantee that the
   access token is conveyed by value and the authorization server implementation
   may change the token format at any time.

   In scenarios where it is desirable for the clients to obtain information
   transmitted in the access token, OAuth 2.0 token introspection may provide
   a useful tool to enable such functionality (proper authorization assumed).

   In scenarios where the content of the access token must not be readable
   by clients, encrypting the content of the access token is RECOMMENDED.

   Since the content of the access token is accessible to the resource server
   it is important to
   evaluate whether the resource server gained the proper entitlement to
   have access to any content received in form of claims, for example
   through user consent in some form, policies and agreements with the
   organization running the authorization servers, and so on. The policies
   and the user interfaces to enable this user consent are, however, part
   of a specific deployment and therefore outside the scope of this document.

How does this sound?

Ciao
Hannes

From: OAuth <[email-masked]> On Behalf Of Rifaat Shekh-Yusef
Sent: Thursday, May 14, 2020 8:03 PM
To: Denis <[email-masked]>
Cc: Vittorio Bertocci <[email-masked]>; [email-masked]
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

Denis,

You are rehashing the same issues that you have already discussed on the mailing list multiple times,
You could not get the WG to agree with your points, because the WG believe that this issue is outside the scope of this document.

The best the chairs can do at this stage is to capture your point in the shepherd write-up to the IESG.
We think this document has the support of the WG and is ready to move forward.

Regards,
 Rifaat

On Thu, May 14, 2020 at 12:29 PM Denis <[email-masked]<mailto:[email-masked]>> wrote:
Hi Vittorio,

I am referring to the email you sent on April the 29 th which is copied below.

1) You wrote:
> targeting of access tokens
Let me think about that a bit longer.
I acknowledge that the decision of including an audience has the effect of letting the AS track when the client accesses a particular resource,
but at the same time that’s completely mainstream and very much by design in a very large number of cases. As such, I find the language
you are suggesting to be potentially confusing, as it positions this as an exception vs a privacy protecting mainstream that is in fact not common,
and ascribes to the client more latitude than I believe is legitimate to expect or grant.
I’ll try to come up with concise language that clarifies to the reader that the current mechanism does allow AS tracking.
Since the last draft has been published on the 27 th, you have not proposed any "concise language that clarifies to the reader
that the current mechanism does allow AS tracking".

2) You also wrote about the "sub" uniqueness:
As long as an identifier identifies one resource only, it satisfies uniqueness. It doesn’t have to be a singleton.
RFC 7519 defines in section 4.1.2 the semantics of the "sub" claim using the following sentence:
The subject value MUST either be scoped to be locally unique in the context of the issuer or be globally unique.
The text does NOT say that the subject value "MUST be scoped to be locally unique in the context of the resource server".
Changing the semantics of an already defined claim is not permitted. If you would like to have such a semantics available,
a new claim should be defined (and it would be very nice to have it !).

3) The text is the privacy considerations section states:

   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 to preserve the desired level of privacy.

In the real world, it is also clients or end-users which would like to prevent correlation to preserve their desired level of privacy.

A better sentence would be:

   Although the ability to correlate requests might be required by design in many scenarios, there are scenarios where the authorization
   server or the client might want to prevent correlation to preserve the desired level of privacy.

4) The text continues with:

   Authorization servers should choose how to assign "sub" values according to the level of privacy required by each
   situation.  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.

Authorization servers are not necessarily able to choose the level of privacy required by each situation. When there are different
situations for the same resource server, the scope is (unfortunately at the moment) the only way to select the "level of privacy that is required".

The example ("For instance:") is only an example that provides a vague recommendation for the ASs which is NOT conformant
with the semantics of the "sub" claim as defined in RFC 7519.

What should be discussed here are not "examples" or what an authorization server should do, but explanations about the implications
for the end-user or for the client for the various values that can be placed into the "sub" claim by an AS. The problem is wider that simply
a collusion between resource servers, but also with other servers that DO NOT participate in any OAuth exchange.

RFC 6973 (Privacy Considerations) states in section 7 : Guidelines
This section provides guidance for document authors in the form of a questionnaire about a protocol being designed.
The questionnaire may be useful at any point in the design process, particularly after document authors have developed
a high-level protocol model as described in [RFC4101].
One of the questions is:
f.  Correlation.  Does the protocol allow for correlation of identifiers ?  Are there expected ways that information exposed
by the protocol will be combined or correlated with information obtained outside the protocol ?
It is important to provide an answer to these two questions.

Hereafter is some text that is fully conformant with RFC 7519 which should be incorporated into the privacy considerations section
which explains the implications of the two (and only two) flavours of the "sub" claim.
When the sub claim contains a locally unique identifier in the context of the issuer, this allows the tracking of principal activities
across multiple resource servers.

When the sub claim contains a globally unique identifier, this allows to correlate principal activities across multiple resource
servers, while in addition, this globally unique identifier may also allow to correlate the principal activities on servers where
no access has been performed by the principals to these servers but where the same globally unique identifiers are being used
by these servers.
Denis
Thanks Denis for the thorough commentary.

> The title of this spec.
Fixed, thanks!

> The client MUST NOT inspect the content of the access token
This is really a sticky point. I really want to acknowledge your PoV on this, but at the same time I found this to be one of the biggest sources of issues in the use of JWT for access tokens hence I feel we really need to give solid guidance here. Let me expand further on the reasoning behind it, and perhaps we can get to language that satisfies both PoVs.
To me the key point is that clients should not write code that inspects access tokens. Taking a dependency on the ability to do so is ignoring fundamental information about the architecture and relationships between OAuth roles, and suggests an ability of the client to understand the semantic of the content that cannot be assumed in the general case. I expanded on the details in my former reply to you on this topic, I would recommend referring to it. Clients violating this simple principle has been one of the most common sources of production issues I had to deal with in the past few years, and one of the hardest to remediate given that clients are hard to update and sometimes the things they relied on were irremediably lost. This is why I am inclined to put in here strong language.
That said: I have nothing against client developers examining a network trace and drawing conclusions based on the content of what they see. That doesn’t create any hard dependencies and has no implications in respect to changes in the solution behavior. However I am not sure how to phrase that in the specification, given that referring to the client inevitably refers to its code. I am open to suggestions.

>  3)…
I have a pretty hard time following the chain of reasoning in this section. Let me attempt to tackle it to the best of my understanding.
I think the key might be
> a client should be able to choose whether it wishes the sub claim to contain [..]
I don’t think that should be a choice left to the client. In business systems, my experience is that the type of identifiers to be used (when the IdP gives any choice at all)  is established at resource provisioning time. I am not aware of mechanisms thru which a client signals the nature of the identifier to be used, nor that would be fully feasible (the resource knows what it needs to perform its function).
Furthermore:
> which has nothing to do with uniqueness since the value changes for every generated token.
Again, this is something that was touched on in my former reply to your message. As long as an identifier identifies one resource only, it satisfies uniqueness. It doesn’t have to be a singleton.
Finally, the scope is optional (for good reasons: 1st party and non delegation scenarios don’t require it) hence it cannot be relied upon for properties that should hold in every scenario.
In summary: per the preceding thread on this topic, the consensus was that varying the sub content was a satisfactory way of protecting against correlation. I don’t a gree that clients should have a mechanism to request different sub flavors, as that decision should be done out of band by the AS and RS; and the scope isn’t always available anyway.
> targeting of access tokens
Let me think about that a bit longer.
I acknowledge that the decision of including an audience has the effect of letting the AS track when the client accesses a particular resource, but at the same time that’s completely mainstream and very much by design in a very large number of cases. As such, I find the language you are suggesting to be potentially confusing, as it positions this as an exception vs a privacy protecting mainstream that is in fact not common, and ascribes to the client more latitude than I believe is legitimate to expect or grant.
I’ll try to come up with concise language that clarifies to the reader that the current mechanism does allow AS tracking.

From: OAuth <[email-masked]><mailto:[email-masked]> on behalf of Denis <[email-masked]><mailto:[email-masked]>
Date: Wednesday, April 29, 2020 at 09:12
To: "[email-masked]"<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

You will find four comments numbered 1) to 4).
1) The title of this spec. is:

JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens

So, this spec. is supposed to be targeted to OAuth 2.0.  However, the header at the top of the page omits to mention it.

Currently, it is :
Internet-Draft       OAuth Access Token JWT Profile           April 2020
It should rather be:
Internet-Draft       OAuth 2.0 Access Token JWT Profile           April 2020

2) The following text is within section 6.

The client MUST NOT inspect the content of
the access token: the authorization server and the resource server
might decide to change token format at any time (for example by
switching from this profile to opaque tokens) hence any logic in the
client relying on the ability to read the access token content would
break without recourse.
Nonetheless, authorization servers should
not assume that clients will comply with the above.
It is of a primary importance that clients MAY be able to inspect tokens before transmitting them.
The "MUST NOT" is not acceptable.
The above text should be replaced with:

Reading the access token content may be useful for the user to verify that
the access token content matches with its expectations.  However,
the authorization server and the resource server might decide to change the
token format at any time.  Thus, the client should not expect to always be
in a position to read the access token content.

The remaining of the text about this topic is fine.

3) The next topic is about the sub claim.

The text states:

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 to preserve the desired
level of privacy. Authorization servers should choose how to assign
sub values according to the level of privacy required by each
situation.

I have a set of questions:

  1.  How can authorization servers choose how to assign sub values according to the level of privacy required "by each situation" ?
  2.  How can authorization servers know the level of privacy required "by each situation" ?
  3.  How can the users be informed of the level of privacy required "by each situation" ?
  4.  How can the users consent with the level of privacy required "by each situation" ?
Currently, the request MUST include either a resource parameter or an aud claim parameter, while it MAY include a scope parameter.
The syntax of the scope parameter is a list of space-delimited, case-sensitive strings (RFC 6749). It is thus subject to private agreements
between clients and Authorization Servers. Since the scope is being returned, it is a primary importance that the returned scope matches
with its expectations before transmitting the token to a Resource Server.

In theory, a client should be able to choose whether it wishes the sub claim to contain :

  *   a global unique identifier for all ASs ("globally unique"),
  *   a unique identifier for each AS ("locally unique in the context of the issuer"),
  *   a different pseudonym for each RS, or
  *   a different pseudonym for each authorization token request.
The only variable parameter that it can use for this purpose in the token request is the scope parameter.

RFC 7519 states is section 4.1.2:

The subject value MUST either be scoped to be locally unique in the context of the issuer
or be globally unique.

It is quite hard to recognize that the sub claim is able to carry a different pseudonym for each RS, i.e. for case (c), or
a different pseudonym for each authorization token request, i.e. for case (d), which has nothing to do with uniqueness
since the value changes for every generated token.

This has implications about the following text:

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.

Since it addresses case (c).

and also about the following text:

4.b) 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.

Since it addresses case (d).

This means that the current text placed in the privacy considerations section was a good attempt to address the case,
but that the text needs to be revised.

Proposed text replacement for all the previously quoted sentences:

According to RFC 7519 (4.1.2): The subject value MUST either be scoped to be locally unique in the context of the issuer or be globally unique.

When the sub claim contains a globally unique identifier, this allows to correlate principal activities across multiple resource servers, while in addition,
this globally unique identifier may also allow to correlate the principal activities on servers where no access has been performed by the principals
to these servers but where the same globally unique identifiers are being used by these servers.

When the sub claim contains a locally unique identifier in the context of the issuer, this also allows the tracking of principal activities across multiple resource servers.

The scope request parameter is the only way to influence on the content of the sub claim parameter. Its meaning is subject to a private agreement
between the client and the AS, which means that the use of the scope parameter is the only way to choose between a locally unique identifier
in the context of the issuer or a globally unique identifier.

Since the scope parameter is being returned, it is a primary importance that the returned scope matches with the expectations of the client before transmitting
the token to a Resource Server.

However, there are other cases where the client would like to be able to choose whether it wishes the sub claim to contain :
    - a different pseudonym for each RS so that different resource servers will be unable to correlate its activities, or
    - a different pseudonym for each authorization token request, so that the same resource server cannot correlate its activities performed at different instant of time.

Considering the semantics of the sub claim, these two cases cannot be currently supported.

4) The next topic is about the targeting of access tokens
Text had been proposed before the last conference call. Then, the topic has been presented at the very end of the last conference call, but no text has been included
in the next draft.
Here is a revised text be included in the privacy considerations section:
For security reasons, some clients may be willing to target their access tokens but, for privacy reasons, may be unwilling to disclose to Authorization Servers
an identification of the Resource Servers they are going to access, so that Authorization Servers will be unable to know which resources servers are being accessed.
The disclosure of the Resource Servers names allows the Authorization Servers to list all the Resource Servers being access by all its users and in addition to list pairs
of (Principal, Resource Servers) which allow to trace all the users accesses to Resource Servers performed through a given Authorization Server. When a token is targeted,
this profile does not contain provisions to address these two threats.

Denis
Hi all,

This is a second working group last call for "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens".

Here is the document:
https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-06

Please send your comments to the OAuth mailing list by April 29, 2020.

Regards,
 Rifaat & Hannes

_______________________________________________

OAuth mailing list

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth
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.

---

From: Denis <[email-masked]>
Date: Wed, 3 Jun 2020 12:11:58 +0200

Hi Hannes,

First of all, I do appreciate your efforts to attempt to get rid of the 
"MUST NOT" in the "Privacy considerations" section.

Let us look at the following proposed sentence:

While this is technical possible, it is important to note that the OAuth 
2.0 protocol does not aim to expose the content of the access token
     to the client. The access token is therefore, by design, considered 
to be opaque to the client".
/
In the context of this document/, a detailed content of the JWT is 
expected and thus, if a client receives a JWT compliant to this profile
(and if the token is not encrypted which is most often the case) it will 
absolutely be sure to pick up any guaranteed field within the JWT.
So, /in the context of this document/, the access token cannot be 
considered to be opaque to the client.

About the second paragraph, /in the context of this document (/besides 
the case where the JWT is encrypted), it is neither difficult,
nor impossible to parse the token/.
/
About the second paragraph, let us look at the following proposed 
sentence/in the context of this document/ :

" Additionally, there is no guarantee that the access token is conveyed 
by value and the authorization server implementation may change
       the token format at any time ".

The argumentation that the token format may change at any point of time, 
while being valid in the general case, is invalid /in the context of 
this document/.
This JWT profile will be stable over time. This means that this quoted 
sentence is inappropriate /in the context of this document/.

The third proposed paragraph is stating :

"In scenarios where it is where it is desirable for the clients to 
obtain information transmitted in the access token, OAuth 2.0 token 
introspection
       may provide a useful tool to enable such functionality (proper 
authorization assumed) ".

RFC 7662 (OAuth 2.0 Token Introspection) is a protocol to be used by 
protected resources, but is not a protocol to be used by clients.
As indicated, in order to be usable, a "proper authorization" also needs 
to be managed. Besides the difficulty to support such a protocol for 
clients
and to twist its original usage as defined in RFC 7662, it is simpler to 
develop the code to examine the content of the JWT, since its content is 
guaranteed
to be stable over time.

The last proposed paragraph is the following:

    " Since the content of the access token is accessible to the 
resource server it is important to evaluate whether the resource server 
gained the proper entitlement
       to have access to any content received in form of claims, /for 
example through user consent in some form, policies and agreements with 
the organization running /
/      the authorization servers, and so on/. The policies and the user 
interfaces to enable this user consent are, however, part of a specific 
deployment and therefore
       outside the scope of this document ".

The sentence "for example through user consent in some form, policies 
and agreements with the organization running the authorization servers, 
and so on"
should be removed, since this example lets believe that the consent is 
handled by the authorizations servers while it might be handled by the 
resource servers.

The last proposed paragraph would be solution neutral if the example 
were removed. This would lead to the following sentence:

Since the content of the access token is accessible to the resource 
server it is important to evaluate whether the resource server gained 
the proper entitlement
to have access to any content received in form of claims. The policies 
and the user interfaces to enable this user consent are, however, part 
of a specific deployment
and therefore outside the scope of this document.

Finally, there are still two questions that have been raised but which 
have not yet been answered at this time:

  * how can a client request a JWT compliant to /this/ profile, and
  * how can a client be confident that it got a JWT compliant to /this/
    profile ?

Denis

> *6*<https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-04#section-6>*.  
> Privacy Considerations*
>
> *6 
> <https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-04#section-6>. 
> Privacy Considerations*
>
> *From:* OAuth <[email-masked]> *On Behalf Of * Rifaat Shekh-Yusef
> *Sent:* Thursday, May 14, 2020 8:03 PM
> *To:* Denis <[email-masked]>
> *Cc:* Vittorio Bertocci <[email-masked]>; [email-masked]
> *Subject:* Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile 
> for OAuth 2.0 Access Tokens"
>
> Denis,
>
> You could not get the WG to agree with your points, because the WG 
> believe that this issue is outside the scope of this document.
>
>         /> targeting of access tokens/
>
>         I acknowledge that the decision of including an audience has
>         the effect of letting the AS track when the client accesses a
>         particular resource,
>         but at the same time that’s completely mainstream and very
>         much by design in a very large number of cases. As such, I
>         find the language
>         you are suggesting to be potentially confusing, as it
>         positions this as an exception vs a privacy protecting
>         mainstream that is in fact not common,
>         *I’ll try to come up with concise language that clarifies to
>         the reader that the current mechanism does allow AS tracking*.
>
>     Since the last draft has been published on the 27 th, you have not
>     proposed any "concise language that clarifies to the reader
>         As long as an identifier identifies one resource only, it
>         satisfies uniqueness. It doesn’t have to be a singleton.
>
>         The subject value MUST either be scoped to be locally unique
>         in the context of the issuer or be globally unique.
>
>     The text does NOT say that the subject value "MUST be scoped to be
>     locally unique in the context of the *resource server*".
>
>     Changing the semantics of an already defined claim is not
>     permitted. If you would like to have such a semantics available,
>     In the real world, it is also clients or end-users which would
>     like to prevent correlation to preserve their desired level of
>     privacy.
>
>        server *or the client* might want to prevent correlation to
>     preserve the desired level of privacy.
>
>        Authorization servers should choose how to assign "sub" values
>     according to the level of privacy required by each
>        situation.  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"
>     Authorization servers are not necessarily able to choose the level
>     of privacy required by each situation. When there are different
>     situations for the same resource server, the scope is
>     (unfortunately at the moment) the only way to select the "level of
>     privacy that is required".
>
>     The example ("For instance:") is only an example that provides a
>     vague recommendation for the ASs which is NOT conformant
>     What should be discussed here are not "examples" or what an
>     authorization server should do, but explanations about the
>     implications
>     for the end-user or for the client for the various values that can
>     be placed into the "sub" claim by an AS. The problem is wider that
>     simply
>     a collusion between resource servers, but also with other servers
>     that DO NOT participate in any OAuth exchange.
>
>         This section provides guidance for document authors in the
>         form of a questionnaire about a protocol being designed.
>         The questionnaire may be useful at any point in the design
>         process, particularly after document authors have developed
>         f. *Correlation*.  Does the protocol allow for correlation of
>         identifiers ? Are there expected ways that information exposed
>         by the protocol will be combined or *correlated with
>         information obtained outside the protocol* ?
>
>     Hereafter is some text that is fully conformant with RFC 7519
>     which should be incorporated into the privacy considerations section
>         When the sub claim contains a locally unique identifier in the
>         context of the issuer, this allows the tracking of principal
>         activities
>         When the sub claim contains a globally unique identifier, this
>         allows to correlate principal activities across multiple resource
>         servers, while in addition, this globally unique identifier
>         may also allow to correlate the principal activities on
>         servers where
>         no access has been performed by the principals to these
>         servers but where the same globally unique identifiers are
>         being used
>         by these servers.
>
>     Denis
>
>         /> The title of this spec./
>
>         Fixed, thanks!
>
>         /> The client MUST NOT inspect the content of the access token/
>
>         This is really a sticky point. I really want to acknowledge
>         your PoV on this, but at the same time I found this to be one
>         of the biggest sources of issues in the use of JWT for access
>         tokens hence I feel we really need to give solid guidance
>         here. Let me expand further on the reasoning behind it, and
>         perhaps we can get to language that satisfies both PoVs.
>
>         To me the key point is that clients should not write /code/
>         that inspects access tokens. Taking a dependency on the
>         ability to do so is ignoring fundamental information about the
>         architecture and relationships between OAuth roles, and
>         suggests an ability of the client to understand the semantic
>         of the content that cannot be assumed in the general case. I
>         expanded on the details in my former reply to you on this
>         topic, I would recommend referring to it. Clients violating
>         this simple principle has been one of the most common sources
>         of production issues I had to deal with in the past few years,
>         and one of the hardest to remediate given that clients are
>         hard to update and sometimes the things they relied on were
>         irremediably lost. This is why I am inclined to put in here
>         strong language.
>
>         That said: I have nothing against client developers examining
>         a network trace and drawing conclusions based on the content
>         of what they see. That doesn’t create any hard dependencies
>         and has no implications in respect to changes in the solution
>         behavior. However I am not sure how to phrase that in the
>         specification, given that referring to the client inevitably
>         refers to its code. I am open to suggestions.
>
>         >  3)…
>
>         I have a pretty hard time following the chain of reasoning in
>         this section. Let me attempt to tackle it to the best of my
>         understanding.
>
>         I think the key might be
>
>         /> a client should be able to choose whether it wishes the sub
>         claim to contain [..]/
>
>         I don’t think that should be a choice left to the client. In
>         business systems, my experience is that the type of
>         identifiers to be used (when the IdP gives any choice at all)
>          is established at resource provisioning time. I am not aware
>         of mechanisms thru which a client signals the nature of the
>         identifier to be used, nor that would be fully feasible (the
>         resource knows what it needs to perform its function).
>
>         Furthermore:
>
>         /> which has nothing to do with uniqueness since the value
>         changes for every generated token./
>
>         Again, this is something that was touched on in my former
>         reply to your message. As long as an identifier identifies one
>         resource only, it satisfies uniqueness. It doesn’t have to be
>         a singleton.
>
>         Finally, the scope is optional (for good reasons: 1^st party
>         and non delegation scenarios don’t require it) hence it cannot
>         be relied upon for properties that should hold in every scenario.
>
>         In summary: per the preceding thread on this topic, the
>         consensus was that varying the sub content was a satisfactory
>         way of protecting against correlation. I don’t a gree that
>         clients should have a mechanism to request different sub
>         flavors, as that decision should be done out of band by the AS
>         and RS; and the scope isn’t always available anyway.
>
>         /> targeting of access tokens/
>
>         I acknowledge that the decision of including an audience has
>         the effect of letting the AS track when the client accesses a
>         particular resource, but at the same time that’s completely
>         mainstream and very much by design in a very large number of
>         cases. As such, I find the language you are suggesting to be
>         potentially confusing, as it positions this as an exception vs
>         a privacy protecting mainstream that is in fact not common,
>         I’ll try to come up with concise language that clarifies to
>         the reader that the current mechanism does allow AS tracking.
>
>         *From: *OAuth <[email-masked]>
>         <mailto:[email-masked]> on behalf of Denis
>         <[email-masked]> <mailto:[email-masked]>
>         *Date: *Wednesday, April 29, 2020 at 09:12
>         *To: *"[email-masked]" <mailto:[email-masked]>
>         <[email-masked]> <mailto:[email-masked]>
>         *Subject: *Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT)
>         Profile for OAuth 2.0 Access Tokens"
>
>         *1) *The title of this spec. is:
>
>         JSON Web Token (JWT) Profile for OAuth *2.0* Access Tokens
>
>         So, this spec. is supposed to be targeted to OAuth *2.0.
>         * However, the header at the top of the page omits to mention it.
>
>         Currently, it is :
>
>         Internet-Draft OAuth *2.0* Access Token JWT Profile April 2020
>
>         *2)* The following text is within section 6.
>
>         *3) *The next topic is about the sub claim.
>
>         The text states:
>
>          1. How can authorization servers choose how to assign sub
>             values according to the level of privacy required "by each
>             situation" ?
>          4. How can the users *consent* with the level of privacy
>             required "by each situation" ?
>
>         Currently, the request MUST include either a resource
>         parameter or an aud claim parameter, while it MAY include a
>         scope parameter.
>
>         The syntax of the scope parameter is a list of
>         space-delimited, case-sensitive strings (RFC 6749). It is thus
>         subject to private agreements
>         between clients and Authorization Servers. Since the scope is
>         being returned, it is a primary importance that the returned
>         scope matches
>         The only variable parameter that it can use for this purpose
>         in the token request is the scope parameter.
>
>         It is quite hard to recognize that the sub claim is able to
>         carry a different pseudonym for each RS, i.e. for case (c), or
>         a different pseudonym for each authorization token request,
>         i.e. for case (d), which has nothing to do with uniqueness
>         This means that the current text placed in the privacy
>         considerations section was a good attempt to address the case,
>         According to RFC 7519 (4.1.2): The subject value MUST either
>         be scoped to be locally unique in the context of the issuer or
>         be globally unique.
>
>         When the sub claim contains a globally unique identifier, this
>         allows to correlate principal activities across multiple
>         resource servers, while in addition,
>         this globally unique identifier may also allow to correlate
>         the principal activities on servers where no access has been
>         performed by the principals
>         to these servers but where the same globally unique
>         identifiers are being used by these servers.
>
>         When the sub claim contains a locally unique identifier in the
>         context of the issuer, this also allows the tracking of
>         principal activities across multiple resource servers.
>
>         The scope request parameter is the only way to influence on
>         the content of the sub claim parameter. Its meaning is subject
>         to a private agreement
>         between the client and the AS, which means that the use of the
>         scope parameter is the only way to choose between a locally
>         unique identifier
>         Since the scope parameter is being returned, it is a primary
>         importance that the returned scope matches with the
>         expectations of the client before transmitting
>         However, there are other cases where the client would like to
>         be able to choose whether it wishes the sub claim to contain :
>             - a different pseudonym for each RS so that different
>         resource servers will be unable to correlate its activities, or
>             - a different pseudonym for each authorization token
>         request, so that the same resource server cannot correlate its
>         activities performed at different instant of time.
>
>         *4) *The next topic is about the targeting of access tokens
>
>         Text had been proposed before the last conference call. Then,
>         the topic has been presented at the very end of the last
>         conference call, but no text has been included
>         in the next draft.
>
>         For security reasons, some clients may be willing to target
>         their access tokens but, for privacy reasons, may be unwilling
>         to disclose to Authorization Servers
>         an identification of the Resource Servers they are going to
>         access, so that Authorization Servers will be unable to know
>         which resources servers are being accessed.
>         The disclosure of the Resource Servers names allows the
>         Authorization Servers to list all the Resource Servers being
>         access by all its users and in addition to list pairs
>         of (Principal, Resource Servers) which allow to trace all the
>         users accesses to Resource Servers performed through a given
>         Authorization Server. When a token is targeted,
>             This is a second working group last call for "JSON Web
>             Token (JWT) Profile for OAuth 2.0 Access Tokens".
>
>             Here is the document:
>
>             [email-masked]  <mailto:[email-masked]>
>
>     [email-masked] <mailto:[email-masked]>
> 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.

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 4 Jun 2020 14:26:10 +0000

Hi Denis,

Please see my response below.

From: Denis <[email-masked]>
Sent: Wednesday, June 3, 2020 12:12 PM
To: Hannes Tschofenig <[email-masked]>
Cc: Rifaat Shekh-Yusef <[email-masked]>; Vittorio Bertocci <[email-masked]>; [email-masked]
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

Hi Hannes,
First of all, I do appreciate your efforts to attempt to get rid of the "MUST NOT" in the "Privacy considerations" section.

    While this is technical possible, it is important to note that the OAuth 2.0 protocol does not aim to expose the content of the access token
    to the client. The access token is therefore, by design, considered to be opaque to the client".

In the context of this document, a detailed content of the JWT is expected and thus, if a client receives a JWT compliant to this profile
(and if the token is not encrypted which is most often the case) it will absolutely be sure to pick up any guaranteed field within the JWT.
So, in the context of this document, the access token cannot be considered to be opaque to the client.

[Hannes] Here we have a disconnect. The OAuth 2.0 design does not assume that the client inspects the access tokens if it flies by. This document could not change that.
The purpose of this document is actually quite simple: Those who want to use JWT as a format for access tokens they can use the claims described in this document. You are also free to use whatever format you want.

About the second paragraph, in the context of this document (besides the case where the JWT is encrypted), it is neither difficult,
nor impossible to parse the token.

About the second paragraph, let us look at the following proposed sentence in the context of this document :

    " Additionally, there is no guarantee that the access token is conveyed by value and the authorization server implementation may change
      the token format at any time ".

The argumentation that the token format may change at any point of time, while being valid in the general case, is invalid in the context of this document.
This JWT profile will be stable over time. This means that this quoted sentence is inappropriate in the context of this document.

[Hannes] Here is the issue. In a given deployment you do not know how the access token is encoded nor whether the claims are in this format. You don’t know whether the token is conveyed by reference or by value. Hence, why should we suddenly even give developers the impression that OAuth Clients should look at the token.

    " In scenarios where it is where it is desirable for the clients to obtain information transmitted in the access token, OAuth 2.0 token introspection
      may provide a useful tool to enable such functionality (proper authorization assumed) ".

RFC 7662 (OAuth 2.0 Token Introspection) is a protocol to be used by protected resources, but is not a protocol to be used by clients.
As indicated, in order to be usable, a "proper authorization" also needs to be managed. Besides the difficulty to support such a protocol for clients
and to twist its original usage as defined in RFC 7662, it is simpler to develop the code to examine the content of the JWT, since its content is guaranteed
to be stable over time.
[Hannes] While it may be simpler to inspect the access token, the use of token introspection is a better match for the OAuth architecture. We can talk about updating the token introspection RFC to also describe this use case, assuming there is interest.
The question in general will surface why the client should get access to the content of the access token in the first place. For those cases where information is passed to the client other mechanisms, such as the identity token in OIDC, have been developed.

   " Since the content of the access token is accessible to the resource server it is important to evaluate whether the resource server gained the proper entitlement
      to have access to any content received in form of claims, for example through user consent in some form, policies and agreements with the organization running
      the authorization servers, and so on. The policies and the user interfaces to enable this user consent are, however, part of a specific deployment and therefore
      outside the scope of this document ".

The sentence "for example through user consent in some form, policies and agreements with the organization running the authorization servers, and so on"
should be removed, since this example lets believe that the consent is handled by the authorizations servers while it might be handled by the resource servers.
[Hannes] The information is disclosed by the authorization server and hence the consent has to be with the authorization server.

The last proposed paragraph would be solution neutral if the example were removed. This would lead to the following sentence:

Since the content of the access token is accessible to the resource server it is important to evaluate whether the resource server gained the proper entitlement
to have access to any content received in form of claims. The policies and the user interfaces to enable this user consent are, however, part of a specific deployment
and therefore outside the scope of this document.

Finally, there are still two questions that have been raised but which have not yet been answered at this time:

  *   how can a client request a JWT compliant to this profile, and
  *   how can a client be confident that it got a JWT compliant to this profile ?

[Hannes] Regarding the two questions: It cannot and it was never the intention of this work.

Ciao
Hannes

Denis

FROM:

TO:

How does this sound?

Ciao
Hannes

From: OAuth <[email-masked]><mailto:[email-masked]> On Behalf Of Rifaat Shekh-Yusef
Sent: Thursday, May 14, 2020 8:03 PM
To: Denis <[email-masked]><mailto:[email-masked]>
Cc: Vittorio Bertocci <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

Denis,

Regards,
 Rifaat

Fixed, thanks!

Currently, it is :

The text states:

Denis
Hi all,

Here is the document:

Regards,
 Rifaat & Hannes

OAuth mailing list

---

From: Phillip Hunt <[email-masked]>
Date: Thu, 4 Jun 2020 11:35:02 -0700

Denis,

I agree with Hannes. Speaking as one of the security consideration and threat model authors for OAuth2, a foundational design assumption was always that access tokens are opaque to clients. 

Even in the case of OIDC they created the id token to be a token defined for the client in the special purpose case of authentication. 

In my experience a client insisting on using and interpreting tokens is often doing something wrong and violating security processing rules like audience. Issues such as sharing a token unintended parties (ie not the resources specified by the aud claim) leading to confused deputy or impersonation attacks. 

Opaqueness of ATs to clients is a foundational architectural principle of the OAuth 2 framework. 

This is not to dismiss new use cases OAuth 2 does not address. But I feel these cases that require access token inspection by clients should be evaluated in the context of a new protocol evolution proposal (eg like xyz). 

Phil Hunt

> On Jun 4, 2020, at 7:26 AM, Hannes Tschofenig <[email-masked]> wrote:
> 
> 
> Hi Denis,
>  
> how can a client request a JWT compliant to this profile, and
> how can a client be confident that it got a JWT compliant to this profile ?
>  
> 6.  Privacy Considerations
>  
>  
> 6.  Privacy Considerations
> On Thu, May 14, 2020 at 12:29 PM Denis <[email-masked]> wrote:
> Hi Vittorio,
>  
> From: OAuth <[email-masked]> on behalf of Denis <[email-masked]>
> To: "[email-masked]" <[email-masked]>
> How can authorization servers choose how to assign sub values according to the level of privacy required "by each situation" ?
> How can authorization servers know the level of privacy required "by each situation" ?
> How can the users be informed of the level of privacy required "by each situation" ?
> How can the users consent with the level of privacy required "by each situation" ?
> a global unique identifier for all ASs ("globally unique"),
> a unique identifier for each AS ("locally unique in the context of the issuer"),
> a different pseudonym for each RS, or
> a different pseudonym for each authorization token request.
> [email-masked]
> [email-masked]
> 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
> [email-masked]

---

From: Denis <[email-masked]>
Date: Fri, 5 Jun 2020 09:52:10 +0200

Hi  Hannes,

Let us start by the last argument of this email which is copied below:

    Finally, there are still two questions that have been raised but
    which have not yet been answered at this time:

      * how can a client request a JWT compliant to /this/ profile, and
      * how can a client be confident that it got a JWT compliant to
        /this/ profile ?

    [Hannes] Regarding the two questions: It cannot and it was never the
    intention of this work.

If this document was limited to section 2, it would simply be a 
description of a specific profile, but it is more than that
since it includes two additional sections:

    3. Requesting a JWT Access Token
    4. Validating JWT Access Tokens

In section 3, the text states:

    If the request does not include a "resource" parameter, the 
authorization server *MUST* use in the "aud" claim
   as default resource indicator.

If the authorization server has no way to know that the client is 
sending a request which implies compliance
with draft-ietf-oauth-access-token-jwt why should it behave in such a way ?

In section 4 the text states:

    resource servers receiving a JWT access token *MUST* validate it in 
the following manner

If the resource server has no way to know that it is checking a JWT 
which is supposed to be compliant
with draft-ietf-oauth-access-token-jwt why should it behave in such a way ?

The responses to these two questions are important before handling the 
other comments.

IMHO, a token type would be able to easily address the problem; 
otherwise sections 3 and 4 should be deleted.

The remaining of my replies are within the text below prefixed with [Denis].

> *From:* Denis <[email-masked]>
> *Sent:* Wednesday, June 3, 2020 12:12 PM
> *To:* Hannes Tschofenig <[email-masked]>
> *Cc:* Rifaat Shekh-Yusef <[email-masked]>; Vittorio Bertocci 
> <[email-masked]>; [email-masked]
> I do appreciate your efforts to attempt to get rid of the "MUST NOT" 
> in the "Privacy considerations" section.
>
> OAuth 2.0 protocol does not aim to expose the content of the access token
> (and if the token is not encrypted which is most often the case) it 
> will absolutely be sure to pick up any guaranteed field within the JWT.
> [Hannes] Here we have a disconnect. The OAuth 2.0 design does not 
> assume that the client inspects the access tokens if it flies by. This 
> document could not change that.
> The purpose of this document is actually quite simple: Those who want 
> to use JWT as a format for access tokens they can use the claims 
> described in this document.
> You are also free to use whatever format you want.
>
[Denis] You wrote: "The OAuth 2.0 design does not *assume *that the 
client inspects the access tokens if it flies by". However, there are 
cases where
the client may be interested to know which attributes have been placed 
into the JWT, there should be some way(s) to be able to do it.
Using Token Introspection (extended to be used by clients) would be like 
bringing in an elephant to kill a mouse. Using a local API would be a 
simple
solution, however the IETF defines (most often) protocols rather than 
local APIs.

The user's privacy cannot be fulfilled if the client is unable to know 
which attributes have been placed into the JWT. A solution to address 
this issue
would be to clearly advertise the following in the Privacy 
Considerations section:

    As the OAuth 2.0 design does not assume that the client inspects the
    access tokens if it flies by, clients have no way to know which
    identity
    attributes have effectively been placed into the JWT. Since these
    identity attributes may disclose more private information than what
    is strictly
    necessary to perform one or more operations, this may be a serious
    concern for users that care about their privacy.

>     " Additionally, there is no guarantee that the access token is 
> conveyed by value and the authorization server implementation may change
> The argumentation that the token format may change at any point of 
> time, while being valid in the general case, is invalid /in the 
> context of this document/.
> [Hannes] Here is the issue. In a given deployment you do not know how 
> the access token is encoded nor whether the claims are in this format.
> You don’t know whether the token is conveyed by reference or by value. 
> Hence, why should we suddenly even give developers the impression
> that OAuth Clients should look at the token.
>
[Denis] OAuth clients SHOULD only look at the attributes placed into the 
JWT, when/if they have privacy concerns about the identity attributes
that have been placed into the JWT. Otherwise, they would have no idea 
on how they could be traced by the resources servers /and other servers //
//that don't use OAuth/. In the current situation, it appears necessary 
to clearly advertise in the Privacy Considerations section that the 
token opacity
may be a serious concern for users that care about their privacy.

It is also important to note that the /foundational design assumption 
/of keeping access tokens opaque to clients (and their users) is closing 
the door
to any confidence for clients that their privacy is indeed preserved by 
the authorization servers.

> As indicated, in order to be usable, a "proper authorization" also 
> needs to be managed. Besides the difficulty to support such a protocol 
> for clients
> and to twist its original usage as defined in RFC 7662, it is simpler 
> to develop the code to examine the content of the JWT, since its 
> content is guaranteed
> to be stable over time.
>
> [Hannes] While it may be simpler to inspect the access token, the use 
> of token introspection is a better match for the OAuth architecture.
> We can talk about updating the token introspection RFC to also 
> describe this use case, assuming there is interest.
>
[Denis] Updating the token introspection RFC would be like bringing a 
bull in a china shop.

> The question in general will surface why the client should get access 
> to the content of the access token in the first place.
> For those cases where information is passed to the client other 
> mechanisms, such as the identity token in OIDC, have been developed.
>
[Denis] The reason has been explained above: it has to do with 
correlation of the users by different resources servers,
but also by other servers when "globally unique identifiers" are being 
used in the "sub" claim.

> resource server it is important to evaluate whether the resource 
> server gained the proper entitlement
> example through user consent in some form, policies and agreements 
> with the organization running /
> /      the authorization servers, and so on/. The policies and the 
> user interfaces to enable this user consent are, however, part of a 
> specific deployment and therefore
> and agreements with the organization running the authorization 
> servers, and so on"
> [Hannes] The information is disclosed by the authorization server and 
> hence the consent has to be with the authorization server.
>
[Denis] A resource server may say: "In order to perform this operation , 
I need your date of birth". If the user agrees, then the client will ask 
to the authorization
server to insert the date of birth of the user into the JWT. In this 
way, the consent is given by the client when talking to the resource 
server. The authorization
server is not involved with a consent given by the user. Obviously, this 
is one scenario and other scenarios exist, but such a scenario should 
not be prevented.

The AS does not need to know which operation will be performed by the 
user, it only needs to know that the user is willing his birth date to 
be included into the JWT.
However, at the moment, since there is no RFC supporting such a 
possibility, asking for specific standardized attributes is not (yet) 
possible.

>   * how can a client be confident that it got a JWT compliant to
>     /this/ profile ?
>
[Denis] This point has been addressed at the top of this email. However, 
I would like to add one point.

Let us suppose that a token type would be added both in the token 
request and within the token itself,
and if, at the minimum, the client would  be allowed to access to this 
token type, saying "This token is conformant to RFC XXX",
then the client would be able to call a local API able to disclose the 
content of the token.

This would be like using a piece of cheese to catch the mouse.

Denis

> Ciao
>
> Hannes
>
>
> Denis
>
>     Let me try to jump in here in order to make a proposal for the
>     text in the privacy consideration section:
>
>     FROM:
>
>     *6*
>     <https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-04#section-6>*. 
>     Privacy Considerations*
>
>     *From:* OAuth <[email-masked]>
>     <mailto:[email-masked]> *On Behalf Of *Rifaat Shekh-Yusef
>     *To:* Denis <[email-masked]> <mailto:[email-masked]>
>     *Cc:* Vittorio Bertocci <[email-masked]>
>     <mailto:[email-masked]>; [email-masked]
>     <mailto:[email-masked]>
>     *Subject:* Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT)
>             I acknowledge that the decision of including an audience
>             has the effect of letting the AS track when the client
>             accesses a particular resource,
>             *I’ll try to come up with concise language that clarifies
>             to the reader that the current mechanism does allow AS
>             tracking*.
>
>         Since the last draft has been published on the 27 th, you have
>         not proposed any "concise language that clarifies to the reader
>             The subject value MUST either be scoped to be locally
>             unique in the context of the issuer or be globally unique.
>
>         The text does NOT say that the subject value "MUST be scoped
>         to be locally unique in the context of the *resource server*".
>
>            Although the ability to correlate requests might be
>         required by design in many scenarios, there are scenarios
>         where the authorization
>            Although the ability to correlate requests might be
>         required by design in many scenarios, there are scenarios
>         where the authorization
>            Authorization servers should choose how to assign "sub"
>         values according to the level of privacy required by each
>            the  authorization server should ensure that JWT access
>         tokens meant for different resource servers have distinct "sub"
>         Authorization servers are not necessarily able to choose the
>         level of privacy required by each situation. When there are
>         different
>         (unfortunately at the moment) the only way to select the
>         "level of privacy that is required".
>
>         The example ("For instance:") is only an example that provides
>         a vague recommendation for the ASs which is NOT conformant
>         for the end-user or for the client for the various values that
>         can be placed into the "sub" claim by an AS. The problem is
>         wider that simply
>         a collusion between resource servers, but also with other
>         servers that DO NOT participate in any OAuth exchange.
>
>             f. *Correlation*.  Does the protocol allow for correlation
>             of identifiers ?  Are there expected ways that information
>             exposed
>             When the sub claim contains a locally unique identifier in
>             the context of the issuer, this allows the tracking of
>             principal activities
>             When the sub claim contains a globally unique identifier,
>             this allows to correlate principal activities across
>             multiple resource
>             servers, while in addition, this globally unique
>             identifier may also allow to correlate the principal
>             activities on servers where
>             This is really a sticky point. I really want to
>             acknowledge your PoV on this, but at the same time I found
>             this to be one of the biggest sources of issues in the use
>             of JWT for access tokens hence I feel we really need to
>             give solid guidance here. Let me expand further on the
>             reasoning behind it, and perhaps we can get to language
>             that satisfies both PoVs.
>
>             To me the key point is that clients should not write
>             /code/ that inspects access tokens. Taking a dependency on
>             the ability to do so is ignoring fundamental information
>             about the architecture and relationships between OAuth
>             roles, and suggests an ability of the client to understand
>             the semantic of the content that cannot be assumed in the
>             general case. I expanded on the details in my former reply
>             to you on this topic, I would recommend referring to it.
>             Clients violating this simple principle has been one of
>             the most common sources of production issues I had to deal
>             with in the past few years, and one of the hardest to
>             remediate given that clients are hard to update and
>             sometimes the things they relied on were irremediably
>             lost. This is why I am inclined to put in here strong
>             language.
>
>             That said: I have nothing against client developers
>             examining a network trace and drawing conclusions based on
>             the content of what they see. That doesn’t create any hard
>             dependencies and has no implications in respect to changes
>             in the solution behavior. However I am not sure how to
>             phrase that in the specification, given that referring to
>             the client inevitably refers to its code. I am open to
>             suggestions.
>
>             >  3)…
>
>             I have a pretty hard time following the chain of reasoning
>             in this section. Let me attempt to tackle it to the best
>             of my understanding.
>
>             I think the key might be
>
>             /> a client should be able to choose whether it wishes the
>             sub claim to contain [..]/
>
>             I don’t think that should be a choice left to the client.
>             In business systems, my experience is that the type of
>             identifiers to be used (when the IdP gives any choice at
>             all)  is established at resource provisioning time. I am
>             not aware of mechanisms thru which a client signals the
>             nature of the identifier to be used, nor that would be
>             fully feasible (the resource knows what it needs to
>             perform its function).
>
>             Furthermore:
>
>             reply to your message. As long as an identifier identifies
>             one resource only, it satisfies uniqueness. It doesn’t
>             have to be a singleton.
>
>             Finally, the scope is optional (for good reasons: 1^st
>             party and non delegation scenarios don’t require it) hence
>             it cannot be relied upon for properties that should hold
>             in every scenario.
>
>             consensus was that varying the sub content was a
>             satisfactory way of protecting against correlation. I
>             don’t a gree that clients should have a mechanism to
>             request different sub flavors, as that decision should be
>             done out of band by the AS and RS; and the scope isn’t
>             always available anyway.
>
>             I acknowledge that the decision of including an audience
>             has the effect of letting the AS track when the client
>             accesses a particular resource, but at the same time
>             that’s completely mainstream and very much by design in a
>             very large number of cases. As such, I find the language
>             mainstream that is in fact not common, and ascribes to the
>             client more latitude than I believe is legitimate to
>             expect or grant.
>
>             I’ll try to come up with concise language that clarifies
>             to the reader that the current mechanism does allow AS
>             tracking.
>
>             *Subject: *Re: [OAUTH-WG] Second WGLC on "JSON Web Token
>             (JWT) Profile for OAuth 2.0 Access Tokens"
>
>                 values according to the level of privacy required "by
>                 each situation" ?
>             parameter or an aud claim parameter, while it MAY include
>             a scope parameter.
>
>             space-delimited, case-sensitive strings (RFC 6749). It is
>             thus subject to private agreements
>             between clients and Authorization Servers. Since the scope
>             is being returned, it is a primary importance that the
>             returned scope matches
>             The only variable parameter that it can use for this
>             purpose in the token request is the scope parameter.
>
>             It is quite hard to recognize that the sub claim is able
>             to carry a different pseudonym for each RS, i.e. for case
>             (c), or
>             a different pseudonym for each authorization token
>             request, i.e. for case (d), which has nothing to do with
>             uniqueness
>             According to RFC 7519 (4.1.2): The subject value MUST
>             either be scoped to be locally unique in the context of
>             the issuer or be globally unique.
>
>             When the sub claim contains a globally unique identifier,
>             this allows to correlate principal activities across
>             multiple resource servers, while in addition,
>             this globally unique identifier may also allow to
>             correlate the principal activities on servers where no
>             access has been performed by the principals
>             When the sub claim contains a locally unique identifier in
>             the context of the issuer, this also allows the tracking
>             of principal activities across multiple resource servers.
>
>             The scope request parameter is the only way to influence
>             on the content of the sub claim parameter. Its meaning is
>             subject to a private agreement
>             between the client and the AS, which means that the use of
>             the scope parameter is the only way to choose between a
>             locally unique identifier
>             Since the scope parameter is being returned, it is a
>             primary importance that the returned scope matches with
>             the expectations of the client before transmitting
>             However, there are other cases where the client would like
>             to be able to choose whether it wishes the sub claim to
>             contain :
>             request, so that the same resource server cannot correlate
>             its activities performed at different instant of time.
>
>             Text had been proposed before the last conference call.
>             Then, the topic has been presented at the very end of the
>             last conference call, but no text has been included
>             in the next draft.
>
>             For security reasons, some clients may be willing to
>             target their access tokens but, for privacy reasons, may
>             be unwilling to disclose to Authorization Servers
>             an identification of the Resource Servers they are going
>             to access, so that Authorization Servers will be unable to
>             know which resources servers are being accessed.
>             Authorization Servers to list all the Resource Servers
>             being access by all its users and in addition to list pairs
>             of (Principal, Resource Servers) which allow to trace all
>             the users accesses to Resource Servers performed through a
>             given Authorization Server. When a token is targeted,
>     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.
>