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 <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