[Last-Call] Towards an RFC Errata to RFC 7662 ?

[Denis <[e-mail]>]

Hi Ben,

This new thread, i.e."Towards an RFC Errata to RFC 7662 ?" is used to 
discuss one of the topics raised in:
Last Call: <draft-ietf-oauth-jwt-introspection-response-09.txt> (JWT 
Response for OAuth Token Introspection) to Proposed Standard

Only the text relevant to this topic has been left.

The text that has been discussed and polished would perfectly fit into 
the Privacy Consideration section from RFC 7662.

Here it is again:

    Implementers should be aware that a token introspection request lets
    the AS know when the client is accessing the RS, which can also
    indicate when the user is using the client. If this implication is
    not acceptable, implementers can use other means to carry access
    token data, e.g. directly transferring the data needed by the RS
    within the access token.

Privacy considerations sections do not change the protocol but only 
provide some warnings. Warning the implementers is fine,
but warning the users and the clients should also be considered.

Thanks to your observations, I noticed that the sentence "thecall 
described in OAuth Introspection [RFC 7662] should be avoided"
is not appropriate.So I propose an additional text which is relevant for 
the users:

    Token introspection is an optional feature primarily intended for
    clients that are unable to support structured access tokens,
    including their validation. However, the use of this call allows an
    AS to track where and exactly when clients or users have indeed
    presented an issued access token to a RS.

    Some users or clients may be concerned that such a feature allows
    the AS to accurately trace them. If no Token introspection endpoint
    is published by an AS,
    users and clients can be confident that such tracing cannot happen.
    On the contrary, when an introspection_endpoint is published by an
    AS [RFC8414],
    users and clients have no way to know whether the RS will be allowed
    to use it, nor whether it will effectively use it.If these
    implications are not acceptable,
    users or clients should not use an AS that publishes an
    introspection_endpoint.

Denis

> Hi all,
>
> On Mon, Aug 31, 2020 at 09:58:11AM +0200, Denis wrote:
>> The last text that has been proposed on the list about this thread is
>> the following:
>>
>> Implementers should be aware that a token introspection request lets the AS know when the client is accessing the RS,
>> which can also indicate when the user is using the client.  If this implication is not acceptable, implementers can use
>> other means to carry access token data, e.g. directly transferring the data needed by the RS within the access token.
>>
>> The concerns of the implementers have nothing to do with the concerns of
>> the Users. Such a text proposal has nothing to do with a "User consent".
>>
>> *Towards an RFC Errata to RFC 7662*
>>
>> Mike Jones wrote:
>>
>> I agree with Dick’s observation about the privacy implications of using
>> an Introspection Endpoint. That’s why it’s preferable to not use one at all
>>         and instead directly have the Resource understand the Access
>> Token. One way of doing this is the JWT Access Token spec. There are
>> plenty of others.
>>
>> I fully agree.
>>
>> RFC 7662 should have incorporated a more detailed content such as:
>>
>>        In OAuth 2.0 [RFC6749], the contents of tokens are opaque to
>> clients. However, the contents of tokens is not intended to be opaque to
>> RSs.
>>        Token introspection is an OPTIONAL feature of an AS described in
>> OAuth Introspection [RFC 7662] intended for clients that are unable
>>        to support structured access tokens including their validation.
>> The use of this call allows an AS to track where and when its clients
>> have indeed
>>        presented an issued access token. As soon as the RS knows the
>> format of the access token, e.g. using structured token formats such as
>>        JWT [RFC7519], and is able to validate its security features, the
>> call described in OAuth Introspection [RFC 7662] should be avoided,
>> otherwise
>>        the AS will know exactly when the introspection call has been made
>> and thus be able to make sure which client has attempted perform an access
>>        to that RS and at which instant of time. As soon as this call is
>> supported by an AS, the client or the user have no way to prevent the RS
>> to use it.
>>
>> It might be useful to add it, e.g. using an RFC Errata.
> I do not believe this would be an appropriate usage of an Errata Report --
> it changes the meaning of the RFC away from what the WG intended at the
> time of publication.
>
> Use of tokens that are just opaque DB handles (along with some form of
> introspection) is desirable when a prominent threat is leakage of token
> contents from the browser.  We have had numerous discussions over the years
> of various ways in which information can leak from the browser, including
> history APIs, malicious javascript, and more.  While these threats are not
> always applicable in all deployment models, they are still present, just as
> the threats that you propose we defend against are not always of concern in
> all deployment models.  AFAICT, given the technologies currently available,
> there is not one universal solution that will address all concerns, and
> deployments will have to make a trade-off.  I think we need to acknowledge
> that there are different deployment models and that (for example) giving
> the user visibility into the token contents is not always desired, given
> the other risks that the current mechanisms for providing that visibility
> open up.
>
> -Ben
>
> P.S. your usage of the phrase "the User and his client" (below) suggests
> that you are still picturing the client as being local to the user, as is
> the case for, e.g., a TLS client or an IMAP client.  This is not the
> original model for an OAuth, where the client can just as well be a
> headless server in a cloud somewhere.
>