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

[Fabien Imbault <[e-mail]>]

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.

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

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.

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.

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]> 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]
> https://www.ietf.org/mailman/listinfo/txauth
>