Hi Vittorio,
Since Murray raised the concern, I have responded. A *guidance *section
should not contain any *MUST*, *SHALL*, *MUST *or *SHALL NOT.*
I believe that my proposal is a fair compromise on this topic by keeping
all the sentences, except the first half of the second paragraph
of Section 6, as noticed by Murray.
Denis
Hi Denis, this aspect was debated at length (one example in
https://mailarchive.ietf.org/arch/msg/oauth/OYgGsIa_4q8UYnl6SiGyvJ9Hnxw/
<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 <denis.i...@free.fr>
*Sent:* Wednesday, April 14, 2021 1:19 AM
*To:* Vittorio Bertocci
<vittorio.bertocci=40auth0....@dmarc.ietf.org>; Murray Kucherawy
<superu...@gmail.com>; The IESG <i...@ietf.org>
*Cc:* draft-ietf-oauth-access-token-...@ietf.org;
oauth-cha...@ietf.org; oauth@ietf.org
*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
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
