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 "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.
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
