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. /T//he 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
