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

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.
>
> Looking at draft-ietf-oauth-access-token-jwt-07 I don’t see where the 
> draft introduces these two new flavors.
>
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

> Additional comments below:
>
> *From:* Denis <denis.ietf@free.fr>
> *Sent:* Thursday, September 10, 2020 11:41 AM
> *To:* Hannes Tschofenig <Hannes.Tschofenig@arm.com>
> *Cc:* Dick Hardt <dick.hardt@gmail.com>; oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] draft-ietf-oauth-access-token-jwt-07
>
> Hi Hannes,
>
> Thank you for responses. See below.
>
>     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?
>
> [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.
>
>
>     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.
>
> [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.
>
>         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.
>
>         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.
>
>         "
>
>     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.
>
> [Denis] While reading all of your three last responses, I now 
> understand the point.
>
>
>         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.
>
> 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.
>    (...)
>
> [Hannes] That’s fine for me because this is what the intended effect 
> of the spec is.
>
> Ciao
>
> Hannes
>
> Denis
>
>         Ciao
>
>         Hannes
>
>     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 <denis.ietf@free.fr
>         <mailto:denis.ietf@free.fr>> wrote:
>
>             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."
>
>                 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.
>
>                 "
>
>             /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:
>
>                 "
>
>                 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.
>
>             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
>
>                 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
>
>                 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>
>                 <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>
>                 <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>
>                 <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.
>
>
>                 _______________________________________________
>
>                 OAuth mailing list
>
>                 OAuth@ietf.org  <mailto:OAuth@ietf.org>
>
>                 https://www.ietf.org/mailman/listinfo/oauth
>
>             _______________________________________________
>             OAuth mailing list
>             OAuth@ietf.org <mailto:OAuth@ietf.org>
>             https://www.ietf.org/mailman/listinfo/oauth
>
>     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.
>
> 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. 