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.
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
