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

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

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]> On Behalf Of Denis
Sent: Tuesday, 12 May 2020 7:55 PM
To: 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"
...
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