Hi Denis, this aspect was debated at length (one example in https://mailarchive.ietf.org/arch/msg/oauth/OYgGsIa_4q8UYnl6SiGyvJ9Hnxw/, there are many others) and the consensus reflected in the current text was clear.
From: Denis <[email protected]> Sent: Wednesday, April 14, 2021 1:19 AM To: Vittorio Bertocci <[email protected]>; Murray Kucherawy <[email protected]>; The IESG <[email protected]> Cc: [email protected]; [email protected]; [email protected] Subject: Re: [OAUTH-WG] Murray Kucherawy's No Objection on draft-ietf-oauth-access-token-jwt-12: (with COMMENT) Hi Murray, Thank you for your comments. I come back on one of your comments (while other comments and Vittorio's responses are deleted): The first half of the second paragraph of Section 6 seems much more like an interoperability issue than a privacy issue to me. I agree that, taken in isolation, the connection to privacy of that aspect is not immediately self-evident. I would argue it is not about interop either, given that noncompliance with the guidance given there doesn’t impact what's transmitted. Nonetheless, I believe the privacy section is the closest match we have for that guidance, given its many touch points to privacy matters (the ability of a client to inspect ATs is a privacy concern; the decision to use a JWT ATs, which ultimately makes spelling out the guidance necessary, is influenced by privacy considerations; and so on and so forth). In sum, although I agree it's not a perfect fit, I think that's the best fit we have; and given that consolidating consensus for that part has been particularly painful, I am inclined to leave that part as is. The second paragraph of Section 6 (Privacy Considerations) is as follows: The client MUST NOT inspect the content of the access token: the authorization server and the resource server might decide to change token format at any time (for example by switching from this profile to opaque tokens) hence any logic in the client relying on the ability to read the access token content would break without recourse. The OAuth 2.0 framework assumes that access tokens are treated as opaque by clients. Administrators of authorization servers should also take into account that the content of an access token is visible to the client. Whenever client access to the access token content presents privacy issues for a given scenario, the authorization server should take explicit steps to prevent it. As soon as there is a MUST NOT, this is not a guidance any more. Some words of this paragraph, i.e. "any logic in the client relying on the ability to read the access token content" simply recognize that the client is able to inspect the content of the access token, but if it does it this is at its own risk since "the resource server might decide to change token format at any time (for example by switching from this profile to opaque tokens)". The second paragraph may be rewritten by placing in front of it an important sentence that comes later on in this paragraph: The OAuth 2.0 framework assumes that access tokens are treated as opaque by clients. Then after, the first sentence that includes the MUST NOT can be removed and the current text can be re-used after it, by shuffling the order of the remaining sentences. The end result would be the following: The OAuth 2.0 framework assumes that access tokens are treated as opaque by clients. Administrators of authorization servers should take into account that the content of an access token is visible to the client. The authorization server and the resource server might decide to change token format at any time (for example by switching from this profile to opaque tokens) hence any logic in the client relying on the ability to read the access token content would break without recourse. Whenever client access to the access token content presents privacy issues for a given scenario, the authorization server should take explicit steps to prevent it. The key benefits are the following: the guidance is still there, but the sentence with the "MUST NOT" has been removed. Denis
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
