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

[[e-mail]]

Thanks Hannes!

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

 

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

 

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.