Re: [OAUTH-WG] Towards an RFC Errata to RFC 7662 ?

[Justin Richer <[e-mail]>]

I’m not sure that adding this amount of text to the privacy considerations section is appropriate for an errata. If we wanted to do this, I believe we’d need to do a new revision of 7662.

 — Justin

> On Sep 2, 2020, at 4:39 AM, Denis <[e-mail]> wrote:
> 
> 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 "the call 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.
>> 
> 
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth