Re: [OAUTH-WG] Murray Kucherawy's No Objection on draft-ietf-oauth-access-token-jwt-12: (with COMMENT)

[Denis <[e-mail]>]

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