> Token introspection is an optional feature primarily intended for clients
No. The abstract of RFC 7662 (OAuth Introspection) starts: This specification defines a method for a protected resource to query an OAuth 2.0 authorization server to determine the active state of an OAuth 2.0 token and to determine meta-information about this token Introspection is primarily for resource servers (RSs), not clients. Denis, you are putting a lot of effort into improving privacy handling in OAuth. But by repeatedly using the wrong terms and attributing actions to the wrong entities your suggested text is not usable. > If no Token introspection endpoint is published by an AS, users and clients can be confident that such tracing cannot happen Wow. That is a huge leap of faith. Any extra interactions between an RS & AS are somehow prevented (“cannot happen”) because AS metadata shown to another party (a client) is missing a URL? The whole point of RFC 7662 (as discussed in its introduction) is that various “proprietary inter-service communication mechanisms (such as shared databases and protected enterprise service buses)” have been developed to convey token info between AS & RS. So a standard could be helpful option for AS/RSs considering proprietary options. None of those proprietary mechanisms are mentioned in OAuth metadata published to clients. -- James Manger From: OAuth <[email protected]> On Behalf Of Denis Sent: Wednesday, 2 September 2020 6:39 PM To: Benjamin Kaduk <[email protected]> Cc: [email protected]; oauth <[email protected]>; Torsten Lodderstedt <[email protected]>; Mike Jones <[email protected]> Subject: [OAUTH-WG] Towards an RFC Errata to RFC 7662 ? [External Email] This email was sent from outside the organisation – be cautious, particularly with links and attachments. 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
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
