Hi Denis, On Wed, Sep 02, 2020 at 10:39:07AM +0200, Denis 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.
Thank you for starting a new thread. My apologies for taking so long to reply to it; I have not been entirely healthy for a couple weeks and many things have been left behind. I do agree with Justin that a document update is the best way to incorporate this kind of considerations -- with the caveat that generally Roman, as responsible AD for the WG, would be processing errata reports against the OAuth specs, if I was to be processing these proposals I would probably have to mark them as "Hold for Document Update" due to the need to ensure that they reflect WG consensus. One further note inline... > 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. I don't think that users and clients can be confident about this; AFAIK out-of-band configuration of an introspection endpoint is possible. -Ben > 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 OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
