Subject: [OAUTH-WG] draft-ietf-oauth-access-token-jwt-07

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 8 Sep 2020 06:29:32 +0000

Hi Victorio, Hi all,

I am doing my shepherd write-up for draft-ietf-oauth-access-token-jwt-07. Reading through the draft I have a few minor suggestions:

Section 2:

I would delete this sentence "JWT access tokens are regular JWTs complying with the requirements described in this section."

Reason: You pretty much make the same statement on the previous page (see terminology section).

Section 2.1

s/asymmetric algorithms/asymmetric cryptography
(same replacement in Section 4)

s/   This specification registers the "application/at+jwt" media type,
   which can be used to indicate that the content is an access token./This specification registers the "application/at+jwt" media type,
   which can be used to indicate that the content is a JWT access token.

Use capitalized "Section" when a section number is indicated, such as in Section 2.2.

Section 2.2

s/""aud"/"aud"

2.2.1

s/   auth_time  OPTIONAL - as defined in section 2 of [OpenID.Core]./   auth_time  OPTIONAL - as defined in Section 2 of [OpenID.Core].
s/   acr, amr  OPTIONAL - as defined in section 2 of [OpenID.Core]./   acr, amr  OPTIONAL - as defined in Section 2 of [OpenID.Core].

s/Please see/See

s/For example:/For example,

Section 4

You write:

"Authorization servers SHOULD implement OAuth 2.0 Authorization Server Metadata [RFC8414] ... "

Are you sure you mean "implement" and not "use"? The paragraph gives me the impression that you talk about "ASs using RFC 8414"

s/Please see section Section 5 for further guidance on security implications./Please see Section 5 for further guidance on security implications.

This sentence sounds strange to me:
"
   When invoked as described in OAuth 2.0 Bearer Token Usage [RFC6750],
   resource servers receiving a JWT access token MUST validate it in the
   following manner.
"

How about:
"
   Resource servers receiving a JWT access token MUST validate it in the
   following manner.
"

Question: If you refer to RFC 6750 and then list the steps are you just repeating the steps from RFC 6750 or are you augmenting them?

You write:

"
If the JWT access token includes authorization claims as described in
   the authorization claims section, the resource server SHOULD use them
   in combination with any other contextual information available to
   determine whether the current call should be authorized or rejected.
"

Include a reference to the authorization claims section

s/ For more
   details on cross-JWT confusion please refer to 2.8 of [RFC8725]./ For more
   details on cross-JWT confusion please refer to Section 2.8 of [RFC8725].

You write:

"
   Authorization servers should not rely on the use of different keys
   for signing OpenID Connect ID Tokens and JWT tokens as a method to
   safeguard against the consequences of leaking specific keys.
"

The phrase "leaking keys" is probably not the best term to describe what follows afterwards in the text.

You write:

"
The client MUST NOT inspect the content of
   the access token
"

This RFC 2119 language is not really enforceable in terms of interoperability. Maybe you could rephrase a bit. Something like the following would work:

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

You wrote:

"

   In scenarios in which JWT access tokens are accessible to the end
   user, it should be evaluated whether the information can be accessed
   without privacy violations (for example, if an end user would simply
   access his or her own personal information) or if steps must be taken
   to enforce confidentiality.  Possible measures include: encrypting
   the access token, encrypting the sensitive claims, omitting the
   sensitive claims or not using this profile, falling back on opaque
   access tokens.
"

The first sentence is a repetition of the previous paragraph. I would suggest to delete
the first sentence in this paragraph and to move the second sentence to the previous paragraph.

You wrote:

"
   This profile mandates the presence of the "sub" claim in every JWT
   access token, making it possible for resource servers to rely on that
   information for performing tasks such as correlating incoming
   requests with data stored locally for the authenticated principal.
   Although the ability to correlate requests might be required by
   design in many scenarios, there are scenarios where the authorization
   server might want to prevent correlation to preserve the desired
   level of privacy.  Authorization servers should choose how to assign
   "sub" values according to the level of privacy required by each
   situation.  For instance: if a solution requires preventing tracking
   principal activities across multiple resource servers, the
   authorization server should ensure that JWT access tokens meant for
   different resource servers have distinct "sub" values tht cannot be
   correlated in the event of resource servers collusion.  Similarly: if
   a solution requires preventing a resource server from correlating the
   principal's activity within the resource itself, the authorization
   server should assign different "sub" values for every JWT access
   token issued.  In turn, the client should obtain a new JWT access
   token for every call to the resource server, to ensure that the
   resource server receives different "sub" and "jti" values at every
   call, thus preventing correlation between distinct requests.
"

The above paragraph suggests that there are different levels of privacy. What you are
talking about in the text is unlinkability and identification. Ways to deal with such
privacy threats are described in Section 6 of RFC 6973.

Hence, I would suggest to slightly rephrase the paragraph to something like:

"
   This profile mandates the presence of the "sub" claim in every JWT
   access token, making it possible for resource servers to rely on that
   information for correlating incoming
   requests with data stored locally for the authenticated principal.
   Although the ability to correlate requests might be required by
   design in many scenarios, there are scenarios where the authorization
   server might want to prevent correlation. The "sub" claim should be
   populated by the authorization servers according to a privacy impact
   assessment. For instance, if a solution requires preventing tracking
   principal activities across multiple resource servers, the
   authorization server should ensure that JWT access tokens meant for
   different resource servers have distinct "sub" values that cannot be
   correlated in the event of resource servers collusion.  Similarly, if
   a solution requires preventing a resource server from correlating the
   principal's activity within the resource itself, the authorization
   server should assign different "sub" values for every JWT access
   token issued.  In turn, the client should obtain a new JWT access
   token for every call to the resource server, to ensure that the
   resource server receives different "sub" and "jti" values at every
   call, thus preventing correlation between distinct requests.
"

Section 7.2

s/   Section Section 2.2.3.1 of this specification refers to the
   attributes "roles", "groups", "entitlements" defined in [RFC7643] to
   express authorization information in JWT access tokens.
/   Section 2.2.3.1 of this specification refers to the
   attributes "roles", "groups", "entitlements" defined in [RFC7643] to
   express authorization information in JWT access tokens.

References

RFC 7519 has to be a normative reference:

   [RFC7519]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
              (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
              <https://www.rfc-editor.org/info/rfc7519>.

RFC 7644 is an unused reference:

   [RFC7644]  Hunt, P., Ed., Grizzle, K., Ansari, M., Wahlstroem, E.,
              and C. Mortimore, "System for Cross-domain Identity
              Management: Protocol", RFC 7644, DOI 10.17487/RFC7644,
              September 2015, <https://www.rfc-editor.org/info/rfc7644>.

The same is true for RFC 3986:

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, DOI 10.17487/RFC3986, January 2005,
              <https://www.rfc-editor.org/info/rfc3986>.

Ciao
Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Denis <[email-masked]>
Date: Tue, 8 Sep 2020 18:09:38 +0200

Hi Hannes,

Two comments between the lines.

> Hi Victorio, Hi all,
>
> I am doing my shepherd write-up for 
> draft-ietf-oauth-access-token-jwt-07. Reading through the draft I have 
> a few minor suggestions:
>
> Section 2:
>
> I would delete this sentence "JWT access tokens are regular JWTs 
> complying with the requirements described in this section."
>
>    which can be used to indicate that the content is an access 
> token./This specification registers the "application/at+jwt" media type,
>
> s/   auth_time  OPTIONAL - as defined in section 2 of 
> [OpenID.Core]./   auth_time  OPTIONAL - as defined in Section 2 of 
> [OpenID.Core].
>
> s/   acr, amr  OPTIONAL - as defined in section 2 of [OpenID.Core]./   
> acr, amr  OPTIONAL - as defined in Section 2 of [OpenID.Core].
>
> s/Please see/See
>
> Are you sure you mean "implement" and not "use"? The paragraph gives 
> me the impression that you talk about "ASs using RFC 8414"
>
> s/Please see section Section 5 for further guidance on security 
> implications./Please see Section 5 for further guidance on security 
> implications.
>
> Question: If you refer to RFC 6750 and then list the steps are you 
> just repeating the steps from RFC 6750 or are you augmenting them?
>
> You write:
>
> "
>
> This RFC 2119 language is not really enforceable in terms of 
> interoperability. Maybe you could rephrase a bit. Something like the 
> following would work:
>
> "
>
/In the general case, /the OAuth 2.0 framework assumes that access 
tokens are treated as opaque by clients.
However, with this coming RFC, we are not in the general case: since the 
client gets back an access token conformant to _this_ RFC, then it knows
exactly its detailed structure. The argument about "changing the token 
format at any time" does not apply. In this case, the client is quite sure
that it would be able to understand most of its content (at least all 
the standard claims). The above text proposal would need to be reconsidered.

Hiding (by encrypting it) the content of the access token to the client 
is odd when an access token contains claims about a human-user :
these claims are personal data and the human-user is usually allowed to 
have access to his own personal data.

Encryption is nice in theory but complicated in practice, since a key 
management system must put in place. Whenever possible, it should be 
avoided.

BTW, some questions raised during the WGLC have not been answered: How 
can a client request an access token compliant to this profile ?
Which parameter(s) allow it to ask an access token compliant to this 
profile ? How can the AS know that it got a call for the issuance of an 
access token
compliant to this profile ?

Another comment follows.

>    correlated in the event of resource servers collusion.
>
While the idea is really nice, the use of the "sub" claim in this 
context is not compatible with the definition of the "sub" claim
as defined in RFC 7519:

      4.1.2.  "sub" (Subject) Claim

         The "sub" (subject) claim identifies the principal that is the
         subject of the JWT.  The claims in a JWT are normally statements
         about the subject. *The subject value MUST either be scoped to be**
**        locally unique in the context of the issuer or be globally 
unique.*
         The processing of this claim is generally application 
specific.  The
         "sub" value is a case-sensitive string containing a StringOrURI
         value.  Use of this claim is OPTIONAL.

There are two options and two options only:

    "locally unique in the context of the issuer" means that it is the
    same for all RSs.
    "globally unique" means that it is the same not only for all the RSs
    but also for servers that have nothing to do with OAuth (e.g. an
    email address).

>     Similarly, if
The proposed text describes two different cases where the sub claim is 
either unique for an AS/RS pair orunique for each access token.

These two cases are not included in the definition found in RFC 7519.

In the general case, an identifier can be:

 1. locally unique in the context of the issuer (i.e. the same for all RSs),
 2. globally unique (i.e. the same not only for all the RSs but also for
    servers that have nothing to do with OAuth),
 3. unique for an AS/RS pair, or
 4. unique for each access token.

I see different ways to solve this problem:

    1° Stick to the definition of RFC 7519 and (unfortunately) remove
    these possibilities.
    2° Define two new claims which would support the two cases where the
    sub claim would be either unique for an AS/RS pair orunique for one
    access token.
    3° Define four new claims which would support the four above cases.

Denis

> IMPORTANT NOTICE: The contents of this email and any attachments are 
> confidential and may also be privileged. If you are not the intended 
> recipient, please notify the sender immediately and do not disclose 
> the contents to any other person, use it for any purpose, or store or 
> copy the information in any medium. Thank you.
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Dick Hardt <[email-masked]>
Date: Tue, 8 Sep 2020 09:26:06 -0700

Denis

The objective of this document is to standardize the token the AS shares
with the RS. It is not to standardize how the client can read the token.
Just because the user is using the client, that does not mean the user
wants the client to see any claims about themselves. Letting the client see
the contents of the token may be a privacy violation.

client != user
ᐧ

On Tue, Sep 8, 2020 at 9:10 AM Denis <[email-masked]> wrote:

> I am doing my shepherd write-up for draft-ietf-oauth-access-token-jwt-07.
> Reading through the draft I have a few minor suggestions:
>
>
>
> Section 2:
>
>
>
> I would delete this sentence "JWT access tokens are regular JWTs complying
> with the requirements described in this section."
>
>
>
>    which can be used to indicate that the content is an access token./This
> specification registers the "application/at+jwt" media type,
>
> s/   auth_time  OPTIONAL - as defined in section 2 of [OpenID.Core]./
> auth_time  OPTIONAL - as defined in Section 2 of [OpenID.Core].
>
> Are you sure you mean "implement" and not "use"? The paragraph gives me
> the impression that you talk about "ASs using RFC 8414"
>
>
>
>
>
> Question: If you refer to RFC 6750 and then list the steps are you just
> repeating the steps from RFC 6750 or are you augmenting them?
>
>
>
>
>
> You write:
>
>
>
> "
>
> *In the general case, *the OAuth 2.0 framework assumes that access tokens
> are treated as opaque by clients.
> client gets back an access token conformant to *this* RFC, then it knows
> that it would be able to understand most of its content (at least all the
> standard claims). The above text proposal would need to be reconsidered.
>
> BTW, some questions raised during the WGLC have not been answered: How can
> a client request an access token compliant to this profile ?
> While the idea is really nice, the use of the "sub" claim in this context
> is not compatible with the definition of the "sub" claim
> as defined in RFC 7519:
>
>         about the subject.  *The subject value MUST either be scoped to
> be*
> *        locally unique in the context of the issuer or be globally
> unique.*
>         The processing of this claim is generally application specific.
> The
> "locally unique in the context of the issuer" means that it is the same
> for all RSs.
> "globally unique" means that it is the same not only for all the RSs but
> also for servers that have nothing to do with OAuth (e.g. an email address).
>
>
>     Similarly, if
>
> either unique for an AS/RS pair or unique for each access token.
>
>    2. globally unique (i.e. the same not only for all the RSs but also
>    for servers that have nothing to do with OAuth),
> 1° Stick to the definition of RFC 7519 and (unfortunately) remove these
> possibilities.
> 2° Define two new claims which would support the two cases where the sub
> claim would be either unique for an AS/RS pair or unique for one access
> token.
>               <https://www.rfc-editor.org/info/rfc7519>
>               September 2015, <https://www.rfc-editor.org/info/rfc7644>
> <https://www.rfc-editor.org/info/rfc7644>.
>
>
>
>               <https://www.rfc-editor.org/info/rfc3986>
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
>
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>

---

From: <[email-masked]>
Date: Tue, 8 Sep 2020 23:03:54 -0700

Thanks Hannes!

I will go thru the comments and update accordingly by EoW.

From: OAuth <[email-masked]> On Behalf Of Hannes Tschofenig
Sent: Monday, September 7, 2020 11:30 PM
To: [email-masked]
Subject: [OAUTH-WG] draft-ietf-oauth-access-token-jwt-07

Hi Victorio, Hi all, 

Section 2: 

Reason: You pretty much make the same statement on the previous page (see
terminology section). 

Section 2.1

Use capitalized "Section" when a section number is indicated, such as in
Section 2.2.   

Section 2.2

s/""aud"/"aud"

2.2.1

s/   acr, amr  OPTIONAL - as defined in section 2 of [OpenID.Core]./   acr,
amr  OPTIONAL - as defined in Section 2 of [OpenID.Core].

s/Please see/See 

Section 4

You write: 

"Authorization servers SHOULD implement OAuth 2.0 Authorization Server
Metadata [RFC8414] ... "

Are you sure you mean "implement" and not "use"? The paragraph gives me the
impression that you talk about "ASs using RFC 8414"

"

   following manner.

"

How about: 

"

   following manner.

"

 

You write: 

"

"

 

s/ For more

   details on cross-JWT confusion please refer to 2.8 of [RFC8725]./ For
more

   

You write: 

"

"

The phrase "leaking keys" is probably not the best term to describe what
follows afterwards in the text. 

You write:

"

   the access token

"

"   

   break without recourse. The OAuth 2.0 framework assumes that access
tokens 

   Administrators of authorization servers should also take into account
that 

   to prevent it.   

"

You wrote: 

"

   access tokens.

"

The first sentence is a repetition of the previous paragraph. I would
suggest to delete

the first sentence in this paragraph and to move the second sentence to the
previous paragraph. 

You wrote: 

"

"

The above paragraph suggests that there are different levels of privacy.
What you are 

talking about in the text is unlinkability and identification. Ways to deal
with such 

"

"

Section 7.2

  

References

 

 

Ciao

Hannes

---

From: Denis <[email-masked]>
Date: Wed, 9 Sep 2020 10:41:49 +0200

Hi Dick and Hannes,

1)  While reading RFC 7519, no reader may be able to figure out that 
there are more than two flavours of the "sub" claim.
      This draft is introducing two new other favours of the semantics 
of the "sub" claim which are not present in RFC 7519.
      When an element has been defined, its semantics cannot be changed 
... unless making an Errata to RFC 7519
      which would be a clean way to proceed.

2) The argument about "changing the token format at any time" does not 
apply in the context of this future RFC.
     This sentence should be either removed or modified  This means that 
the following sentence which is a derivative
     of this sentence should also be either removed or modified:

    Hence, any logic in the client relying on the ability to read the
    access token content would break without recourse.

3) The following questions have still not been answered:

    Some questions raised during the WGLC have not been answered: How
    can a client request an access token compliant to this profile ?
    Which parameter(s) allow it to ask an access token compliant to this
    profile ? How can the AS know that it got a call for the issuance
    of an access token compliant to this profile ?

Denis

> Denis
>
>
> The objective of this document is to standardize the token the AS 
> shares with the RS. It is not to standardize how the client can read 
> the token. Just because the user is using the client, that does not 
> mean the user wants the client to see any claims about themselves. 
> Letting the client see the contents of the token may be a privacy 
> violation.
>
> client != user
> ᐧ
>
> On Tue, Sep 8, 2020 at 9:10 AM Denis <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi Hannes,
>
>>     draft-ietf-oauth-access-token-jwt-07. Reading through the draft I
>>     have a few minor suggestions:
>>
>>     Section 2:
>>
>>     s/   acr, amr  OPTIONAL - as defined in section 2 of
>>     [OpenID.Core]./   acr, amr OPTIONAL - as defined in Section 2 of
>>     [OpenID.Core].
>>
>>     s/Please see/See
>>
>>     Are you sure you mean "implement" and not "use"? The paragraph
>>     gives me the impression that you talk about "ASs using RFC 8414"
>>
>>     implications./Please see Section 5 for further guidance on
>>     security implications.
>>
>>     Question: If you refer to RFC 6750 and then list the steps are
>>     you just repeating the steps from RFC 6750 or are you augmenting
>>     them?
>>
>>     You write:
>>
>>     "
>>
>>     The phrase "leaking keys" is probably not the best term to
>>     describe what follows afterwards in the text.
>>
>>     You write:
>>
>>     "
>>
>>     interoperability. Maybe you could rephrase a bit. Something like
>>     the following would work:
>>
>>     "
>>
>     However, with this coming RFC, we are not in the general case:
>     since the client gets back an access token conformant to _this_
>     RFC, then it knows
>     exactly its detailed structure. The argument about "changing the
>     token format at any time" does not apply. In this case, the client
>     is quite sure
>     that it would be able to understand most of its content (at least
>     all the standard claims). The above text proposal would need to be
>     reconsidered.
>
>     Hiding (by encrypting it) the content of the access token to the
>     client is odd when an access token contains claims about a
>     human-user :
>     these claims are personal data and the human-user is usually
>     allowed to have access to his own personal data.
>
>     Encryption is nice in theory but complicated in practice, since a
>     key management system must put in place. Whenever possible, it
>     should be avoided.
>
>     BTW, some questions raised during the WGLC have not been answered:
>     How can a client request an access token compliant to this profile ?
>     Which parameter(s) allow it to ask an access token compliant to
>     this profile ? How can the AS know that it got a call for the
>     issuance of an access token
>>     Similarly: if
>     **        locally unique in the context of the issuer or be
>     globally unique.*
>         "locally unique in the context of the issuer" means that it is
>         the same for all RSs.
>         "globally unique" means that it is the same not only for all
>         the RSs but also for servers that have nothing to do with
>         OAuth (e.g. an email address).
>
>
>>         Similarly, if
>>
>     The proposed text describes two different cases where the sub
>     claim is either unique for an AS/RS pair orunique for each access
>     token.
>
>      2. globally unique (i.e. the same not only for all the RSs but
>         also for servers that have nothing to do with OAuth),
>         1° Stick to the definition of RFC 7519 and (unfortunately)
>         remove these possibilities.
>         2° Define two new claims which would support the two cases
>         where the sub claim would be either unique for an AS/RS pair
>         orunique for one access token.
>>     IMPORTANT NOTICE: The contents of this email and any attachments
>>     are confidential and may also be privileged. If you are not the
>>     intended recipient, please notify the sender immediately and do
>>     not disclose the contents to any other person, use it for any
>>     purpose, or store or copy the information in any medium. Thank you.
>>
>>     [email-masked]  <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 9 Sep 2020 15:14:57 +0000

We have gone through this discussion before. This document does not change the underlying assumptions of the OAuth 2.0 framework. In that framework the client is neither supposed to look at the access token content nor does it request the claims to comply to a specific profile.

I am planning to add a note about this disagreement into the shepherd write-up. I don’t think there is more that can be done given that there is no support in this group for changing the architectural assumptions of OAuth 2.0.

I believe that this is a topic should be brought to the Grant Negotiation and Authorization Protocol (gnap) working group instead.

Ciao
Hannes

From: Dick Hardt <[email-masked]>
Sent: Tuesday, September 8, 2020 6:26 PM
To: Denis <[email-masked]>
Cc: Hannes Tschofenig <[email-masked]>; [email-masked]
Subject: Re: [OAUTH-WG] draft-ietf-oauth-access-token-jwt-07

Denis

The objective of this document is to standardize the token the AS shares with the RS. It is not to standardize how the client can read the token. Just because the user is using the client, that does not mean the user wants the client to see any claims about themselves. Letting the client see the contents of the token may be a privacy violation.

client != user
ᐧ

On Tue, Sep 8, 2020 at 9:10 AM Denis <mailto:[email-masked]> wrote:
Hi Hannes,

Hi Victorio, Hi all,

Section 2:

Section 2.1

Section 2.2

s/""aud"/"aud"

2.2.1

s/Please see/See

Section 4

You write:

How about:
"

You write:

"

s/ For more

You write:

"

You write:

"

"

In the general case, the OAuth 2.0 framework assumes that access tokens are treated as opaque by clients.
However, with this coming RFC, we are not in the general case: since the client gets back an access token conformant to this RFC, then it knows
exactly its detailed structure. The argument about "changing the token format at any time" does not apply. In this case, the client is quite sure
that it would be able to understand most of its content (at least all the standard claims). The above text proposal would need to be reconsidered.

Hiding (by encrypting it) the content of the access token to the client is odd when an access token contains claims about a human-user :
these claims are personal data and the human-user is usually allowed to have access to his own personal data.
Encryption is nice in theory but complicated in practice, since a key management system must put in place. Whenever possible, it should be avoided.
BTW, some questions raised during the WGLC have not been answered: How can a client request an access token compliant to this profile ?
Which parameter(s) allow it to ask an access token compliant to this profile ? How can the AS know that it got a call for the issuance of an access token
compliant to this profile ?
Another comment follows.
You wrote:

"

You wrote:

"

"
While the idea is really nice, the use of the "sub" claim in this context is not compatible with the definition of the "sub" claim
as defined in RFC 7519:

        The "sub" (subject) claim identifies the principal that is the
        subject of the JWT.  The claims in a JWT are normally statements
        about the subject.  The subject value MUST either be scoped to be
        locally unique in the context of the issuer or be globally unique.
        The processing of this claim is generally application specific.  The
        "sub" value is a case-sensitive string containing a StringOrURI
        value.  Use of this claim is OPTIONAL.
There are two options and two options only:
"locally unique in the context of the issuer" means that it is the same for all RSs.
"globally unique" means that it is the same not only for all the RSs but also for servers that have nothing to do with OAuth (e.g. an email address).

    Similarly, if
   a solution requires preventing a resource server from correlating the
   principal's activity within the resource itself, the authorization
   server should assign different "sub" values for every JWT access
   token issued.  In turn, the client should obtain a new JWT access
   token for every call to the resource server, to ensure that the
   resource server receives different "sub" and "jti" values at every
   call, thus preventing correlation between distinct requests.
The proposed text describes two different cases where the sub claim is either unique for an AS/RS pair or unique for each access token.
These two cases are not included in the definition found in RFC 7519.
In the general case, an identifier can be:
1. locally unique in the context of the issuer (i.e. the same for all RSs),
2. globally unique (i.e. the same not only for all the RSs but also for servers that have nothing to do with OAuth),
3. unique for an AS/RS pair, or
4. unique for each access token.
I see different ways to solve this problem:
1° Stick to the definition of RFC 7519 and (unfortunately) remove these possibilities.
2° Define two new claims which would support the two cases where the sub claim would be either unique for an AS/RS pair or unique for one access token.
3° Define four new claims which would support the four above cases.
Denis
"

Section 7.2

References

   [RFC7519]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
              (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
              https://www.rfc-editor.org/info/rfc7519.

   [RFC7644]  Hunt, P., Ed., Grizzle, K., Ansari, M., Wahlstroem, E.,
              and C. Mortimore, "System for Cross-domain Identity
              Management: Protocol", RFC 7644, DOI 10.17487/RFC7644,
              September 2015, https://www.rfc-editor.org/info/rfc7644.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, DOI 10.17487/RFC3986, January 2005,
              https://www.rfc-editor.org/info/rfc3986.

Ciao
Hannes

mailto:[email-masked]

mailto:[email-masked]

---

From: Denis <[email-masked]>
Date: Wed, 9 Sep 2020 17:21:46 +0200

Hannes,

Since you are planning to write a shepherd write-up, please do not omit 
to mention the last three points mentioned in my previous email:

Denis

> "Authorization servers SHOULD implement OAuth 2.0 Authorization Server Metadata [RFC8414] ..."
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 10 Sep 2020 06:02:03 +0000

Hi Denis,

Hi Dick and Hannes,

1)  While reading RFC 7519, no reader may be able to figure out that there are more than two flavours of the "sub" claim.
     This draft is introducing two new other favours of the semantics of the "sub" claim which are not present in RFC 7519.
     When an element has been defined, its semantics cannot be changed ... unless making an Errata to RFC 7519
     which would be a clean way to proceed.

[Hannes] What do you mean by “flavours” of the subject claim?

2) The argument about "changing the token format at any time" does not apply in the context of this future RFC.
    This sentence should be either removed or modified  This means that the following sentence which is a derivative
    of this sentence should also be either removed or modified:
Hence, any logic in the client relying on the ability to read the access token content would break without recourse.

[Hannes] The OAuth 2.0 architecture allows the authorization server and the resource server to agree on whatever token format they want. They can pass the information by value or by reference (which may then require token introspection or an equivalent mechanism). This document does not change anything concern this.

Imagine a third party implementing an OAuth 2.0 Client. If they make assumptions about the ability to parse the content of the token, we create a brittle system.

For this reason, the sentence "changing the token format at any time" is correct.

I hope this makes sense.

3) The following questions have still not been answered:
Some questions raised during the WGLC have not been answered: How can a client request an access token compliant to this profile ?

[Hannes] The client cannot request the authorization server to use a specific token format. Since the client is not going to look at the access token content why would it even care.

Which parameter(s) allow it to ask an access token compliant to this profile ?

[Hannes] There no parameters defined so that the client can ask for an access token format that is compliant to this profile.

How can the AS know that it got a call for the issuance
of an access token compliant to this profile ?

[Hannes] The AS only gets a request for an access token and the AS needs to decide what format to use, like it did in the past. Nothing changed.

Ciao
Hannes

Denis

Denis

client != user
ᐧ

On Tue, Sep 8, 2020 at 9:10 AM Denis <[email-masked]<mailto:[email-masked]>> wrote:
Hi Hannes,

Hi Victorio, Hi all,

Section 2:

Section 2.1

Section 2.2

s/""aud"/"aud"

2.2.1

s/Please see/See

Section 4

You write:

How about:
"

You write:

"

s/ For more

You write:

"

You write:

"

"

Another comment follows.
You wrote:

"

You wrote:

"

"

    Similarly, if

Denis
"

Section 7.2

References

   [RFC7519]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
              (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
              <https://www.rfc-editor.org/info/rfc7519><https://www.rfc-editor.org/info/rfc7519>.

   [RFC7644]  Hunt, P., Ed., Grizzle, K., Ansari, M., Wahlstroem, E.,
              and C. Mortimore, "System for Cross-domain Identity
              Management: Protocol", RFC 7644, DOI 10.17487/RFC7644,
              September 2015, <https://www.rfc-editor.org/info/rfc7644><https://www.rfc-editor.org/info/rfc7644>.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, DOI 10.17487/RFC3986, January 2005,
              <https://www.rfc-editor.org/info/rfc3986><https://www.rfc-editor.org/info/rfc3986>.

Ciao
Hannes

OAuth mailing list

[email-masked]<mailto:[email-masked]>

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: Denis <[email-masked]>
Date: Thu, 10 Sep 2020 11:40:51 +0200

Hi Hannes,

Thank you for responses. See below.

> This draft is introducing two new other favours of the semantics of 
> the "sub" claim which are not present in RFC 7519.
[Denis] RFC 7519 states: The subject value MUST *either *be scoped to be 
locally unique in the context of the issuer *or *be globally unique.

This makes two flavours: *either *locally unique in the context of the 
issuer *or *globally unique.

When reading the current text, in addition to these two flavours, two 
additional flavours (3) and (4) are discovered
which makes a total of four flavours:

 1. locally unique in the context of the issuer (i.e. the same for all RSs),
 2. globally unique (i.e. the same not only for all the RSs but also for
    servers that have nothing to do with OAuth),
 3. unique for an AS/RS pair, and
 4. unique for every access token.

>     [Hannes] The OAuth 2.0 architecture allows the authorization
>     server and the resource server to agree on whatever token format
>     they want.
>     They can pass the information by value or by reference (which may
>     then require token introspection or an equivalent mechanism).
>     This document does not change anything concern this.
>
>     Imagine a third party implementing an OAuth 2.0 Client. If they
>     make assumptions about the ability to parse the content of the
>     token, we create a brittle system.
>
[Denis] I do not dispute the sentence you proposed "The OAuth 2.0 
framework assumes that access tokens are treated opaque by clients"
which replaces the previous sentence which was: "The client MUST NOT 
inspect the content of the access token".

The two sentences prior to it are:

    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.

Once having read your last three responses, I would propose the 
following small change in the second sentence:/
/

    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 /at an instant of time might /break /later on/
    without recourse.

>     [Hannes] The client cannot request the authorization server to use
>     a specific token format. Since the client is not going to look at
>     the access token content why would it even care.
>
[Denis] While reading all of your three last responses, I now understand 
the point.

>     this profile ?
>     [Hannes] There no parameters defined so that the client can ask
>     for an access token format that is compliant to this profile.
>
OK.
>
>     How can the AS know that it got a call for the issuance of an
>     access token compliant to this profile ?
>
>     [Hannes] The AS only gets a request for an access token and the AS
>     needs to decide what format to use, like it did in the past.
>     Nothing changed.
>
Your response does help to understand. Section 3 is stating:

    An authorization server /can /issue a JWT access token in response 
to any authorization grant defined by [RFC6749] and
    subsequent extensions meant to result in an access token.

I believe, it would be worthwhile to add a sentence, just after this 
sentence, with the following text:

    When an authorization server decides to issue a JWT access token 
compliant to this profile, then the following requirements apply.
    (...)

Denis
>     shares with the RS. It is not to standardize how the client can
>     read the token. Just because the user is using the client, that
>     does not mean the user wants the client to see any claims about
>     themselves. Letting the client see the contents of the token may
>     be a privacy violation.
>
>     client != user
>
>     ᐧ
>
>             draft-ietf-oauth-access-token-jwt-07. Reading through the
>             draft I have a few minor suggestions:
>
>             Section 2:
>
>             I would delete this sentence "JWT access tokens are
>             regular JWTs complying with the requirements described in
>             this section."
>
>             which can be used to indicate that the content is an
>             access token./This specification registers the
>             "application/at+jwt" media type,
>
>             [OpenID.Core]./   auth_time  OPTIONAL - as defined in
>             Section 2 of [OpenID.Core].
>
>             [OpenID.Core]./   acr, amr  OPTIONAL - as defined in
>             Section 2 of [OpenID.Core].
>
>             s/Please see/See
>
>             "Authorization servers SHOULD implement OAuth 2.0
>             Authorization Server Metadata [RFC8414] ... "
>
>             Are you sure you mean "implement" and not "use"? The
>             paragraph gives me the impression that you talk about "ASs
>             using RFC 8414"
>
>             s/Please see section Section 5 for further guidance on
>             security implications./Please see Section 5 for further
>             guidance on security implications.
>
>             Question: If you refer to RFC 6750 and then list the steps
>             are you just repeating the steps from RFC 6750 or are you
>             augmenting them?
>
>             You write:
>
>             "
>
>             This RFC 2119 language is not really enforceable in terms
>             of interoperability. Maybe you could rephrase a bit.
>             Something like the following would work:
>
>             "
>
>         /In the general case, /the OAuth 2.0 framework assumes that
>         access tokens are treated as opaque by clients.
>         since the client gets back an access token conformant to
>         _this_ RFC, then it knows
>         exactly its detailed structure. The argument about "changing
>         the token format at any time" does not apply. In this case,
>         the client is quite sure
>         that it would be able to understand most of its content (at
>         least all the standard claims). The above text proposal would
>         need to be reconsidered.
>
>         Hiding (by encrypting it) the content of the access token to
>         the client is odd when an access token contains claims about a
>         human-user :
>         Encryption is nice in theory but complicated in practice,
>         since a key management system must put in place. Whenever
>         possible, it should be avoided.
>
>         BTW, some questions raised during the WGLC have not been
>         answered: How can a client request an access token compliant
>         to this profile ?
>         Which parameter(s) allow it to ask an access token compliant
>         to this profile ? How can the AS know that it got a call for
>         the issuance of an access token
>             the first sentence in this paragraph and to move the
>             second sentence to the previous paragraph.
>
>             You wrote:
>
>             "
>
>         While the idea is really nice, the use of the "sub" claim in
>         this context is not compatible with the definition of the
>         "sub" claim
>         as defined in RFC 7519:
>
>                 about the subject. *The subject value MUST either be
>         scoped to be
>                 locally unique in the context of the issuer or be
>         globally unique.*
>             "globally unique" means that it is the same not only for
>             all the RSs but also for servers that have nothing to do
>             with OAuth (e.g. an email address).
>
>
>
>             Similarly, if
>
>         claim is either unique for an AS/RS pair or unique for each
>         access token.
>
>          2. globally unique (i.e. the same not only for all the RSs
>             but also for servers that have nothing to do with OAuth),
>             where the sub claim would be either unique for an AS/RS
>             pair or unique for one access token.
>             IMPORTANT NOTICE: The contents of this email and any
>             attachments are confidential and may also be privileged.
>             If you are not the intended recipient, please notify the
>             sender immediately and do not disclose the contents to any
>             other person, use it for any purpose, or store or copy the

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 10 Sep 2020 11:39:08 +0000

Hi Denis,

Thanks for the clarifications regarding the uniqueness properties of the values that go into the subject claim.

Looking at draft-ietf-oauth-access-token-jwt-07 I don’t see where the draft introduces these two new flavors.

Additional comments below:

From: Denis <[email-masked]>
Sent: Thursday, September 10, 2020 11:41 AM
To: Hannes Tschofenig <[email-masked]>
Cc: Dick Hardt <[email-masked]>; [email-masked]
Subject: Re: [OAUTH-WG] draft-ietf-oauth-access-token-jwt-07

Hi Hannes,

Hi Denis,

Hi Dick and Hannes,

[Denis] RFC 7519 states: The subject value MUST either be scoped to be locally unique in the context of the issuer or be globally unique.

This makes two flavours: either locally unique in the context of the issuer or globally unique.

When reading the current text, in addition to these two flavours, two additional flavours (3) and (4) are discovered
which makes a total of four flavours:

[Hannes] The OAuth 2.0 architecture allows the authorization server and the resource server to agree on whatever token format they want.
They can pass the information by value or by reference (which may then require token introspection or an equivalent mechanism).
This document does not change anything concern this.

I hope this makes sense.

[Denis] I do not dispute the sentence you proposed "The OAuth 2.0 framework assumes that access tokens are treated opaque by clients"
which replaces the previous sentence which was: "The client MUST NOT inspect the content of the access token".

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.

Once having read your last three responses, I would propose the following small change in the second sentence:

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 at an instant of time might break later on without recourse.

You may have noticed that I proposed to change the RFC 2119 language in the text. I changed my original proposal to make it more clear (see red text).

"
   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 software relying on the ability to read the access token content may
   break since the OAuth 2.0 framework assumes that access tokens
   are treated opaque by clients.

[Denis] While reading all of your three last responses, I now understand the point.

How can the AS know that it got a call for the issuance of an access token compliant to this profile ?

   An authorization server can issue a JWT access token in response to any authorization grant defined by [RFC6749] and
   subsequent extensions meant to result in an access token.

I believe, it would be worthwhile to add a sentence, just after this sentence, with the following text:

   When an authorization server decides to issue a JWT access token compliant to this profile, then the following requirements apply.
   (...)

[Hannes] That’s fine for me because this is what the intended effect of the spec is.

Ciao

Hannes

Denis

Ciao
Hannes

Denis

Denis

client != user
ᐧ

Hi Victorio, Hi all,

Section 2:

Section 2.1

Section 2.2

s/""aud"/"aud"

2.2.1

s/Please see/See

Section 4

You write:

How about:
"

You write:

"

s/ For more

You write:

"

You write:

"

"

Another comment follows.
You wrote:

"

You wrote:

"

"

    Similarly, if

Denis
"

Section 7.2

References

Ciao
Hannes

OAuth mailing list

---

From: Denis <[email-masked]>
Date: Thu, 10 Sep 2020 14:33:04 +0200

Hi Hannes,

All my concerns about the fact that the OAuth 2.0 framework assumes that 
access tokens are treated opaque by clients are now solved.

Thanks !

> Hi Denis,
>
> Thanks for the clarifications regarding the uniqueness properties of 
> the values that go into the subject claim.
>
The text is as follows in section 6:

    Authorization servers should choose how to assign "sub" values 
according to the level of privacy required by each
    situation.  For instance: if a solution requires preventing tracking 
principal activities across multiple resource servers,
    the authorization server should ensure that JWT access tokens meant 
for different resource servers have distinct "sub"
    values *tht *cannot be correlated in the event of resource servers 
collusion.

Note the typo:  tht  -- > that

This is the flavor n° 3.

   Similarly: if a solution requires preventing a resource server from 
correlating the principal’s activity within the resource itself,
   the authorization server should assign different "sub" values for 
every JWT access  token issued.

This is the flavor n°4.

Denis

> *From:* Denis <[email-masked]>
> *Sent:* Thursday, September 10, 2020 11:41 AM
> *To:* Hannes Tschofenig <[email-masked]>
> *Cc:* Dick Hardt <[email-masked]>; [email-masked]
> *Subject:* Re: [OAUTH-WG] draft-ietf-oauth-access-token-jwt-07
>
> Hi Hannes,
>
>     1) While reading RFC 7519, no reader may be able to figure out
>     that there are more than two flavours of the "sub" claim.
>          When an element has been defined, its semantics cannot be
>     changed ... unless making an Errata to RFC 7519
> [Denis] RFC 7519 states: The subject value MUST *either *be scoped to 
> be locally unique in the context of the issuer *or * be globally unique.
>
>     2) The argument about "changing the token format at any time" does
>     not apply in the context of this future RFC.
>         This sentence should be either removed or modified This means
>     that the following sentence which is a derivative
>         Hence, any logic in the client relying on the ability to read
>         the access token content would break without recourse.
>
>         server and the resource server to agree on whatever token
>         format they want.
>         They can pass the information by value or by reference (which
>         may then require token introspection or an equivalent mechanism).
>         Imagine a third party implementing an OAuth 2.0 Client. If
>         they make assumptions about the ability to parse the content
>         of the token, we create a brittle system.
>
>     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).
> following small change in the second sentence:
>
>     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).
>     access token content /at an instant of time might /break /later
>     on/ without recourse.
>
>         You may have noticed that I proposed to change the RFC 2119
>         language in the text. I changed my original proposal to make
>         it more clear (see red text).
>
>         "
>
>         Some questions raised during the WGLC have not been answered:
>         [Hannes] The client cannot request the authorization server to
>         use a specific token format. Since the client is not going to
>         look at the access token content why would it even care.
>
>         [Hannes] There no parameters defined so that the client can
>         ask for an access token format that is compliant to this profile.
>
> OK.
>
>         [Hannes] The AS only gets a request for an access token and
>         the AS needs to decide what format to use, like it did in the
>         past. Nothing changed.
>
>         The objective of this document is to standardize the token the
>         AS shares with the RS. It is not to standardize how the client
>         can read the token. Just because the user is using the client,
>         that does not mean the user wants the client to see any claims
>         about themselves. Letting the client see the contents of the
>         token may be a privacy violation.
>
>         client != user
>
>         ᐧ
>
>                 draft-ietf-oauth-access-token-jwt-07. Reading through
>                 the draft I have a few minor suggestions:
>
>                 Section 2:
>
>                 regular JWTs complying with the requirements described
>                 in this section."
>
>                 paragraph gives me the impression that you talk about
>                 "ASs using RFC 8414"
>
>                 security implications./Please see Section 5 for
>                 further guidance on security implications.
>
>                 Question: If you refer to RFC 6750 and then list the
>                 steps are you just repeating the steps from RFC 6750
>                 or are you augmenting them?
>
>                 You write:
>
>                 "
>
>                 The phrase "leaking keys" is probably not the best
>                 term to describe what follows afterwards in the text.
>
>                 You write:
>
>                 "
>
>                 This RFC 2119 language is not really enforceable in
>                 terms of interoperability. Maybe you could rephrase a
>                 bit. Something like the following would work:
>
>                 "
>
>             /In the general case, /the OAuth 2.0 framework assumes
>             that access tokens are treated as opaque by clients.
>             However, with this coming RFC, we are not in the general
>             case: since the client gets back an access token
>             conformant to _this_ RFC, then it knows
>             exactly its detailed structure. The argument about
>             "changing the token format at any time" does not apply. In
>             this case, the client is quite sure
>             that it would be able to understand most of its content
>             (at least all the standard claims). The above text
>             proposal would need to be reconsidered.
>
>             Hiding (by encrypting it) the content of the access token
>             to the client is odd when an access token contains claims
>             about a human-user :
>             these claims are personal data and the human-user is
>             usually allowed to have access to his own personal data.
>
>             answered: How can a client request an access token
>             Which parameter(s) allow it to ask an access token
>             compliant to this profile ? How can the AS know that it
>             got a call for the issuance of an access token
>             While the idea is really nice, the use of the "sub" claim
>             in this context is not compatible with the definition of
>             the "sub" claim
>             as defined in RFC 7519:
>
>                     about the subject. *The subject value MUST either
>             be scoped to be
>                 "globally unique" means that it is the same not only
>                 for all the RSs but also for servers that have nothing
>                 to do with OAuth (e.g. an email address).
>
>
>
>
>                 Similarly, if
>
>             The proposed text describes two different cases where the
>             sub claim is either unique for an AS/RS pair or unique for
>             each access token.
>
>              2. globally unique (i.e. the same not only for all the
>                 RSs but also for servers that have nothing to do with
>                 OAuth),
>                 1° Stick to the definition of RFC 7519 and
>                 (unfortunately) remove these possibilities.
>                 2° Define two new claims which would support the two
>                 cases where the sub claim would be either unique for
>                 an AS/RS pair or unique for one access token.
>                 September 2015,
>                 <https://www.rfc-editor.org/info/rfc7644>
>                 attachments are confidential and may also be
>                 privileged. If you are not the intended recipient,
>                 please notify the sender immediately and do not
>                 disclose the contents to any other person, use it for
>                 any purpose, or store or copy the information in any
>                 medium. Thank you.
>
>

---

From: Vittorio Bertocci <[email-masked]>
Date: Tue, 15 Sep 2020 06:59:06 +0000

Thank you Hannes for the thorough review, and thanks in advance for the writeup!

I applied most of the changes you suggested, and submitted a new draft.
Comments on questions and suggestions I didn’t understand below:

  *   Question: If you refer to RFC 6750 and then list the steps are you just repeating the steps from RFC 6750 or are you augmenting them?
6750 doesn’t offer an explicit list of validation steps, given the format agnostic approach followed by Core, tho some can be inferred here and there. The validation steps defined here are closer to the ones OIDC core lists for id_token validation, but aren’t exactly the same- besides the typ header step and aud value considerations, which are unique to this spec, the discussion led to some other important differences from the OIDC list (no ordering in the steps, no auth_time, acr, azp considerations etc) that warrant listing the validation steps explicitly.

  *   The phrase "leaking keys" is probably not the best term to describe what follows afterwards in the text.
Can you expand on what aspect makes the term misaligned with the following text? The main difference seems to be that later on the verb used is “compromise”, but that’s more due to the fact that there’s an active agent in the sentence (the attacker) while the preceding phrase lacks one. If I were to use “compromise” instead of leak I’d need to make it passive, which seems a bit weird. I am happy to change it, but I wanted to understand the point better first.

  *   This RFC 2119 language is not really enforceable in terms of interoperability.
I’d like to understand this better. The thing I am trying to express here is an absolute prohibition, as stated by 2119. The fact that it is unenforceable and potentially inconsequential doesn’t make it acceptable, hence the language seems to be appropriate.
       I didn’t take out the MUST NOT yet as we clarify the point further. I did however apply all your edits to that section, as they do make things clearer. Thanks!

  *   The first sentence is a repetition of the previous paragraph. I would suggest to delete the first sentence in this paragraph and to move the second sentence to the previous paragraph
The second sentence isn’t really a repetition IMO- rather, it is a specialization. Whereas the first paragraph talks about the client, the sentence you singled out talks about the end user. Those are closely correlated, but not the same. There are scenarios where the end user doesn’t have access to the tokens, but the client app does.

From: OAuth <[email-masked]> on behalf of Hannes Tschofenig <[email-masked]>
Date: Monday, September 7, 2020 at 23:29
To: "[email-masked]" <[email-masked]>
Subject: [OAUTH-WG] draft-ietf-oauth-access-token-jwt-07

Hi Victorio, Hi all,

Section 2:

Section 2.1

Section 2.2

s/""aud"/"aud"

2.2.1

s/Please see/See

Section 4

You write:

How about:
"

You write:

"

s/ For more

You write:

"

You write:

"

"

You wrote:

"

You wrote:

"

"

Section 7.2

References

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 17 Sep 2020 10:23:18 +0000

Hi Vittorio,

Thanks for the draft update.

Responses to  your questions are below:

From: Vittorio Bertocci <[email-masked]>
Sent: Tuesday, September 15, 2020 8:59 AM
To: Hannes Tschofenig <[email-masked]>; [email-masked]
Subject: Re: [OAUTH-WG] draft-ietf-oauth-access-token-jwt-07

I applied most of the changes you suggested, and submitted a new draft.
Comments on questions and suggestions I didn't understand below:

  *   Question: If you refer to RFC 6750 and then list the steps are you just repeating the steps from RFC 6750 or are you augmenting them?
6750 doesn't offer an explicit list of validation steps, given the format agnostic approach followed by Core, tho some can be inferred here and there. The validation steps defined here are closer to the ones OIDC core lists for id_token validation, but aren't exactly the same- besides the typ header step and aud value considerations, which are unique to this spec, the discussion led to some other important differences from the OIDC list (no ordering in the steps, no auth_time, acr, azp considerations etc) that warrant listing the validation steps explicitly.

[Hannes] Thanks. This answers my question. No further action needed on this issue.

  *   The phrase "leaking keys" is probably not the best term to describe what follows afterwards in the text.
Can you expand on what aspect makes the term misaligned with the following text? The main difference seems to be that later on the verb used is "compromise", but that's more due to the fact that there's an active agent in the sentence (the attacker) while the preceding phrase lacks one. If I were to use "compromise" instead of leak I'd need to make it passive, which seems a bit weird. I am happy to change it, but I wanted to understand the point better first.

Here is the entire paragraph:

"
   Authorization servers should not rely on the use of different keys
   for signing OpenID Connect ID Tokens and JWT tokens as a method to
   safeguard against the consequences of leaking specific keys.  Given
   that resource servers have no way of knowing what key should be used
   to validate JWT access tokens in particular, they have to accept
   signatures performed with any of the keys published in AS metadata or
   OpenID Connect discovery: consequently, an attacker just needs to
   compromise any key among the ones published to be able to generate
   and sign JWTs that will be accepted as valid by the resource server.
"

Let us consider two cases here, namely the symmetric key case and the asymmetric key case.

In both cases it is common practice to use different keys for different purposes. In this case we are even talking about the use of keys for different recipients. ID Tokens are created by the AS for use by the OAuth Client while access tokens are consumed by the resource server.

For the symmetric key case, one of the two parties can leak the key. Who do you assume leaks the key here?
For the asymmetric key case, leaking the public key does not have a security impact. Are you concerned that the private key is compromised on the AS? There is, however, additionally the question about the compromise of the trust anchor.

You are saying that resource servers have no way of knowing what key to use to validate the access token. This is not correct because there is a dedicated field for that purpose: From RFC 7515:

"The "kid" (key ID) Header Parameter is a hint indicating which key was used to secure the JWS."

Why is this statement true "they have to accept signatures performed with any of the keys published in AS metadata or OpenID Connect discovery"

In general, it is bad if the private key got compromised. This will allow an adversary to create access tokens. The question is therefore: if this happens, how can you revoke the keys.
Using different keys for different purposes with different recipients is a common practice.

  *   This RFC 2119 language is not really enforceable in terms of interoperability.
I'd like to understand this better. The thing I am trying to express here is an absolute prohibition, as stated by 2119. The fact that it is unenforceable and potentially inconsequential doesn't make it acceptable, hence the language seems to be appropriate.
       I didn't take out the MUST NOT yet as we clarify the point further. I did however apply all your edits to that section, as they do make things clearer. Thanks!

Here is the sentence again:

"

I fully understand that you are trying to prohibit the OAuth client to look at the access token.
Normally, RFC 2119 language is used to inform how implementations should behave. This behavior can then be tested. How do you want to test whether a client did or did not look at the token as an outside observer?

I am not as passionate about this paragraph as others in the group because I have a pragmatic approach: it will not make a difference whether the MUST NOT is capitalized or not.

  *   The first sentence is a repetition of the previous paragraph. I would suggest to delete the first sentence in this paragraph and to move the second sentence to the previous paragraph
The second sentence isn't really a repetition IMO- rather, it is a specialization. Whereas the first paragraph talks about the client, the sentence you singled out talks about the end user. Those are closely correlated, but not the same. There are scenarios where the end user doesn't have access to the tokens, but the client app does.

You are right. I would restructure the paragraphs as follows:

   As JWT access tokens carry information by value, it now becomes

   possible for requestors and receivers clients and potentially

   even end users to directly peek inside the

   token claims collection.

   the access token: the authorization server and the resource server

   switching from this profile to opaque tokens) hence any logic in the

   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.

   to enforce confidentiality.

   Possible measures to prevent leakage of information to clients and end

   Users include: encrypting the access token, encrypting the sensitive

   claims, omitting the sensitive claims or not using this profile, falling

   back on opaque access tokens.

The reason for the restructuring is the following:

  *   The counter-measures are applicable to end users and clients looking at the tokens - not just end users.
  *   The first sentence talks about clients and end users and not just about clients.

I hope this makes sense.

Ciao
Hannes

From: OAuth <[email-masked]<mailto:[email-masked]>> on behalf of Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>
Date: Monday, September 7, 2020 at 23:29
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [OAUTH-WG] draft-ietf-oauth-access-token-jwt-07

Hi Victorio, Hi all,

Section 2:

Section 2.1

Section 2.2

s/""aud"/"aud"

2.2.1

s/Please see/See

Section 4

You write:

How about:
"

You write:

"

s/ For more

You write:

"

You write:

"

"

You wrote:

"

You wrote:

"

"

Section 7.2

References

Ciao
Hannes

---

From: Vittorio Bertocci <[email-masked]>
Date: Sat, 19 Sep 2020 00:26:57 +0000

Thanks for the extra details! I published an updated draft.
Comments:

  *   The reason for the restructuring is the following: [..]counter-measures are applicable to end users and clients looking at the tokens [..] The first sentence talks about clients and end users and not just about clients.
       Makes perfect sense! I applied your suggestion in the new draft.

  *   I am not as passionate about this paragraph as others in the group because I have a pragmatic approach: it will not make a difference whether the MUST NOT is capitalized or not.
On the basis of this, I would like to try keeping the uppercase thru the next iteration. I’d rather make the intent extra clear, especially if it doesn’t make a difference in terms of testable behavior.

On the leaking keys, that warrants more discussion. The current language is the result of the discussion in https://mailarchive.ietf.org/arch/msg/oauth/OfHpPeCQ0Pt8r9_qOF5sVC9GdWo/. You can find the details in there, but the TL;DR is that we don’t want anyone to have the impression that having one key dedicated to id_tokens and another for access tokens only gives any extra guarantee in case one of those two keys is leaked: meaning, if both keys are advertised in the metadata, they can be used interchangeably hence an attacker obtaining the key dedicated to signing id_tokens will be able to manufacture valid access tokens too without the RS being able to tell the difference. It took me a bit to understand this during the discussion, it is a tricky point. But all the more reasons to address it explicitly.
In details:

  *   For the symmetric key case
The main challenge we are dealing with is the lack of specialized metadata attributes to advertise intended key function.
That excludes the symmetric case given that there’s no discovery involved, hence out of band anything can happen (eg the two parties might agree on specific key uses).

  *   are even talking about the use of keys for different recipients. ID Tokens are created by the AS for use by the OAuth Client while access tokens are consumed by the resource server.
From the security PoV, the fact that the intended recipients are distinct doesn’t improve outcomes if compromising a key meant for one recipient grants an attacker access to the other recipient too.
Also. From the developer PoV it is pretty common to have one web application that handles both browser requests for pages (hence being an ID_token recipient) and API requests (hence expacting access tokens) from mobile clients, S2S and other clients. Many developer platforms automatically provision both a client_id and a resource ID for an application. This doesn’t mean that _every_ application will have this dual nature, but it means that it is a prominent enough scenario to require consideration, even if the dual audience compromise wouldn’t be a problem in itself.

  *   Are you concerned that the private key is compromised on the AS?
Definitely the concern considered here. We advertise the public keys in the metadata hence they are “leaked” by design 😊

  *   “The "kid" (key ID) Header Parameter is a hint indicating which key was used to secure the JWS.”
At that point that is far too late 😊 If as RS I receive a JWT AT  whose kid declares it has been signed by A, and the AS metadata declares that possible signing keys correspond to A and B, I have to accept the signature- right? But as RS I cannot know whether A is the key the AS intended to use for signing ATs or ID_tokens, all I know is that it is one of the keys the AS declares it will use. If I am expecting an ID_token, I am in the exact same situation. That means that an attacker compromising A can manufacture both ID_tokens and JWT ATs that will look valid, regardless of what use (AT or ID_token) the AS assigned to A or B. The key is that the AS intent remains an internal detail, and all the RS can do is verify that A is one of the keys AS advertises. The kid in the header doesn’t help to solve this.

  *   Why is this statement true “they have to accept signatures performed with any of the keys published in AS metadata or OpenID Connect discovery"
See the last point

  *   Using different keys for different purposes with different recipients is a common practice.
That’s true, but unfortunately in this particular case the lack of differentiation in the AS metadata means that assigning different keys to different audiences will not make a difference if those keys are all published in an indifferentiated list.

From: Hannes Tschofenig <[email-masked]>
Date: Thursday, September 17, 2020 at 03:23
To: Vittorio Bertocci <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: [OAUTH-WG] draft-ietf-oauth-access-token-jwt-07

Hi Vittorio,

  1.  Question: If you refer to RFC 6750 and then list the steps are you just repeating the steps from RFC 6750 or are you augmenting them?
6750 doesn’t offer an explicit list of validation steps, given the format agnostic approach followed by Core, tho some can be inferred here and there. The validation steps defined here are closer to the ones OIDC core lists for id_token validation, but aren’t exactly the same- besides the typ header step and aud value considerations, which are unique to this spec, the discussion led to some other important differences from the OIDC list (no ordering in the steps, no auth_time, acr, azp considerations etc) that warrant listing the validation steps explicitly.

  1.  The phrase "leaking keys" is probably not the best term to describe what follows afterwards in the text.
Can you expand on what aspect makes the term misaligned with the following text? The main difference seems to be that later on the verb used is “compromise”, but that’s more due to the fact that there’s an active agent in the sentence (the attacker) while the preceding phrase lacks one. If I were to use “compromise” instead of leak I’d need to make it passive, which seems a bit weird. I am happy to change it, but I wanted to understand the point better first.

“
“

“The "kid" (key ID) Header Parameter is a hint indicating which key was used to secure the JWS.”

Why is this statement true “they have to accept signatures performed with any of the keys published in AS metadata or OpenID Connect discovery"

  1.  This RFC 2119 language is not really enforceable in terms of interoperability.
I’d like to understand this better. The thing I am trying to express here is an absolute prohibition, as stated by 2119. The fact that it is unenforceable and potentially inconsequential doesn’t make it acceptable, hence the language seems to be appropriate.
       I didn’t take out the MUST NOT yet as we clarify the point further. I did however apply all your edits to that section, as they do make things clearer. Thanks!

"

  1.  The first sentence is a repetition of the previous paragraph. I would suggest to delete the first sentence in this paragraph and to move the second sentence to the previous paragraph
The second sentence isn’t really a repetition IMO- rather, it is a specialization. Whereas the first paragraph talks about the client, the sentence you singled out talks about the end user. Those are closely correlated, but not the same. There are scenarios where the end user doesn’t have access to the tokens, but the client app does.

   token claims collection.

   prevent it.

  1.  The counter-measures are applicable to end users and clients looking at the tokens – not just end users.
  2.  The first sentence talks about clients and end users and not just about clients.

I hope this makes sense.

Ciao
Hannes

Hi Victorio, Hi all,

Section 2:

Section 2.1

Section 2.2

s/""aud"/"aud"

2.2.1

s/Please see/See

Section 4

You write:

How about:
"

You write:

"

s/ For more

You write:

"

You write:

"

"

You wrote:

"

You wrote:

"

"

Section 7.2

References

Ciao
Hannes