Re: [GNAP] RS-Token Introspection or RC-Token Introspection

[Denis <[e-mail]>]

Hi Fabien,

> Hi Denis,
>
> Please note that the token introspection is not a new idea, it's 
> already present in OAuth2 world (rfc 7662), and allows the RS to 
> verify the access token.

I am pretty aware that token introspection is already present in the 
OAuth2 world (rfc 7662). :-)

In important point : RFC 7662 states "the contents of tokens are opaque 
to clients".
The text does _not_ state : "the contents of tokens are opaque to both 
clients and Resource Servers (RSs).


> In the current version of GNAP, there is also section 6 that 
> introduces management endpoints, which could potentially be extended 
> in a similar way (currently this is not specified, the management 
> endpoint is here for rotation/revocation). Then the client could 
> require more information on what is included in the opaque token, but 
> of course, this relies on the assumption that the client trusts the 
> AS. There is also the discussion on the "resource" description in the 
> response, that may provide a simpler scheme 
> (https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/141 
> <https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/141>).
> But if we assume the AS may be malevolent (which is more likely if the 
> AS becomes a less central point, at least for some implementations),
> then indeed receiving opaque tokens wouldn't provide all the 
> guarantees, as it may lie on what is really in the token (too many 
> claims for instance).

> More specifically, while I recon there might be a risk which we'd 
> rather not have, I don't really think an opaque token is really an 
> unmanageable issue with privacy.
> Suppose someone adds a field in a JWT, most likely you'll be able to 
> detect that.

RFC 7662 has been made available primarily for "lazy" RSs. :-)

Let us consider a case where the contents of access tokens are opaque to 
both RCs and RSs.

Let us suppose that opaque access tokens contains only a temporary 
handle to the set of claims related to the end-user, e.g. a 128 bits 
handle.

Neither the RC, nor the RS would be able to understand it and the RS 
would be forced to call back the AS.
Not only this call back will be bad in terms of the user's privacy 
because the AS will be able to know exactly when the access token has 
been used
by the end-user but it would be impossible to detect it to prevent some 
damage on the RS side.

We cannot assume that all future ASs in the world, while still providing 
the requested claims, will never deliver more attributes than the ones 
requested
by the RC and thus allow RSs (and possibly other servers) link their users.
>
> But suppose we go for non opaque tokens, then we'd need a way of 
> describing its format. Which might limit a bit the use cases if we're 
> not careful.

In OAuth 2.0, it has been possible to describe a token format (JSON Web 
Token (JWT) Profile for OAuth 2.0 Access Tokens).
I don't believe it would a "mission impossible" in this WG to describe a 
GNAP format for access tokens.

The IETF is supposed to standardize protocols at the bit level and this 
has made its success.

Denis

>
> I'd be interested to know what others think, since it is diverging 
> quite a bit from the OAuth2 world (not a bad thing in itself but still).
>
> Fabien
>
> On Fri, Dec 11, 2020 at 12:04 PM Denis <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     Hi Fabien,
>
>     This is a response only to the point 7 from the "Quick review of
>     draft-ietf-gnap-core-protocol-00".
>     The full original text with your comments is copied after my reply.
>
>     In order to allow the RC to understand the content of an opaque
>     token, you are proposing to support a Token Introspection query
>     from the RC to the AS.
>     This does not solve the concerns of a RC that wants to make sure
>     that the access token does not contain claims that have not been
>     requested.
>
>     Let us illustrate the case by using an example:
>
>     The RC asks to the AS to deliver an access token that contains an
>     identifier only unique to the RS.
>     In reality, the AS delivers an access token that does contain an
>     identifier only unique to the RS
>     but in addition a globally unique identifier. Since the access
>     token is supposed to be opaque to the RC,
>     the RC calls the AS to perform a Token Introspection operation. In
>     its response, the AS presents an identifier
>     that is indeed only unique to the RS but the AS voluntarily *omits
>     *to present the globally unique identifier to the RC.
>
>     In the same way, if Token Introspection is supported by a RS, that
>     does not provide confidence to the end-user or to the RC.
>
>     Let us illustrate the case by using another example:
>
>     The AS delivers to the RC an access token that only contains an
>     identifier unique to the RS. Since the access token
>     is supposed to be opaque to the RS, the RS calls the AS to perform
>     a Token Introspection operation. In its response,
>     the AS presents an identifier that is indeed only unique to the RS
>     but the AS voluntarily *adds *a globally unique identifier.
>
>     _Conclusion_: In both cases, a globally unique identifier will be
>     used by the RS without the RC or the end-user knowing it.
>                           Opaque tokens are in contradiction with the
>     end-user's privacy.
>
>     For end-users caring about their privacy (or for systems willing
>     to protect the user's privacy), access tokens should not be
>     considered
>     to be opaque to RCs, nor to RSs, and ASs should not support Token
>     Introspection, whether it is RS-Token Introspection or RC-Token
>     Introspection.
>
>     Denis
>
>
>>>                 7.The content and the format of access tokens shall
>>>                 not be considered to be opaque to the RC so that the
>>>                 RC can inspect it.
>>>                     This is a matter of confidence to make sure for
>>>                 the RC (and for the user) that no "extra"
>>>                 information has been included by the AS into the
>>>                 access token.
>>>
>>>         [FI] This might go a bit further than the GNAP's mandate
>>>         (especially if it becomes a mandatory requirement). But
>>>         supposing we support non-opaque tokens,
>>>         does it preclude supporting opaque tokens? It's just a
>>>         different trust model, which makes sense if people agree
>>>         with your premises (previous items),
>>>         but that are less relevant if people still consider the AS
>>>         as the central piece. Also one great thing with opaque
>>>         tokens is that it makes the system easier to upgrade
>>>         (you don't really care about what a token is).
>>
>>         [Denis] Privacy is not more relevant for an AS-centric model
>>         than for a RS-centric model. In particular, a RC should be
>>         able to verify which kind of end-user identifier claim
>>         has been incorporated into the access token by the AS, in
>>         particular whether it is globally unique, unique to the AS
>>         only, unique to the RS only or ephemeral (valid for
>>         that RS during a session with the AS).
>>
>>     [FI2] ok, see discussion on whether tokens should be opaque or not.
>>
>>         I suppose that the use of structured access tokens should be
>>         recommended. This means,in particular, that from the very
>>         beginning, we should incorporate a version number
>>         inside each access token.
>>
>>
>>>         One alternative way would be to allow RS call to AS for
>>>         verification (including revocation status) and include a
>>>         checksum.
>>
>>         [Denis]  The RC, i.e. not the RS, should be able to perform
>>         such verification before presenting the access token to the
>>         RS. So this alternative way would not work.
>>
>>     [FI2] then there could be a similar API for the client (cf
>>     discussion on similarities between introspection/management APIs).
>>
>
>     -- 
>     TXAuth mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/txauth
>     <https://www.ietf.org/mailman/listinfo/txauth>
>