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 <denis.i...@free.fr> 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 > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
