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

[Denis <[e-mail]>]

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