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

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 3 May 2020 22:59:23 -0700

Hi Denis,

You seem to be continuing to be operating under incorrect assuptions about
how OAuth 2.0 works, and have proceeded to make long chains of reasoning
that, unfortunately, are not based on a solid foundation.  In order to
reduce the amount of frustration amongst all participants, in the future I
strongly suggest that you make sure you have the fundamentals correct
before going into long chains of reasoning.

Furthermore, while you have indeed identified some areas where the current
OAuth ecosystem could be improved, I reiterate that the current document,
defining a token format that is optional to use, is not the place to make
changes to how OAuth works.  I think you do everyone a disservice for
attempting to suggest that this document should do so.

Because there is so much based on a flawed foundation, I will not respond
inline to every point, but do see a few things where further clarification
would be useful.

On Thu, Apr 30, 2020 at 11:50:04AM +0200, Denis wrote:
> Hello Vittorio,
> 
> Your reply was amazingly fast. Responses are between the lines.
> 
> > 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.
> >
> First of all, a "*MUST NOT* "should not be placed in a privacy 
> considerations section, but in the main body of the document.
> The goal of a privacy considerations section is to provide explanations, 
> but not to introduce additional requirements.

That's not actually a requirement.  In many cases it makes sense to avoid
putting normative requirements in the security and/or privacy
considerations sections, but it is very much a thing that is done in many
RFCs, and in some cases it is useful to do so.

> Then after, since this section is about privacy considerations, it is 
> important to refer to an ISO standard that has been published 9 years ago.

Is it?  I don't see much precedent for IETF documents referencing this ISO
standard.  If it's so important you'd think that we'd have been citing it
with regularity.  Since this will be the first or second time, I think you
need to provide some additional justification as to how the topics it
covers fit within the existing IETF BCPs for how we treat security and
privacy considerations before we conclude that it is the appropriate
reference.

> It is ISO 29100 (Information technology — Security techniques — Privacy 
> framework). Most of the ISO standards need to be bought.
> However, there are a few exceptions and this standard can be freely 
> downloaded from the ISO web site, if you accept some conditions,
> using this URL:
> 
>     https://standards.iso.org/ittf/PubliclyAvailableStandards/index.html
> 
> ISO 29100, even if it is outdated on some aspects (it only deals with 
> two entities), identifies ten principles (See Table 3).
> 
>     1. Consent and choice
> 
>     2. Purpose legitimacy and specification
> 
>     3. Collection limitation
> 
>     4. Data minimization
> 
>     5. Use, retention and disclosure limitation
> 
>     6. Accuracy and quality
> 
>     7. Openness, transparency and notice
> 
>     8. Individual participation and access
> 
>     9. Accountability
> 
>     10. Information security
> 
>     11. Privacy compliance
> 
> If the client is unable to inspect the token, then openness and 
> transparency do not exist any more.
> 
> Since there is no formal protocol in OAuth 2.0  for "consent and 
> choice", the only way for a client for denying its consent is to inspect 
> the token
> and to stop its transmission if the content of the token is not 
> considered to be adequate for it.
> 
> Since you are open to suggestions, would you please reconsider the text 
> I proposed: it simply states that if the client wants to inspect the token,
> it will not necessarily be in a position to do it. It is simply a 
> warning, but this warning does not prevent the client to attempt to 
> inspect the token .
> 
> I will go one step further: if the client wants to inspect the token and 
> if the format of the token is unknown to the client, then the client 
> will simply
> stop its further transmission. For some clients, preserving their 
> privacy may be more important than performing an access to a RS.

That may be true, but I agree with Vittorio that this document needs to
strongly discourage clients from doing so, since they would be breaking a
protocol invariant if they do.

Thanks,

Ben

> > >  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).
> >
> Consent and choice is the first of the ten privacy principles. Since 
> OAuth has not been constructed taking into considerations this privacy 
> principle,
> it is quite "normal" that you don't observe protocols able to do it at 
> the present time.
> 
> > 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.
> >
> It is a matter of interpretation. I stick to the definition given in RFC 
> 7519 (section 4.1.2):
> 
> *T**he subject value MUST either be scoped to be locally unique in the 
> context of the issuer or be globally unique.*
> 
> However, the "context of the issuer" is left undefined.
> 
> > 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.
> >
> I would not say that the scope request parameter is a nice way to choose 
> which attributes should be placed in a JWT. However, considering the 
> limitations placed
> in this document, it is the ONLY way to do. In my email sent before the 
> virtual meeting, I wrote: "Allowing a client to only specify a scope and 
> a resource is very restrictive".
> 
> Clause 2.2.2 (second paragraph) states:
> 
> ***This profile does not introduce any mechanism for a client to**
> ******directly request the presence of specific claims in JWT access**
> ******tokens*, as the authorization server can determine what additional
> claims are required by a particular resource server by taking in
> consideration the client_id of the client, the scope and the resource
> parameters included in the request.
> 
> Currently, the client has no control of the claims that will be placed 
> in a JWT and further more the current wording of privacy consideration 
> section
> prevents the client to have any inspection of the attributes that have 
> been placed in a JWT. Privacy principles 1 and 7 from ISO 29100 are not 
> fulfilled.
> 
> There are more implications. If, in the future, a mechanism is defined 
> to allow the client to choose the type of the attributes that should be 
> placed in a JWT,
> then the "sub" claim is insufficient. Taking into consideration my 
> previous email, four types of attributes types would need to be specified:
> 
> The client should be able to choose whether it wishes a claim that contains:
> 
>   *      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.
> 
> Clause 2.2.2 states:
> 
> *   the authorization server can determine what additional**
> ******claims are required by a particular resource server* by taking in
> consideration the client_id of the client, the scope and the resource
> parameters included in the request.
> 
> I don't believe this is true in general. Considering its privacy 
> preferences, only the client may know what is appropriate: not the AS, 
> neither the RS.
> 
> > 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.
> >
> "/if all you have is a hammer, everything looks like a nail/".
> 
> When the only parameter that can be used is the "sub" claim, then the 
> only solution is to place everything into it.
> 
> > 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.
> >
> While it would be nice to have such a mechanism, we are not going to 
> define such a mechanism during a second WGLC.
> 
> The privacy considerations section should only inform the readers about 
> the limitations of the protocol in terms of privacy.
> I have proposed text to address the point. If you would prefer a 
> different wording to address this point, please make another proposal.
> 
> > /> 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.
> >
> Please do so.
> 
> Denis
> 
> > *From: *OAuth <[email-masked]> on behalf of Denis 
> > <[email-masked]>
> > *Date: *Wednesday, April 29, 2020 at 09:12
> > *To: *"[email-masked]" <[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]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Denis <[email-masked]>
Date: Mon, 4 May 2020 12:36:05 +0200

Hello Benjamin,

First of all, you don't need to use an aggressive language to state your 
opinion.

Please follow BCP 54, i.e. RFC 7154, issued inMarch 2014 with the 
following title:"IETF Guidelines for Conduct". In particular:

    " Regardless of these individual differences, participants treat
    their colleagues with respect as persons especially
        when it is difficult to agree with them: treat other
    participants as you would like to be treated ".

I wrote:

(...)

     I will go one step further: if the client wants to inspect the 
token and
     if the format of the token is unknown to the client, then the client
will simply stop its further transmission. For some clients, preserving 
their
privacy may be more important than performing an access to a RS.

You responded :

    That may be true, but I agree with Vittorio that this document needs to
    strongly discourage clients from doing so, since they would 
be**_breaking _*
*_a __protocol invariant_ if they do.

If "this may be true", then you should consider that the token 
inspection by a client may be useful and thus should not be prevented.
However, there is no guarantee that it may always be performed.

You are using the wording" _breaking a protocol invariant_". In which 
RFC (related to OAuth) has such a "protocol invariance" been first 
mandated ?

I attempted to find an RFC using the wording "protocol invariant". I 
found RFC 8546 (Wire Image) issued in April 2019 dealing in section 4.1
with the topic " Declaring Protocol Invariants", using the following terms:

Declaring a protocol's invariants represents a promise made by the 
protocol's developers that certain bits in the wire image, and behaviors
    observable in the wire image, will be preserved through the 
specification of all future versions of the protocol.

Using these explanations, I have difficulties to understand how 
preventing the content of a JWT to be inspected by a client may be 
considered
as "a promise made by the protocol's developers that certain bits in the 
wire, and behaviors observable in the wire, will be preserved
through the specification of all future versions of the protocol".

I probably missed something. Would you be able to explain ?

A second point:

As a co-author of RFC 3161 published in August 2001 and of RFC 36268 
published in November 2003 to name a few of the RFCs
to which I contributed, I am not aware of any reference to an ISO 
document made into a RFC. This seems to be a common practice.
When I used the term "refer", I was not asking to place a reference to 
an ISO document in this working draft but to allow everybody in
the WG to have the ability to have a look at its content (and for free). 
Table 3 is simply a quick "reference" to ten privacy principles.

A third point:

RFC 6973 (Privacy Considerations for Internet Protocols) has been 
published in July 2013. Its introduction mentions:

The guidance provided here can and should be used to _assess the privacy 
considerations of protocol_, architectural,
     and operational _specifications_ (...)

    The guidance provided here is meant to help the thought process of 
privacy analysis; it does not provide specific directions
     for how to write a privacy considerations section.

Section 7 (Guidelines) mentions :

    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].
(...)
However, by carefully considering the answers to each question, document 
authors should be able to produce a comprehensive
    analysis that can serve as the basis for discussion of whether the 
protocol adequately protects against privacy threats.

An important item which is addressed both in ISO 29100 and RFC 6973 in 
section 7.1 is "Data Minimization". RFC 6973 mentions:

a.*Identifiers*.What identifiers does the protocol use for 
distinguishing initiators of communications?
Does the protocol use identifiers that allow different protocol 
interactions to be correlated?
What identifiers could be omitted or be made less identifying while 
still fulfilling the protocol’s goals?

b.*Data*.What information does the protocol expose about individuals, 
their devices, and/or their device usage (other than the identifiers 
discussed in (a))?
      To what extent is this information linked to the identities of the 
individuals?How does the protocol combine personal data with the 
identifiers discussed in (a)?

c.*Observers*.Which information discussed in (a) and (b) is exposed to 
each other protocol entity (i.e., recipients, intermediaries, and enablers)?
Are there ways for protocol implementers to choose to limit the 
information shared with each entity?  µ
Are there operational controls available to limit the information shared 
with each entity?
(...)

e.*Persistence of identifiers*.What assumptions are made in the protocol 
design about the lifetime of the identifiers discussed in (a)?
      Does the protocol allow implementers or users to delete or replace 
identifiers?

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?

RFC 6973 also mentions in section 7.2 (User Participation) (while ISO 
29100 uses the wording "Consent and choice"):

a.*User control*.What controls or consent mechanisms does the protocol 
define or require before personal data or identifiers are shared or 
exposed via the protocol?

All the above questions are useful to assess privacy considerations 
about the protocol. Some key questions related to OAuth are the following:

  * considering the current semantics of the "sub" claim, what are the
    implications in terms of "correlation" ?
  * considering the current semantics of the scope request parameter (or
    of any other token request parameter), what are the implications in
    terms of "user control" ?

The next version of this document should use RFC 6973 more closely as a 
guidance to "_assess the privacy considerations __of the protocol_ and 
of operational _specifications_".

Denis

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 8 May 2020 17:54:08 -0700

Hi Denis,

Sorry for the slow response.  I had several deadlines this week and
couldn't think much farther ahead than the next one, so my INBOX fell
behind.

> First of all, you don't need to use an aggressive language to state your 

I would appreciate a little more clarity on which language comes across as
"aggressive"; I was trying very hard to stick to what I see as the facts:

- many people are frustrated with these long discussions that continue to
  rehash similar points and involve people having a hard time seeing each
  others' worldview
- you are making proposals for changes to this document that would
  represent drastic changes from previous specifications that are used by
  the current document (and are drastic changes from current practice),
  without acknowledging that they are in fact drastic changes to the core
  protocol

Please accept my apologies for however I deviated from that goal.

I am trying to get us to a place where we can have productive discussions
and improve the quality of our protocols.  Right now I don't think we're
having very productive discussions; in fact, we're holding up progress on a
document that looks likely to become widely deployed by asking it to do
more than is reasonable for it to do.

> inspection by a client may be useful and thus should not be prevented.

I do in fact agree that token inspection by a client can be useful in at
least some situations.  However, RFC 6749 is quite clear that "the [access
token] is usually opaque to the client".  A requirement that the access
token MUST be inspectable by the client is incompatible with something that
"is usually opaque to the client".

> However, there is no guarantee that it may always be performed.

I agree that this is the current state of affairs.

> RFC (related to OAuth) has such a "protocol invariance" been first 

RFC 6749, per above.

> specification of all future versions of the protocol.

Perhaps my usage of the term "protocol invariant" was confusing or
inappropriate.  I meant to say that you are trying to change a property of
the core protocol specification; whether or not it is best described as an
"invariant" is immaterial to my point.  In other words, a generic OAuth 2.0
client has to be prepared to deal with access tokens that are opaque to it.

> I probably missed something. Would you be able to explain ?

(I tried to above.)

> the WG to have the ability to have a look at its content (and for free). 

Ah, I misunderstood you then; sorry about that.
Using readily-available documents where someone has already written down
relevant information is a great way to quick-start a discussion, but I
thought you wanted us to have this I-D accept wholesale the definitions
from the ISO document without further discussion.

> protocol adequately protects against privacy threats.

I actually think it would be quite valuable to perform this kind of
analysis for RFC 6749 (and extensions).  Its usage has evolved quite a lot
from its initial origins, and there are (as you have pointed out) many
areas that are lacking.  Would you be willing to start an I-D on this
topic?  I think that it would be more valuable to do something systematic
than to try to do something piecemeal for this document just because it is
a document the WG is currently working on.

>     terms of "user control" ?

I agree: these are "key questions related to OAuth".  Where I perhaps
disagree with you is that I believe they are key questions relating to the
protocol as a whole; the discussion so far seems to indicate that you wish
to both perform this analysis and change the protocol all as part of the
JWT profile document.  I think the tasks are better performed separately.

> of operational _specifications_".

I fully support having privacy considerations sections that discuss the
privacy properties of the protocol in question, even including aspects that
are currently lacking.

However, I do not believe that a JWT profile for OAuth use is the place to
make changes to the core OAuth protocol that improve its privacy properties.
(If we can specify the token format in a way has better privacy properties
than alternative token formats, we should, of course, but we can't change
the protocol itself.)
Making changes to OAuth that improves its privacy properties is a laudable
goal, and I would happily read any I-Ds that proposed such protocol changes
(though I fear that the current deployment/semantics may constrain the
degree to which OAuth 2.0 can be improved and have much more hope for the
txauth group to produce a protocol with good privacy properties).  The
discussion so far has not convinced me that this document is the right
document in which to do so.

Thanks,

Ben

---

From: Denis <[email-masked]>
Date: Mon, 11 May 2020 14:34:04 +0200

Hi Benjamin,

We are making progress since we now understand better each other. You 
wrote several sentences on which I agree:

    "I do in fact agree that token inspection by a client can be useful
    in at least some situations".

    "I fully support having privacy considerations sections that discuss
    the privacy properties of the protocol in question,
    ***e**ven including aspects that are currently lacking*.

    "I do not believe that a JWT profile for OAuth use is the place to
    make changes to the core OAuth protocol that improve its privacy
    properties".

I also accept your apologies.

RFC 6749 is quite clear in section 1.4 that "The string [access token] 
*is usually opaqu**e* to the client".
However, it does not mean that : "The client *MUST NOT* inspect the 
content of the access token".
I believe the wording I proposed corresponds to the reality:

    There is no guarantee that token inspection can always be performed.

When privacy is a concern, if a client wants to verify the claims that 
have been placed into the token but is unable to do it, it will simply 
not present it.

The document should consider more closely the recommendations included  
RFC 6973 (Privacy Considerations for Internet Protocols)
for the writing the Privacy considerations section.

Finally, you wrote:

    Making changes to OAuth that improves its privacy properties is a
    laudable goal, and
    I would happily read any I-Ds that proposed such protocol changes.

Since OAuth has not been constructed from the beginning along Privacy by 
Design rules, it is only possible to make a few improvements.
Whenever possible we should do it.

In my email sent on May the 8 th relative to another thread ( I-D 
Action: draft-ietf-oauth-security-topics-15.txt), I wrote:

    When the token contains one or more attributes that uniquely allow
    to identify the collaborative user (e.g. a "sub" claim),
    then Alice can only impersonate the collaborative user and such a
    case can easily be obtained using TeamViewer.

          * Unfortunately using the "sub" claim is not "privacy
            friendly", since collaborative RSs will be able to link the
            accounts
            of their respective users.  Nevertheless, this a good news
            for Vittorio, since the "sub" claim is REQUIRED in the
            "Profile for OAuth 2.0 Access Tokens". This means that,
            *when this profile is being used, OAuth 2.0 is resistant **to
            the ABC attack*.

          * Using a different claim that would only contain an
            identifier that is unique to the RS (such as a pseudo) would be
            more appropriate (as FIDO does), but I am not aware of a
            claim that has been defined which would have such a semantics.

If a claim that would only contain an identifier that is unique to the 
RS (such as a pseudo) has not already been defined in an I-D,
then it would be interesting to define it.

Denis

---

From: Jared Jennings <[email-masked]>
Date: Mon, 11 May 2020 08:30:01 -0500

If I may, step in and offer a suggestion.

What if instead of "MUST NOT" replace with "SHOULD NOT"?

To me, (and this might be me), but MUST NOT describes a violation. As in I
broke the law. Conversely, I interpret, "SHOULD NOT" as a recommendation, a
guideline, best practice, etc.

If then the sentence went on to explain why you should not inspect the
token, the risk is therefore known and on the "implementer" of the
inspection.

Jared

On Mon, May 11, 2020 at 7:34 AM Denis <[email-masked]> wrote:

> "I do in fact agree that token inspection by a client can be useful in at
> least some situations".
>
> "I fully support having privacy considerations sections that discuss the
> privacy properties of the protocol in question,
>   *e**ven including aspects that are currently lacking*.
>
> "I do not believe that a JWT profile for OAuth use is the place to make
> changes to the core OAuth protocol that improve its privacy properties".
>
> RFC 6749 is quite clear in section 1.4 that "The string [access token] *is
> usually opaqu**e* to the client".

---

From: Vittorio Bertocci <[email-masked]>
Date: Tue, 12 May 2020 00:24:40 +0000

Thank you Jared for your comment!
I have to admit I have been very tempted to go that route, mostly for moving things forward, but I still think we’d do the reader a disservice by relaxing the language there.
Real world scenarios are full of situations where additional assumptions can lower dangers that must be taken in consideration in the general case, which might make less of a risk going against the spec in those particular circumstances, but their existence doesn’t warrant relaxing guidance for the general case. A concrete example: I worked on scenarios where resource servers wanted to guarantee some degree of business continuity in case of AS outage, which boiled down to RS’ willingness to accept ATs past their declared expiration time, on the condition that the AS outage condition was detectable and the staleness of the AT didn’t cross a tolerance threshold. The business scenario made sense, and the implementer was within their right in deciding that disregarding exp in those circumstances was acceptable. Nonetheless, I would not argue that given the existence of that scenario, rfc7519 should turn its MUST NOT into a SHOULD NOT.
There might be circumstances in which the stars align and it is safe for a client to inspect the AT, but in the general case that’s not true (this has been covered in details in the various threads on the topic). Also note, the fact that the client (as the application code) is banned from doing that inspection doesn’t mean that the solution as a whole cannot do it. Developers can examine network traces, or use any other mechanism available in their particular circumstances to inspect traffic that are out of scope for this specification, and that would give them in practice the oversight discussed here where possible. The specification doesn’t aim at preventing that inspection in general, but it does aim at ensuring that the ability to do perform that is excluded from the contract between the roles described in OAuth2, so that any violation is either understood to be high bar, or the logic meant to perform those checks is implemented outside of the client code itself, preserving the protocol invariants and protecting developers from one of the most painful production issues I have observed in many years of real life use of JWT ATs.
Ultimately, the latter part is one of the reasons for which I have a hard time relaxing this part, whereas pretty easily relaxed constraints on other areas where my initial position was more strict (multiple resources in audience, etc). I know this to be very painful if not addressed correctly, and the only arguments against it appear to be more about principle than about concrete scenarios, expressive power or security.

From: Jared Jennings <[email-masked]>
Date: Monday, May 11, 2020 at 06:30
To: Denis <[email-masked]>
Cc: Benjamin Kaduk <[email-masked]>, Vittorio Bertocci <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

To me, (and this might be me), but MUST NOT describes a violation. As in I broke the law. Conversely, I interpret, "SHOULD NOT" as a recommendation, a guideline, best practice, etc.

If then the sentence went on to explain why you should not inspect the token, the risk is therefore known and on the "implementer" of the inspection.

Jared

On Mon, May 11, 2020 at 7:34 AM Denis <[email-masked]<mailto:[email-masked]>> wrote:
Hi Benjamin,

We are making progress since we now understand better each other. You wrote several sentences on which I agree:
"I do in fact agree that token inspection by a client can be useful in at least some situations".

"I fully support having privacy considerations sections that discuss the privacy properties of the protocol in question,
  even including aspects that are currently lacking.

"I do not believe that a JWT profile for OAuth use is the place to make changes to the core OAuth protocol that improve its privacy properties".
I also accept your apologies.

RFC 6749 is quite clear in section 1.4 that "The string [access token] is usually opaque to the client".
However, it does not mean that : "The client MUST NOT inspect the content of the access token".
I believe the wording I proposed corresponds to the reality:
There is no guarantee that token inspection can always be performed.

---

From: Jared Jennings <[email-masked]>
Date: Mon, 11 May 2020 22:14:30 -0500

Hi Vittorio,

Yeah, this does make a bit of sense. So, the goal is to guide implementors from making bad choices, not from a security perspective. Meaning, it's not a security risk that a client does inspect or analyze the token. Instead, it's is an interop issue and thus we are guiding implementors to never assume or expect the token format to be consistent or of a expected format, for various reasons. I kinda know the answer to this question, but I am kinda asking this way to help restate the intent of the "topic" and maybe help guide to a wording that works for everyone.

For example, as a consultant, it can be very helpful to know how to decompile or inspect an "Object", but at the same time knowing that such a method or practice should never be used in production.

Jared

> On May 11, 2020, at 19:24, Vittorio Bertocci <[email-masked]> wrote:
> 
> Real world scenarios are full of situations where additional assumptions can lower dangers that must be taken in consideration in the general case, which might make less of a risk going against the specin those particular circumstances, but their existence doesn’t warrant relaxing guidance for the general case. A concrete example: I worked on scenarios where resource servers wanted to guarantee some degree of business continuity in case of AS outage, which boiled down to RS’ willingness to accept ATs past their declared expiration time, on the condition that the AS outage condition was detectable and the staleness of the AT didn’t cross a tolerance threshold. The business scenario made sense, and the implementer was within their right in deciding that disregarding exp in those circumstances was acceptable. Nonetheless, I would not argue that given the existence of that scenario, rfc7519 should turn its MUST NOT into a SHOULD NOT.
>

---

From: Vittorio Bertocci <[email-masked]>
Date: Tue, 12 May 2020 05:40:30 +0000

It’s not really an interop issue either, given that following or not following this requirement doesn’t alter the shape of messages or tokens. It’s more of an architectural requirement, which preserves the relationships between the OAuth2 roles involved and prevents the confusion that might arise by the availability of data that characterizes this particular scenario, but that doesn’t change the more general premises of the protocol. In terms of finding common ground, I am not sure if visions as diametrically opposed as pitting a MUST against a MUST NOT have much of an achievable common ground, especially given that the MUST NOT stance already passed consensus in the past year, and in more than one month of very public debate during last calls, the MUST side had mostly one backer and more than one opposed.

From: Jared Jennings <[email-masked]>
Date: Monday, May 11, 2020 at 20:14
To: Vittorio Bertocci <[email-masked]>
Cc: Denis <[email-masked]>, Benjamin Kaduk <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

Hi Vittorio,

Jared

On May 11, 2020, at 19:24, Vittorio Bertocci <[email-masked]<mailto:[email-masked]>> wrote:

---

From: Denis <[email-masked]>
Date: Tue, 12 May 2020 11:54:52 +0200

Hi Vittorio,

draft-ietf-oauth-access-token-jwt states in section 2.2.2:

This profile does not introduce any mechanism for a client to directly 
request the presence of specific claims in JWT access tokens,
       as the authorization server can determine what additional claims 
are required by a particular resource server by taking in consideration
       the client_id of the client, the scope and the resource 
parameters included in the request.

RFC 6750 states in section 3 :

     (...)

     Use of the "scope" attribute is OPTIONAL. The "scope" value is 
intended for programmatic use and is not meant to be displayed to end-users.

This has the following consequence: the end-user is usually not able to 
know which attributes correspond to a scope (or to a missing scope).
The only way to know is to look at the content of the token and the 
reason for doing this may be related a privacy consideration.

RFC 6749 states in section 1.4: "The string [access token] *is usually 
opaque* to the client".
However, this sentence does not mean : "The client *MUST NOT* inspect 
the content of the access token".
RFC 6749 does not contain a MUST, SHALL or SHOULD in the above quoted 
sentence. In such a situation,
we should not be "more royalist than the King"

Benjamin Kaduk wrote:

     "*I do in fact agree that token inspection by a client can be 
useful in at least some situations*".

This being stated, hereafter is a full text proposal replacement for the 
first paragraph (12 lines)
of the Privacy Considerations section (section 6):

     As indicated in RFC 6750, the "scope" value is intended for 
programmatic use and is not meant to be displayed to end-users.
   This means that, even when the client uses the scope parameter, the 
end-user will usually have no knowledge of the attributes
    which correspond to the scope (or to a missing scope parameter).

    RFC 6749 mentions that the string [access token] is usually opaque 
to the client. Hence, the client will not necessarily be able
    to inspect the content of the access token. As an example, an 
authorization server and a resource server might decide to change
    the access token format at any time.

    There are however cases, where the access token content presents 
privacy issues for a given scenario. In such cases,
    the end-user would like to know which attributes have been placed in 
a token before forwarding it to a resource server.
    If these attributes do not correspond to the expectations of the 
end-user or if the format of the access token is not understandable
    by the client, then the client SHOULD NOT forward the access token 
to the resource server.

Denis

> It’s not really an interop issue either, given that following or not 
> following this requirement doesn’t alter the shape of messages or 
> tokens. It’s more of an architectural requirement, which preserves the 
> relationships between the OAuth2 roles involved and prevents the 
> confusion that might arise by the availability of data that 
> characterizes this particular scenario, but that doesn’t change the 
> more general premises of the protocol. In terms of finding common 
> ground, I am not sure if visions as diametrically opposed as pitting a 
> MUST against a MUST NOT have much of an achievable common ground, 
> especially given that the MUST NOT stance already passed consensus in 
> the past year, and in more than one month of very public debate during 
> last calls, the MUST side had mostly one backer and more than one 
> opposed.
>
> *From: *Jared Jennings <[email-masked]>
> *Date: *Monday, May 11, 2020 at 20:14
> *To: *Vittorio Bertocci <[email-masked]>
> *Cc: *Denis <[email-masked]>, Benjamin Kaduk <[email-masked]>, 
> "[email-masked]" <[email-masked]>
> Yeah, this does make a bit of sense. So, the goal is to guide 
> implementors from making bad choices, not from a security perspective. 
> Meaning, it's not a security risk that a client does inspect or 
> analyze the token. Instead, it's is an interop issue and thus we are 
> guiding implementors to never assume or expect the token format to be 
> consistent or of a expected format, for various reasons. I kinda know 
> the answer to this question, but I am kinda asking this way to help 
> restate the intent of the "topic" and maybe help guide to a wording 
> that works for everyone.
>
> For example, as a consultant, it can be very helpful to know how to 
> decompile or inspect an "Object", but at the same time knowing that 
> such a method or practice should never be used in production.
>
> Jared
>
>
>
>     On May 11, 2020, at 19:24, Vittorio Bertocci
>     <[email-masked] <mailto:[email-masked]>>
>     wrote:
>
>     Real world scenarios are full of situations where additional
>     assumptions can lower dangers that must be taken in consideration
>     in the general case, which might make less of a risk going against
>     the spec/in those particular circumstances/, but their existence
>     doesn’t warrant relaxing guidance for the general case. A concrete
>     example: I worked on scenarios where resource servers wanted to
>     guarantee some degree of business continuity in case of AS outage,
>     which boiled down to RS’ willingness to accept ATs past their
>     declared expiration time, on the condition that the AS outage
>     condition was detectable and the staleness of the AT didn’t cross
>     a tolerance threshold. The business scenario made sense, and the
>     implementer was within their right in deciding that disregarding
>     exp in those circumstances was acceptable. Nonetheless, I would
>     not argue that given the existence of that scenario, rfc7519
>     should turn its MUST NOT into a SHOULD NOT.
>

---

From: "Manger, James" <[email-masked]>
Date: Tue, 12 May 2020 10:45:01 +0000

That text is an poor suggestion, Denis.

> end-user will usually have no knowledge of the attributes which correspond to the scope

The OAuth model is that the Authorization Server is responsible for informing the end-user about what is going on. That's why they display consent pages showing what will be disclosed, often giving the end-user control over this.

> the end-user would like to know which attributes have been placed in a token ...
> ... if the format of the access token is not understandable by the client, then the client SHOULD NOT forward

A major point of OAuth is to protect end-users from clients. The end-user has to trust the Authorization Server (they sign-in there), but that can lessen the trust required in clients.

A client that inspects an access-token in the hope of preventing an Authorization Server from disclosing too much to a Resource Server is kidding itself (and kidding the end-user). The access-token might be a JWT with minimal claims, then the RS calls the AS's token-inspection API and gets back squillions of claims.

So, by all means, do some auditing of Authorization Servers, Resource Servers, and the tokens they exchange to improve your confidence that they are behaving as they say. But if you write a client to do that inspection as standard behaviour then don't call it OAuth-compliant. It will break when the Authorization Server choses to change its token format. Because your client has violated a MUST in the best practices it will be clear where the responsibility for broken interop lies. And the rest of the ecosystem can hope that such clients are not prevalent enough to harm ongoing evolution of the rest of the system.

--
James Manger

From: OAuth <[email-masked]> On Behalf Of Denis
Sent: Tuesday, 12 May 2020 7:55 PM
To: Vittorio Bertocci <[email-masked]>
Cc: [email-masked]
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"
...
This being stated, hereafter is a full text proposal replacement for the first paragraph (12 lines)
of the Privacy Considerations section (section 6):

    As indicated in RFC 6750, the "scope" value is intended for programmatic use and is not meant to be displayed to end-users.
   This means that, even when the client uses the scope parameter, the end-user will usually have no knowledge of the attributes
   which correspond to the scope (or to a missing scope parameter).

   RFC 6749 mentions that the string [access token] is usually opaque to the client. Hence, the client will not necessarily be able
   to inspect the content of the access token. As an example, an authorization server and a resource server might decide to change
   the access token format at any time.

   There are however cases, where the access token content presents privacy issues for a given scenario. In such cases,
   the end-user would like to know which attributes have been placed in a token before forwarding it to a resource server.
   If these attributes do not correspond to the expectations of the end-user or if the format of the access token is not understandable
   by the client, then the client SHOULD NOT forward the access token to the resource server.
Denis

---

From: Denis <[email-masked]>
Date: Tue, 12 May 2020 14:40:25 +0200

Hi James,

You wrote: "Because your client has violated a MUST in the best 
practices". It seems that you are already taking your wish as granted.
However, this is exactly the point we are discussing.

You wrote: "The end-user has to trust the Authorization Server (they 
sign-in there)". The end-user does not trust the AS for everything,
but only with respect to some activities. Please remember a definition 
of trust present in ISO/IEC 13888-1. 3.59.

    trust : relationship between two elements, a set of activities and a
    security policy in which element x trusts element y
    if and only if x has confidence that y will behave in a well defined
    way (with respect to the activities) that does not violate
    the given security policy.

You wrote: "The access-token might be a JWT with minimal claims". Yes 
indeed, however the end-user may not know it.

You wrote  "a client to do that inspection as standard behaviour". No, 
token inspection is not a standard behaviour.
It happens if, and only if, the end-user has some privacy concerns. 
Please reconsider the text proposal which does make
that point:

Denis

> The OAuth model is that the Authorization Server is responsible for 
> informing the end-user about what is going on. That’s why they display 
> consent pages showing what will be disclosed, often giving the 
> end-user control over this.
>
> > the *end-user* would like to know which attributes have been placed in a 
> token …
>
> > … if the format of the access token is not understandable by the *client*, then the client SHOULD NOT forward
>
> A major point of OAuth is to protect end-users from clients. The 
> end-user has to trust the Authorization Server (they sign-in there), 
> but that can lessen the trust required in clients.
>
> A client that inspects an access-token in the hope of preventing an 
> Authorization Server from disclosing too much to a Resource Server is 
> kidding itself (and kidding the end-user). The access-token might be a 
> JWT with minimal claims, then the RS calls the AS’s token-inspection 
> API and gets back squillions of claims.
>
> So, by all means, do some auditing of Authorization Servers, Resource 
> Servers, and the tokens they exchange to improve your confidence that 
> they are behaving as they say. But if you write a client to do that 
> inspection as standard behaviour then don’t call it OAuth-compliant. 
> It will break when the Authorization Server choses to change its token 
> format. Because your client has violated a MUST in the best practices 
> it will be clear where the responsibility for broken interop lies. And 
> the rest of the ecosystem can hope that such clients are not prevalent 
> enough to harm ongoing evolution of the rest of the system.
>
> --
>
> James Manger
>
> *From:*OAuth <[email-masked]> *On Behalf Of *Denis
> *Sent:* Tuesday, 12 May 2020 7:55 PM
> *To:* Vittorio Bertocci <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile 
> …
>    the end-user would like to know which attributes have been placed 
> in a token before forwarding it to a resource server.

---

From: "Manger, James" <[email-masked]>
Date: Wed, 13 May 2020 00:34:59 +0000

That text is a worse suggestion. It hopelessly confuses "end-user" and "client".

The idea behind the text is only relevant to a client that is written to call a resource server and is registered with an authorization server, but thinks that the details those two exchange (via access tokens) at the client's instigation are sometimes fine, yet at other times are a privacy violation that they aren't trying to hide. It is theoretically conceivable that there is a niche where that is possible, which shows how flexible OAuth is.

I think the main message of this thread is that an access-token really should be explicitly made opaque (by being a reference, or an encrypted JWT) to avoid the privacy risk that details intended to be shared between an Authorization Server and Resource Server are leaked to a Client.

End-users with privacy concerns (which is all of us) should carefully choose the Authorization Servers we deal with. Here is an alternative suggestion as an OAuth privacy consideration.

"OAuth is used to convey information established at an Authorization Server to a Resource Server. Only those two parties - and not the End-User nor the Client - can be sure of knowing the extent of that information. More End-User control would require a different style of protocol than OAuth, such as self-sovereign identity."

--
James Manger

From: Denis <[email-masked]>
Sent: Tuesday, 12 May 2020 10:40 PM
To: Manger, James <[email-masked]>; Vittorio Bertocci <[email-masked]>
Cc: [email-masked]
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

[External Email] This email was sent from outside the organisation - be cautious, particularly with links and attachments.
Hi James,

You wrote: "Because your client has violated a MUST in the best practices". It seems that you are already taking your wish as granted.
However, this is exactly the point we are discussing.

You wrote: "The end-user has to trust the Authorization Server (they sign-in there)". The end-user does not trust the AS for everything,
but only with respect to some activities. Please remember a definition of trust present in ISO/IEC 13888-1. 3.59.
trust : relationship between two elements, a set of activities and a security policy in which element x trusts element y
if and only if x has confidence that y will behave in a well defined way (with respect to the activities) that does not violate
the given security policy.
You wrote: "The access-token might be a JWT with minimal claims". Yes indeed, however the end-user may not know it.

You wrote  "a client to do that inspection as standard behaviour". No, token inspection is not a standard behaviour.
It happens if, and only if, the end-user has some privacy concerns. Please reconsider the text proposal which does make
that point:
   There are however cases, where the access token content presents privacy issues for a given scenario. In such cases,
   the end-user would like to know which attributes have been placed in a token before forwarding it to a resource server.
   If these attributes do not correspond to the expectations of the end-user or if the format of the access token is not understandable
   by the client, then the client SHOULD NOT forward the access token to the resource server.

Denis

--
James Manger

From: OAuth <[email-masked]><mailto:[email-masked]> On Behalf Of Denis
Sent: Tuesday, 12 May 2020 7:55 PM
To: Vittorio Bertocci <[email-masked]><mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"
...
This being stated, hereafter is a full text proposal replacement for the first paragraph (12 lines)
of the Privacy Considerations section (section 6):

---

From: Denis <[email-masked]>
Date: Thu, 14 May 2020 18:29:24 +0200

Hi Vittorio,

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

1) You wrote:

    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:

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

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

> 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.
>
> 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.
>
> 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)…
>
> to contain [..]/
> (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:
>
> every generated token./
> 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.
>
> 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.
>

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Thu, 14 May 2020 14:02:30 -0400

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]> wrote:

> *> 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,
> 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*.
>
> 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
>    server might want to prevent correlation to preserve the desired level
> of privacy.
>
>    Although the ability to correlate requests might be required by design
> in many scenarios, there are scenarios where the authorization
>    situation.  For instance: if a solution requires preventing tracking
> principal activities across multiple resource servers,
> What should be discussed here are not "examples" or what an authorization
> server should do, but explanations about the implications
> a collusion between resource servers, but also with other servers that DO
> NOT participate in any OAuth exchange.
>
> 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
> 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
> 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,
> 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)…
>
> *> a client should be able to choose whether it wishes the sub claim to
> contain [..]*
>
> 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*
>
> 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.
>
> *From: *OAuth <[email-masked]> <[email-masked]> on behalf
> of Denis <[email-masked]> <[email-masked]>
> *To: *"[email-masked]" <[email-masked]> <[email-masked]> <[email-masked]>
> 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 :
>
> It is of a primary importance that clients MAY be able to inspect tokens
> before transmitting them.
> Reading the access token content may be useful for the user to verify that
> 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
> Currently, the request MUST include either a resource parameter or an aud
> claim parameter, while it MAY include a scope parameter.
>
> case-sensitive strings (RFC 6749). It is thus subject to private agreements
>    - 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.
>
> 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
> 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
> 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.
>
> 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
> that Authorization Servers will be unable to know which resources servers
> are being accessed.
> Servers to list all the Resource Servers being access by all its users and
> in addition to list pairs
> This is a second working group last call for "JSON Web Token (JWT) Profile
> for OAuth 2.0 Access Tokens".
>
>
>
> Here is the document:
>