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

[Fabien Imbault <[e-mail]>]

Hi Denis,

I created https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145 to
follow up on that.

Fabien

On Fri, Dec 11, 2020 at 7:12 PM Fabien Imbault <[e-mail]>
wrote:

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