From nobody Tue Sep 8 09:26:50 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF7293A0774 for ; Tue, 8 Sep 2020 09:26:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tT2Ng2d_b4Cc for ; Tue, 8 Sep 2020 09:26:45 -0700 (PDT) Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FBAF3A0744 for ; Tue, 8 Sep 2020 09:26:45 -0700 (PDT) Received: by mail-lf1-x12f.google.com with SMTP id z17so9487218lfi.12 for ; Tue, 08 Sep 2020 09:26:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rYztppevFqHSn2qqJEsrDK1ltr2GuY3qs1k64NreCUg=; b=lydNkb9TX8uNbVTHnJ53tI0ZivhCFpAXysYXVaBN9IPoknPbVWjfO1UKIYbmn4+/fb bD3d5xGsIDe6gFtQGZiHcymSdU12v3FMVvAqtVt7pbKjdwi+/+qpsmzyUf0GgK0IBvQZ OucJfjc+fszsHyQWq3I/FzpWNAXl+wlw/THPvyGuLN8WzgSiFGIw+UPcBofYnNZSTRy+ czdQVWMdyefqubVc3WWXqeQ1heOnCxGteHA2jhOpH4igUrrQFGYi8NakGVQq40PmdGur +kBXKvfMc/mVkRQGwruRDB6i3kSApwUIggi/wuPFZA6k8huyBoCAHey041R0xhqWyxV/ eJIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rYztppevFqHSn2qqJEsrDK1ltr2GuY3qs1k64NreCUg=; b=HqqsvpFijns3SJ8PDWtmckzT1P157qmMgTZEYqVi579BShFqlFZyVHO8OtSdb2hYbk CO011oKWEe6AgJBw2+IuSQ+n/t39ls9NTXUtbqXi2Y/16r+2OBlG9z7uEwFgi4HE2Ohs 62KH33L5drqauDPDoZSbn8nIsmRqUastiVb+pSCp58Fr06Isuu4DaTvMmr/DS6v45nX3 SJSBurw/lrqZv/mIddO1ise5g+sO977wFkQKF79j+T0ERn5drMJXaTima+HOnYiNDP1O ibJm5njBX7q1F4cBCrsmpKPxuMFlmRKFQKhjU0+WRhV49RjIqQ9wb4QN7kEjmOS82KsM dH1Q== X-Gm-Message-State: AOAM530MFdsf/5lRTPnQXXO6VMiRY8ZXScRzJJxnSCjHU4wbX9TeMcpz sYXQK7vqtCZ/YM3QBuWDWry/OJqpwv9CiiPuqd4= X-Google-Smtp-Source: ABdhPJwarK5QYM9v1afqRqearJuwJwUnsdw1gofEZzIP4WJVx9706u+nSEQgwdhBkImAQ4UY0w5H+oRuMIUJOjyTPyg= X-Received: by 2002:a19:3f0d:: with SMTP id m13mr3608866lfa.91.1599582402980; Tue, 08 Sep 2020 09:26:42 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dick Hardt Date: Tue, 8 Sep 2020 09:26:06 -0700 Message-ID: To: Denis Cc: Hannes Tschofenig , oauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000eb33de05aecfccd2" Archived-At: Subject: Re: [OAUTH-WG] draft-ietf-oauth-access-token-jwt-07 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2020 16:26:49 -0000 --000000000000eb33de05aecfccd2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 !=3D user =E1=90=A7 On Tue, Sep 8, 2020 at 9:10 AM Denis 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 complyin= g > 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./Thi= s > 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 clie= nt > > 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 sur= e > 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 ca= n > 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 addres= s). > > > 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=C2=B0 Stick to the definition of RFC 7519 and (unfortunately) remove th= ese > possibilities. > 2=C2=B0 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=C2=B0 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, > > > . > > > > 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, > . > > > > 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, > > > . > > > > > > 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 th= e > information in any medium. Thank you. > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau= th > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000000000000eb33de05aecfccd2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Denis


The objective of t= his document is to standardize the token the AS shares with the RS. It is n= ot 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 an= y claims about themselves. Letting the client see the contents of the token= may be a privacy violation.

client !=3D user=
3D""=E1=90=A7

On Tue, Sep 8, 2020 = at 9:10 AM Denis <denis.ietf@free.= fr> wrote:
=20 =20 =20

Hi Victorio, Hi all,

=C2=A0

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:

=C2=A0

Section 2:

=C2=A0

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

=C2=A0

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

=C2=A0

Section 2.1

=C2=A0

s/asymmetric algorithms/asymmetric cryptography

(same replacement in Section 4)

=C2=A0

s/=C2=A0=C2=A0 This specification registers = the "application/at+jwt" media type,

=C2=A0=C2=A0 which can be used to indicate t= hat the content is an access token./This specification registers the "application/at+jwt" media type,

=C2=A0=C2=A0 which can be used to indicate t= hat the content is a JWT access token.

=C2=A0

Use capitalized "Section" when a s= ection number is indicated, such as in Section 2.2.=C2=A0=C2=A0

=C2=A0

Section 2.2

=C2=A0

s/""aud"/"aud"

=C2=A0

2.2.1

=C2=A0

s/=C2=A0=C2=A0 auth_time=C2=A0 OPTIONAL - as= defined in section 2 of [OpenID.Core]./=C2=A0=C2=A0 auth_time=C2=A0 OPTIONAL= - as defined in Section 2 of [OpenID.Core].

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

=C2=A0

=C2=A0

s/Please see/See

=C2=A0

s/For example:/For example,

=C2=A0

Section 4

=C2=A0

You write:

=C2=A0

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

=C2=A0

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

=C2=A0

=C2=A0

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

=C2=A0

This sentence sounds strange to me: <= u>

"

=C2=A0=C2=A0 When invoked as described in OA= uth 2.0 Bearer Token Usage [RFC6750],

=C2=A0=C2=A0 resource servers receiving a JW= T access token MUST validate it in the

=C2=A0=C2=A0 following manner.=

"

=C2=A0

How about:

"

=C2=A0=C2=A0 Resource servers receiving a JW= T access token MUST validate it in the

=C2=A0=C2=A0 following manner.=

"

=C2=A0

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?

=C2=A0

=C2=A0

You write:

=C2=A0

"

If the JWT access token includes authorization claims as described in

=C2=A0=C2=A0 the authorization claims sectio= n, the resource server SHOULD use them

=C2=A0=C2=A0 in combination with any other c= ontextual information available to

=C2=A0=C2=A0 determine whether the current c= all should be authorized or rejected.

"

=C2=A0

Include a reference to the authorization claims section

=C2=A0

=C2=A0

s/ For more

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

=C2=A0=C2=A0 details on cross-JWT confusion = please refer to Section 2.8 of [RFC8725].

=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0

You write:

=C2=A0

"

=C2=A0=C2=A0 Authorization servers should no= t rely on the use of different keys

=C2=A0=C2=A0 for signing OpenID Connect ID T= okens and JWT tokens as a method to

=C2=A0=C2=A0 safeguard against the consequen= ces of leaking specific keys.

"

=C2=A0

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

=C2=A0

You write:

=C2=A0

"

The client MUST NOT inspect the content of

=C2=A0=C2=A0 the access token<= /p>

"

=C2=A0

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

=C2=A0

"=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0Authorization server and t= he resource server

=C2=A0=C2=A0 might decide to change token fo= rmat at any time (for example by

=C2=A0=C2=A0 switching from this profile to = opaque tokens). Hence, any logic in the

=C2=A0=C2=A0 client relying on the ability t= o read the access token content would

=C2=A0=C2=A0 break without recourse. The OAu= th 2.0 framework assumes that access tokens

=C2=A0=C2=A0=C2=A0are treated opaque by clie= nts.

=C2=A0

=C2=A0=C2=A0 Administrators of authorization= servers should also take into account that

=C2=A0=C2=A0=C2=A0the content of an access t= oken is visible to the client. Whenever client

=C2=A0=C2=A0 access to the access token cont= ent presents privacy issues for a

=C2=A0=C2=A0 given scenario, the authorizati= on server should take explicit steps

=C2=A0=C2=A0 to prevent it.=C2=A0=C2=A0 <= /u>

"


In the general case, <= /i>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 t= he 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:

=C2=A0

"

=C2=A0

=C2=A0=C2=A0 In scenarios in which JWT acces= s tokens are accessible to the end

=C2=A0=C2=A0 user, it should be evaluated wh= ether the information can be accessed

=C2=A0=C2=A0 without privacy violations (for= example, if an end user would simply

=C2=A0=C2=A0 access his or her own personal information) or if steps must be taken

=C2=A0=C2=A0 to enforce confidentiality.=C2= =A0 Possible measures include: encrypting

=C2=A0=C2=A0 the access token, encrypting th= e sensitive claims, omitting the

=C2=A0=C2=A0 sensitive claims or not using t= his profile, falling back on opaque

=C2=A0=C2=A0 access tokens.

"

=C2=A0

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.

=C2=A0

You wrote:

=C2=A0

"

=C2=A0=C2=A0 This profile mandates the prese= nce of the "sub" claim in every JWT

=C2=A0=C2=A0 access token, making it possibl= e for resource servers to rely on that

=C2=A0=C2=A0 information for performing task= s such as correlating incoming

=C2=A0=C2=A0 requests with data stored local= ly for the authenticated principal.

=C2=A0=C2=A0 Although the ability to correla= te requests might be required by

=C2=A0=C2=A0 design in many scenarios, there= are scenarios where the authorization

=C2=A0=C2=A0 server might want to prevent co= rrelation to preserve the desired

=C2=A0=C2=A0 level of privacy.=C2=A0 Authori= zation servers should choose how to assign

=C2=A0=C2=A0 "sub" values accordin= g to the level of privacy required by each

=C2=A0=C2=A0 situation.=C2=A0 For instance: = if a solution requires preventing tracking

=C2=A0=C2=A0 principal activities across mul= tiple resource servers, the

=C2=A0=C2=A0 authorization server should ens= ure that JWT access tokens meant for

=C2=A0=C2=A0 different resource servers have= distinct "sub" values tht cannot be

=C2=A0=C2=A0 correlated in the event of reso= urce servers collusion.=C2=A0 Similarly: if

=C2=A0=C2=A0 a solution requires preventing = a resource server from correlating the

=C2=A0=C2=A0 principal's activity within= the resource itself, the authorization

=C2=A0=C2=A0 server should assign different = "sub" values for every JWT access

=C2=A0=C2=A0 token issued.=C2=A0 In turn, th= e client should obtain a new JWT access

=C2=A0=C2=A0 token for every call to the res= ource server, to ensure that the

=C2=A0=C2=A0 resource server receives differ= ent "sub" and "jti" values at every

=C2=A0=C2=A0 call, thus preventing correlati= on between distinct requests.

"

=C2=A0

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.

=C2=A0

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

=C2=A0

"

=C2=A0=C2=A0 This profile mandates the prese= nce of the "sub" claim in every JWT

=C2=A0=C2=A0 access token, making it possibl= e for resource servers to rely on that

=C2=A0=C2=A0 information for correlating inc= oming

=C2=A0=C2=A0 requests with data stored local= ly for the authenticated principal.

=C2=A0=C2=A0 Although the ability to correla= te requests might be required by

=C2=A0=C2=A0 design in many scenarios, there= are scenarios where the authorization

=C2=A0=C2=A0 server might want to prevent correlation. The "sub" claim should be

=C2=A0=C2=A0=C2=A0populated by the authoriza= tion servers according to a privacy impact

=C2=A0=C2=A0=C2=A0assessment. For instance, = if a solution requires preventing tracking

=C2=A0=C2=A0 principal activities across mul= tiple resource servers, the

=C2=A0=C2=A0 authorization server should ens= ure that JWT access tokens meant for

=C2=A0=C2=A0 different resource servers have= distinct "sub" values that cannot be

=C2=A0=C2=A0 correlated in the event of reso= urce servers collusion.=C2=A0

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:

=C2=A0=C2=A0=C2=A0=C2=A0 4.1.2.=C2=A0 "sub" (Subject) Cla= im
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The "sub" (sub= ject) claim identifies the principal that is the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 subject of the JWT.=C2=A0 The claims in= a JWT are normally statements
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 about the subject.=C2=A0= The subject value MUST either be scoped to be
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 locally unique in= the context of the issuer or be globally unique.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The processing of this c= laim is generally application specific.=C2=A0 The
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "sub" value is= a case-sensitive string containing a StringOrURI
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 value.=C2=A0 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 fo= r all the RSs but also for servers that have nothing to do with OAuth (e.g. an email address).


=C2=A0=C2=A0=C2=A0 Similarly, if

=C2=A0=C2=A0 a solution requires preventing = a resource server from correlating the

=C2=A0=C2=A0 principal's activity within= the resource itself, the authorization

=C2=A0=C2=A0 server should assign different = "sub" values for every JWT access

=C2=A0=C2=A0 token issued.=C2=A0 In turn, th= e client should obtain a new JWT access

=C2=A0=C2=A0 token for every call to the res= ource server, to ensure that the

=C2=A0=C2=A0 resource server receives differ= ent "sub" and "jti" values at every

=C2=A0=C2=A0 call, thus preventing correlati= on 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:=C2= =A0

  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=C2=B0 Stick to the definition of RFC 7519 a= nd (unfortunately) remove these possibilities.
2=C2=B0 Define two new claims which would support the two cases where the sub claim would be either <= font face=3D"Arial">unique for an AS/RS pair or= unique for one access token.
3=C2=B0 Define four new claims which wo= uld support the four above cases.<= br>

Denis

"

=C2=A0

=C2=A0

Section 7.2

=C2=A0

s/=C2=A0=C2=A0 Section Section 2.2.3.1 of th= is specification refers to the

=C2=A0=C2=A0 attributes "roles", &= quot;groups", "entitlements" defined in [RFC7643] to

=C2=A0=C2=A0 express authorization informati= on in JWT access tokens.

/=C2=A0=C2=A0 Section 2.2.3.1 of this specif= ication refers to the

=C2=A0=C2=A0 attributes "roles", &= quot;groups", "entitlements" defined in [RFC7643] to

=C2=A0=C2=A0 express authorization informati= on in JWT access tokens.

=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0

References

=C2=A0

RFC 7519 has to be a normative reference:

=C2=A0

=C2=A0=C2=A0 [RFC7519]=C2=A0 Jones, M., Brad= ley, J., and N. Sakimura, "JSON Web Token

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <https://www.rfc-editor.org/info/rfc7519>.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0

RFC 7644 is an unused reference: <= /u>

=C2=A0

=C2=A0=C2=A0 [RFC7644]=C2=A0 Hunt, P., Ed., = Grizzle, K., Ansari, M., Wahlstroem, E.,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 and C. Mortimore, "System for Cross-domain Identity

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Management: Protocol", RFC 7644, DOI 10.17487/RFC7644,

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 September 2015, <https://www.rfc-editor.org/info/rfc7644>.=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

=C2=A0

The same is true for RFC 3986:

=C2=A0

=C2=A0=C2=A0 [RFC3986]=C2=A0 Berners-Lee, T.= , Fielding, R., and L. Masinter, "Uniform

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Resource Identifier (URI): Generic Syntax", STD 66,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 RFC 3986, DOI 10.17487/RFC3986, January 2005,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <https://www.rfc-editor.org/info/rfc3986>.

=C2=A0

=C2=A0

Ciao

Hannes

=C2=A0

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
h=
ttps://www.ietf.org/mailman/listinfo/oauth


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000eb33de05aecfccd2--