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

["Manger, James" <[e-mail]>]

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 <[e-mail]>
Sent: Tuesday, 12 May 2020 10:40 PM
To: Manger, James <[e-mail]>; Vittorio Bertocci <[e-mail]>
Cc: [e-mail]
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

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 <[e-mail]><mailto:[e-mail]> On Behalf Of Denis
Sent: Tuesday, 12 May 2020 7:55 PM
To: Vittorio Bertocci <[e-mail]><mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
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