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 <oauth-boun...@ietf.org> On Behalf Of Denis
Sent: Tuesday, 12 May 2020 7:55 PM
To: Vittorio Bertocci <vittorio.berto...@auth0.com>
Cc: oauth@ietf.org
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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
