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

[Fabien Imbault <[e-mail]>]

Hi Denis,

I agree that what you're saying makes sense.

I'm just asking more broadly what people think of it (and trying to balance
the risks and benefits of each approach).

Fabien

On Fri, Dec 11, 2020 at 6:56 PM Denis <[e-mail]> wrote:

> 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).
>
> 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]> 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
>>
>
> --
> TXAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/txauth
>