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

From: Murray Kucherawy via Datatracker <[email-masked]>
Date: Wed, 07 Apr 2021 23:22:21 -0700

Murray Kucherawy has entered the following ballot position for
draft-ietf-oauth-access-token-jwt-12: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-oauth-access-token-jwt/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

My co-AD pretty much nailed it.   I would go further and say that her comment
about "Why is this only SHOULD?" applies to a lot of the SHOULDs in here. 
SHOULD presents a choice; why might an implementer reasonably not do any of the
SHOULD things in here?

For readability, I suggest that the three registrations packed into Section
7.2.1 be separated somehow, as right now they appear to be one continuous
bullet list.  Separate subsections would work, or even just a line of prose
before each would suffice.

The first half of the second paragraph of Section 6 seems much more like an
interoperability issue than a privacy issue to me.

---

From: Vittorio Bertocci <[email-masked]>
Date: Wed, 14 Apr 2021 07:18:50 +0000

Hi Murray,
Thank you for your comments! Answers inline

>    SHOULD presents a choice; why might an implementer reasonably not do any of the
In line of principle, I agree- but that's where the consensus brought us. Many of the SHOULD you see in the current draft actually started as MUST, and the discussion drove toward them being relaxed. The technology we are trying to standardize here has been in production use for many years, hence there's a wealth of real world scenarios that influenced the debate.
For a more precise discussion, we should select specific instances: but for an example of typical circumstances that led toward SHOULD, the case discussed with Francesca is pretty typical.

 >   before each would suffice.
Great suggestion, thank you! I added sections for improved readability.

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

On 4/7/21, 23:22, "Murray Kucherawy via Datatracker" <[email-masked]> wrote:

---

From: Denis <[email-masked]>
Date: Wed, 14 Apr 2021 10:18:48 +0200

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

---

From: <[email-masked]>
Date: Wed, 14 Apr 2021 08:23:07 -0700

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-masked]> 
Sent: Wednesday, April 14, 2021 1:19 AM
To: Vittorio Bertocci <vittorio.bertocci=[email-masked]>; Murray Kucherawy <[email-masked]>; The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
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):

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

---

From: Denis <[email-masked]>
Date: Wed, 14 Apr 2021 17:39:09 +0200

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 <[email-masked]>
> *Sent:* Wednesday, April 14, 2021 1:19 AM
> *To:* Vittorio Bertocci 
> <vittorio.bertocci=[email-masked]>; Murray Kucherawy 
> <[email-masked]>; The IESG <[email-masked]>
> *Cc:* [email-masked]; 
> [email-masked]; [email-masked]
> *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):
>
> 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
> that's the best fit we have; and given that consolidating consensus 
> for that part has been particularly painful,
>    recourse. /The OAuth 2.0 framework assumes that access tokens are
>    treated as opaque by clients./  Administrators of authorization
> 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