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

[Denis <[e-mail]>]

Hi Vittorio,

Thank you for your fast response.

You wrote:

    "/It doesn’t look very likely that an RS would simply accept tokens
    from an AS without some out of band negotiatio/n, "

and also:

    "/As far the client is concerned, the RS and the AS might switch
    their agreement/"

With such sentences, it seems that you mandate a direct negotiation 
between the AS and the RS which, by implication,
means that the AS and the RS must know each other, which is exactly what 
I want to avoid. Such some out of band negotiation
can simply be done by publishing which AT formats the AS is able to 
generate and which AT formats the RS is able to accept.
An AS can publish metadata relevant to the JWT access tokens it issues 
and a RS can do the same.

In this way, the client could consult both published lists and choose 
which common format, if any, would be appropriate.
This means that the client should be able in its AT request to specify 
the format of the AT, thus avoiding any direct some
out of band negotiation between the AS and the RS.

You continue saying:

    " /nor it seems very likely that an AS would issue tokens for
    resources it doesn’t know/".

This is where we have a major difference in our points of views. The 
number of AS is likely to be several order of magnitudes higher
compared to the number of RS. Every time a RS is being established, it 
should not have to make itself known to any AS.

This is why I wrote:

    /"a key point is that an AS and a RS DO NOT necessarily need to know
    each other. *The RS only needs to trust the AS*/*.*/(full stop)"/

You are assuming that an AS and a RS necessarily need to know each other.

You wrote:

    "/The scenario in which a token issuer isn’t aware of where the
    client will spend the corresponding token is important,
    but it is more the province of SSI than mainstream OAuth2 usage today"./

Today, as soon as an AT is targeted, the AS will be aware where the 
client is likely to spend the AT. The reality is that the scenario
in which a token issuer will not be aware of where the client will spend 
the corresponding token is today completely out of the scope
of OAuth2 usages (unfortunately, it is not a matter of mainstream or not).

For that reason, if the spec. continues to prevent to implement "Privacy 
by design" architectures and worse, mandates "Spy by design"
architectures, this should be clearly advertised in the Privacy 
Considerations section.

You recommend to specify the split AT structure I suggest in its own 
spec rather than in an interop profile for the general AT case.
The current title of the document is: "JSON Web Token (JWT) Profile for 
OAuth 2.0 Access Tokens". The content of the document
is much more than what the title implies since the introduction states :

    "Besides defining a common set of mandatory and optional claims, the
    profile provides clear indications on how determine the content of
    the issued JWT access token, how an authorization server can publish
    metadata relevant to the JWT access tokens it issues, and how
    a resource server should validate incoming JWT access tokens".

The document specifies a protocol with severe limitations in the 
authorization requests parameters and with severe limitations for the 
validation of AT.
If the spec. stays like that, it should rather be called:

  * "JSON Web Token (JWT) *Basic Protocol* for OAuth 2.0 Access Tokens" or
  * "JSON Web Token (JWT) *Basic Protocol and Profile* for OAuth 2.0
    Access Tokens".


In the future, a true Profile for OAuth 2.0 Access Tokens could then be 
written.

The case where a client would be able to inspect the content of a 
generated AT, indeed comes into contradiction with the case where the AS 
would encrypt
its content for the intended recipient and you advocate that it is 
another reason "for which the AS in the general case needs to know the 
intended recipient".
It is not the general case, but a specific case, which is more difficult 
to deploy than the simplest case where RS only need to know the AS that 
they trust.
It is a trade off /for the client/ to be able to inspect itself the AT 
of to make sure that only the RS will be able to inspect the AT.

I wrote:

    "This means that an identifier of the profile of the AT should be
    able to be included into the AT. This allows for future extensions."

You replied:

    "Can you expand on the exact scenario you are thinking of that calls
    for a version?"

Identifier formats for AT should be able to be included into :

  * the metadata published by the AS,
  * the metadata published by the RS, and
  * the AT itself.


The sketch of the scenario would be as follows.

The client consults both the metadata published by the AS and the 
metadata published by the RS and tries to find matches between token 
formats.
If there are several matches, it will choose,if possible, a match where 
it can access and understand the content of the AT. It will then inform 
the AS
of its choice by adding the identifier of the profile of the AT in the 
AT request. The AS will also include the identifier of the profile of 
the AT in the AT
so that the RS, when it receives the AT, can unambiguously decode the AT.

Finally, I will copy the end of your email.

     > Allowing a client to only specify a scope and a resource is very
    restrictive.
    Specifying scope or using resource indicators are all the mechanisms
    I am aware of that OAuth2 offers for specifying what an access token
    should be for - at least at the time in which the spec was incepted.
    (...) .

    What other interoperable mechanisms would you offer in addition to
    the ones listed here?

The client should be able to specify in its AT request additional 
attributes whose semantic is well described by the attributes description
found in section 5.1 of [OpenID.Core] or the attributes description 
found in [RFC7662] or other identity related specifications.

*Another new and last comment*: it is quite odd that there is no formal 
description of an AT profile anywhere in the current document.
A syntax description would greatly enhance interoperability.

Denis

> Hi Denis,
>
> Thank you for your feedback!
>
> Inline
>
> /> Privacy has not really been a concern in the WG since originally 
> the AT and the RS were co-located./
>
> Colocation of AS and RS was a frequent occurrence, but by no mean 
> mandatory… AFAIK one of the drivers for the changes between OAuth1 and 
> OAuth2 was providing the ability of supporting topologies where AS and 
> RS are distinct right out of the box.
>
> The scenario where AS and RS are distinct was always possible in 
> Outh2, and and not by accident. The JWT AT just happens to be 
> particularly handy in empowering the RS to validate incoming tokens 
> without having to phone home to the AS every time, hence it gives the 
> opportunity to discuss implications of that scenario more in depth, 
> but doesn’t really introduce anything that wasn’t possible before. 
> Even the possibility of a token format passing info by value isn’t 
> forbidden, default OAuth2 ATs are not mandatorily opaque- they just 
> happen not to have a well defined format.
>
> */>In such cases/*/, it is important to be able to make sure that an 
> authorization server will NOT be able to know where the authorizations
> tokens that it issues will be used. Using another wording, an AS SHALL 
> NOT be able to know where an AT requested by a given client will be used:
> *Authorization servers SHALL not have the capability to act as "Big 
> Brother"* and thus SHALL not be able to know which resources are going
> to be accessed by clients./
>
> The scenario in which a token issuer isn’t aware of where the client 
> will spend the corresponding token is important, but it is more the 
> province of SSI than mainstream OAuth2 usage today.
> Mainstream OAuth2 in current use, regardless of the AT format, 
> typically do know for whom the token is being issued: a great deal of 
> logic is predicated on that knowledge. Did the user consent for this 
> client to access this particular resource? Does access to this 
> resource warrant presenting a stronger authentication prompt? Are 
> there other authorization considerations that influences whether the 
> requested token should be issued? Those are considerations an AS need 
> to be able to perform in the general case, regardless of the AT 
> format. That doesn’t mean they MUST be done in every case, but making 
> them impossible would deny a lot of very important scenarios for which 
> JWT ATs (and ATs in general) are used for today.
>
> The split structure you suggest is interesting, but I would recommend 
> is enshrined in its own spec (maybe in the SSI orbit) rather than in 
> an interop profile for the general AT case.
>
> />On the contrary, a client SHALL be able to inspect the content of 
> the access token to make sure that the AS has not included in the AT 
> some private information
> that should not be present, before forwarding the AT to the RS. It is 
> possible for an AS to change the format of the AT, but the RS will not 
> necessarily be in synch
> with the RS.///
>
> I can see the value in doing what we can to prevent abuses, but I find 
> this requirement problematic. The access token is an artifact meant to 
> enable the client to access a resource. Its format remains a private 
> matter between the RS and the AS, which retains the freedom to change 
> it as they see fit without worrying about client code that takes a 
> dependency on characteristics of the AT that might very well be 
> transient. As far the client is concerned, the RS and the AS might 
> switch their agreement from JWT AT to opaque tokens to be validated 
> via introspection at any time, which would break any client side logic 
> inspecting the AT and expecting it to be a JWT. The client has no 
> control whatsoever on the content that is transmitted via opaque 
> token, hence privacy-wise the fact that the content of the JWT is 
> visible is more of a concern about such content being accessible on 
> the client. One additional point: even if clients would be able to 
> safely peek inside an AT without risking breaking their code, there’s 
> no guarantee that the client would understand the semantic of the 
> claims in the AT, as those are meant for consumption by the RS which 
> can assign any semantic to them; nor the client can reliably trust the 
> content of the claims, given that the AS could and sometimes will 
> encrypt their content for the intended recipient (another reason for 
> which the AS in the general case needs to know the intended recipient).
>
> />. It is possible for an AS to change the format of the AT, but the 
> RS will not necessarily be in synch with the RS. /
>
> I don’t understand this sentence. Is the last RS meant to be AS?
>
> Assuming that’s the case: It doesn’t look very likely that an RS would 
> simply accept tokens from an AS without some out of band negotiation, 
> nor it seems very likely that an AS would issue tokens for resources 
> it doesn’t know- see above. Such scenarios might exist, but they don’t 
> seem to model common business solutions or the typical deployment, 
> where an API will be protected by middleware/gateway with precise 
> assumptions on how to validate incoming tokens. There might be changes 
> that are inconsequential (order of claims, additional claims) but 
> anything more substantive would likely simply break the solution.
>
> /> This means that an identifier of the profile of the AT should be 
> able to be included into the AT. This allows for future extensions.///
>
> Can you expand on the exact scenario you are thinking of that calls 
> for a version? If it’s a matter of extensions, those should always be 
> possible – it’s more breaking changes that require versioning, but I 
> don’t recall precedents in similar specs.
>
> If this is aimed at mitigating the “AS changes format without telling 
> RS”, I don’t think that would work – besides of being unnecessary per 
> the above considerations, this wouldn’t protect the RS from changes 
> well within the current spec (which allows adding arbitrary claims as 
> long as it’s done according to JWT rules), from changes within the 
> claim content (eg private string formats) and from complete departures 
> from the use of JWT for ATs.
>
> />//Allowing a client to only specify a scope and a resource is very 
> restrictive./
>
> Specifying scope or using resource indicators are all the mechanisms I 
> am aware of that OAuth2 offers for specifying what an access token 
> should be for- at least at the time in which the spec was incepted. In 
> fact, resource indicators was not even RFC and in market vendors used 
> proprietary functional equivalents. What other interoperable 
> mechanisms would you offer in addition to the ones listed here?
>
> *From: *OAuth <[e-mail]> on behalf of Denis 
> <[e-mail]>
> *Date: *Thursday, April 9, 2020 at 09:26
> *To: *oauth <[e-mail]>
> *Subject: *Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for 
> OAuth 2.0 Access Tokens"
>
> I have three concerns, two of them being related to privacy.
>
> 1) Privacy has not really been a concern in the WG since originally 
> the AT and the RS were co-located. However, this draft now recognizes
> that there may exist cases where "the authorization server and 
> resource server are not co-located, are not ran by the same entity,
> or are otherwise separated by some boundary".
>
> *In such cases*, it is important to be able to make sure that an 
> authorization server will NOT be able to know where the authorizations
> tokens that it issues will be used. Using another wording, an AS SHALL 
> NOT be able to know where an AT requested by a given client will be used:
> *Authorization servers SHALL not have the capability to act as "Big 
> Brother"* and thus SHALL not be able to know which resources are going
> to be accessed by clients.
>
> This means that, in such cases, an authorization server SHALL not be 
> able to know for which resource server an AT has been targeted.
>
> It is a fact that most solutions currently deployed support a built-in 
> *"Spy by design"* architecture instead of a *"Privacy by design"* 
> architecture.
>
> However, for security reasons an AT still needs to be targeted.
>
> The problem to be solved is the following:
>
>   * for security reasons, the AT must be targeted.
>   * for privacy reasons, the AS must be kept ignorant of the name of
>     the target.
>
> One way to solve the problem is to consider that the AT is composed of 
> a sequence of two structures: a signed structure and an unsigned 
> structure.
>
> The signed structure contains a "salted aud claim".
> The unsigned structure contains a "aud salt claim".
>
> In practice, the "salted aud claim" will be composed of both a one way 
> hash function algorithm identifier and a hash value.
>
> Before requesting an AT to an AS, the client chooses a resource server 
> and select a resource indicator value corresponding to the identifier 
> the resource server.
> It then chooses a random value which it uses as a "aud salt claim" and 
> then computes a hash value by using a one-way hash function which 
> combines
> one of the resource indicators of the RS with the "aud salt claim". 
> Both the one way hash function algorithm identifier and the computed  
> hash value
> are then included into the "salted aud claim".
>
> The AT request then contains a "salted aud claim" instead of an"aud 
> claim". The AT blindly copies this value into the AT which is then 
> identified as
> a "salted aud claim" instead of an "aud claim".
>
> When the AT is received by the client, it adds to the AT the unsigned 
> part to the AT which contains the "aud salt claim" and sends both the 
> signed
> and the unsigned part of the AT to the RS.
>
> When the RS receives the AT, using the one way hash function algorithm 
> identifier contained in the "salted aud claim", it combines each of 
> its resource indicators
> with the "aud salt claim" contained in the unsigned part of the AT and 
> verifies whether it matches with the hash value contained in the 
> "salted aud claim".
> If none of these resource indicators is providing a match, then the RS 
> SHALL rejected the AT.
>
> The implication is to allow an AT to contain both a signed part and an 
> unsigned part.
>
> In addition, the "aud claim" should be multi-valued where, as a 
> consequence, both the "salted aud claim" with the "aud salt claim" 
> would also be multi-valued.
>
>
> 2) Within clause 6, "Privacy Considerations", the text states:
>
>    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 (...).
>
> On the contrary, a client SHALL be able to inspect the content of the 
> access token to make sure that the AS has not included in the AT some 
> private information
> that should not be present, before forwarding the AT to the RS. It is 
> possible for an AS to change the format of the AT, but the RS will not 
> necessarily be in synch
> with the RS.
>
> Since there are now cases where "the authorization server and resource 
> server are not co-located, are not ran by the same entity, or are 
> otherwise separated
> by some boundary", a key point is that an AS and a RS DO NOT 
> necessarily need to know each other. The RS only needs to trust the 
> AS. (full stop)
>
> This means that an identifier of the profile of the AT should be able 
> to be included into the AT. This allows for future extensions.
>
> In any case, the "MUST NOT" in the quoted sentence should be removed 
> or changed or the whole sentence should be removed..
>
>
> 3) Within clause 2.2.2 (second paragraph):
>
>    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.
>
> Allowing a client to only specify a scope and a resource is very 
> restrictive.
>
> What would be the title of an RFC that would allow the client to 
> request the presence of specific claims in JWT access ?
>
> If such a restriction is kept, would the current title of this RFC 
> still be inappropriate
> "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens" ?
>
> Denis
>
> DP Security Consulting
>