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

[Denis <[e-mail]>]

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 vio­late
    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]> *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
>