Subject: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2020-04-13

From: IESG Secretary <[email-masked]>
Date: Tue, 07 Apr 2020 10:52:37 -0700

The Web Authorization Protocol (oauth) Working Group will hold
a virtual interim meeting on 2020-04-13 from 12:00 to 13:00 America/Toronto (16:00 to 17:00 UTC).

Agenda:
1. Nested JWT
https://www.ietf.org/archive/id/draft-yusef-oauth-nested-jwt-03.txt

2. JWT Profile for Access Tokens
https://datatracker.ietf.org/doc/draft-ietf-oauth-access-token-jwt/

Information about remote participation:
https://ietf.webex.com/ietf/j.php?MTID=m776932cd87f84cbceb34ae907027b0f0

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Fri, 10 Apr 2020 09:35:04 -0400

The following is a link to the coming interim meeting materials:
https://datatracker.ietf.org/meeting/interim-2020-oauth-04/session/oauth

It has the chairs and Nested JWT slides.
Will upload the JWT Profile for AT slides as soon as I get it.

Regards,
 Rifaat

On Tue, Apr 7, 2020 at 1:52 PM IESG Secretary <[email-masked]>
wrote:

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

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Mon, 13 Apr 2020 06:24:40 -0400

I have uploaded the second presentation for today's session, the JWT
Profile for Access Tokens.
https://datatracker.ietf.org/meeting/interim-2020-oauth-04/session/oauth

Regards,
 Rifaat

---

From: Denis <[email-masked]>
Date: Mon, 13 Apr 2020 17:15:16 +0200

Hello,

More on privacy about "JWT Profile for Access Tokens".

The current document REQUIRES the claim names *sub* and *client_id*.

  * sub  REQUIRED - as defined in section 4.1.2 of [RFC7519].
  * client_id  REQUIRED - as defined in section 4.3 of [RFC8693]

*1) **sub  REQUIRED*

RFC 7519 states:

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

If *sub *is *REQUIRED *for this profile, then this allows all resource 
servers to link accesses made by the same client on different servers.

*2) client_id  REQUIRED*

RFC 8693 states:

    4.3. "client_id" (Client Identiﬁer) Claim
    The client_id claim carries the client identiﬁer of the OAuth 2.0
    [RFC 6749] client that requested the token.

RFC 6749 states:

    2.2.  Client Identifier
        The authorization server issues the registered client a client
        identifier -- a unique string representing the registration
        information provided by the client.  The client identifier is not a
        secret; it is exposed to the resource owner and MUST NOT be used
        alone for client authentication. *The client identifier is
    unique to**
    **   the authorization server.*

If *client_id* is REQUIRED for this profile, this also allows all 
resource servers to link accesses made by the same client on different 
servers.

*Both claim names should be OPTIONAL *to allow to support the privacy 
principle of unlinkability.

Would both names remain *REQUIRED*, the Privacy considerations section 
should mention that such a linkage by different resource servers
will always be possible when using this profile.

Denis

---

From: Dick Hardt <[email-masked]>
Date: Mon, 13 Apr 2020 10:07:43 -0700

Why does the "sub" need to be required?

An access token is to prove authorization. The RS may not need "sub" to
constrain fulfilling the client request.

For example, it the access token has the same properties as a movie ticket,
the RS does not need to have any identifier for who purchased the movie
ticket.

The privacy implication is the RS can correlate across API calls to know it
is the same subject.

On Mon, Apr 13, 2020 at 8:16 AM Denis <[email-masked]> wrote:

>    - sub  REQUIRED - as defined in section 4.1.2 of [RFC7519].
>    - client_id  REQUIRED - as defined in section 4.3 of [RFC8693]
>
> *1) **sub  REQUIRED*
>
> RFC 7519 states:
>
>    about the subject.  The subject value MUST either be scoped to
> The client_id claim carries the client identiﬁer of the OAuth 2.0 [RFC
> 6749] client that requested the token.
>
> RFC 6749 states:
>
> 2.2.  Client Identifier
>    alone for client authentication.  *The client identifier is unique to*
> *   the authorization server.*
>

---

From: Aaron Parecki <[email-masked]>
Date: Mon, 13 Apr 2020 10:15:39 -0700

This is a good point, I often use the hotel key analogy as well. The room
door is the RS, the key is the access token, the door does not need to know
who the user is in order to know if it’s okay to unlock given a particular
key.

If sub is required, then this profile is limited in use to cases where user
identifiers are part of the system, and there will be situations in which
it’s not appropriate to use this profile for access tokens. If that’s okay,
this should be clarified in the overview section to describe when this
profile should be used.

Aaron

On Mon, Apr 13, 2020 at 10:08 AM Dick Hardt <[email-masked]> wrote:

> For example, it the access token has the same properties as a movie
> ticket, the RS does not need to have any identifier for who purchased the
> movie ticket.
>
> The privacy implication is the RS can correlate across API calls to know
> it is the same subject.
>
>
>
>
> On Mon, Apr 13, 2020 at 8:16 AM Denis <[email-masked]
> <[email-masked]>> wrote:
>
>> Hello,
>>
-- 
----
Aaron Parecki
aaronparecki.com
@aaronpk <http://twitter.com/aaronpk>

---

From: Vittorio Bertocci <[email-masked]>
Date: Mon, 13 Apr 2020 13:13:54 -0700

It’s certainly possible to conceive ATs without subs, but I think the
profile would be way less useful for SDK developers.
On the objections:
The sub doesn’t have to be a user, if you look at the earlier discussions
the case in which the token has been issued for an application via client
creds (hence non user) has been debated at length.
Knowing the subject does not necessarily lead to API being able to collide
and track users, given that the sub can be a PPID that is different for
every resource even if the authenticated subject was the same.

The sub is mandatory here because it was present in nearly every token
among the ones observed, and although one should not overindex on those
scenarios, I took that as strong indication that it is a frequently used
field and guaranteeing its presence facilitates embedding in SDKs lots of
downstream features, such as correlating with locally stored attributes,
which would otherwise left as exercise to the reader. Per the points above,
there are no obvious downsides in requiring the presence of the sub and
significant upsides. Again, the AS is in full control of the sub content
hence none of the privacy concerns mentioned here are mandated by the sheer
presence of the sub claim. If you feel the privacy section should be
stronger in warning an AS against the possibility of collusion if global
ide rockers are used, I am happy to reword accordingly

On Mon, Apr 13, 2020 at 10:16 Aaron Parecki <[email-masked]> wrote:

> If sub is required, then this profile is limited in use to cases where
> user identifiers are part of the system, and there will be situations in
> which it’s not appropriate to use this profile for access tokens. If that’s
> okay, this should be clarified in the overview section to describe when
> this profile should be used.
>
> Aaron
>
>
>

---

From: Vittorio Bertocci <[email-masked]>
Date: Mon, 13 Apr 2020 13:40:17 -0700

“Ide rockers” is iPhone autocorrect jargon for “identifiers”, of course :P

---

From: Dick Hardt <[email-masked]>
Date: Mon, 13 Apr 2020 18:04:46 -0700

An SDK is going to support "sub" wether it is required or optional.

On Mon, Apr 13, 2020 at 1:40 PM Vittorio Bertocci <[email-masked]>
wrote:

>> Knowing the subject does not necessarily lead to API being able to
>> collide and track users, given that the sub can be a PPID that is different
>> for every resource even if the authenticated subject was the same.
>>
>
The privacy correlation I described is not solved by a per resource
directed identifier as the resource is learning that the same user is doing
different transactions -- or per my example, the resource is learning all
the movies the user is seeing.

>> among the ones observed,
But NOT every token. So there were use cases where it was not required.

> and although one should not overindex on those scenarios, I took that as
>> strong indication that it is a frequently used field and guaranteeing its
>> presence facilitates embedding in SDKs lots of downstream features, such as
>> correlating with locally stored attributes, which would otherwise left as
>> exercise to the reader.
>>
>
NOT correlating all the different actions by the user may be the desired
privacy goal by a deployment.

> Per the points above, there are no obvious downsides in requiring the
>> presence of the sub and significant upsides. Again, the AS is in full
>> control of the sub content hence none of the privacy concerns mentioned
>> here are mandated by the sheer presence of the sub claim. If you feel the
>> privacy section should be stronger in warning an AS against the possibility
>> of collusion if global ide rockers are used, I am happy to reword
>> accordingly
>>
>
Per Aaron's comment, if this profile is NOT intended to support use cases
where the RS should not be able to correlate a user between resource
accesses, then it is fine for "sub" to be required. If so, then the
document should strongly point that out.

>>> This is a good point, I often use the hotel key analogy as well. The
>>> room door is the RS, the key is the access token, the door does not need to
>>> know who the user is in order to know if it’s okay to unlock given a
>>> particular key.
>>>
>>>> The privacy implication is the RS can correlate across API calls to
>>>> know it is the same subject.
>>>>
>>>>
>>>>
>>>>
>>>>> If *sub *is *REQUIRED *for this profile, then this allows all
>>>>> Would both names remain *REQUIRED*, the Privacy considerations
>>>>> section should mention that such a linkage by different resource servers

---

From: Vittorio Bertocci <[email-masked]>
Date: Mon, 13 Apr 2020 23:40:27 -0700

> An SDK is going to support "sub" wether it is required or optional.
When I think about support for sub in this case, I am not thinking about
just parsing the sub value if it’s present or not surfacing it in an object
model if it’s not- i think about reliably offering the higher level jobs to
be done that are made possible by the sub presence (such as the correlation
with the calling subject and local information, exactly as in your example
all the movies a user watched thru that particular API).

> the resource is learning that the same user is doing different
transactions
Thanks for the clarification, I didn’t realize that you were not just
considering correlation across resources, but across calls to the same API.
And you are right that in that case, an API would be able to correlate the
user across subsequent API calls.
Per the above, I think that the ability of performing that correlation
inter-API is a goal on most systems. More below.

> But NOT every token. So there were use cases where it was not required.
Not that it proves anything conclusively given that I only sampled 7
system, but sub was actually used by all of them- with one of them omitting
it only in a particular circumstance, for tokens issued via client
credentials grant, and leveraging its absence as a way of deducing the
nature of the token (user or app identity). During earlier drafts we
debated at length the issue of providing mechanics to perform that
distinction and the outcome was that there was no interest in providing it;
and in the same debate it was established that sub applies to the
authenticated entity, hence it can describe the app principal as well.
Again, the fact that the main analyzed systems don’t make a strong case for
the absence of sub doesn’t imply that no such case exist; but I believe it
is a strong indicator of sub usefulness in real world scenarios. In fact,
together with iss and aud, sub is the only claim appearing in every
provider JWT AT examined (Tho both sub and aud have each one exception due
to special circumstances).

I am fine with explicitly calling out that the presence of a mandatory sub
makes it possible for an API to correlate subsequent calls on the same
entity. I am ready to bet it won’t be a surprise for people using
proprietary JWT ATs, also thanks to the widespread practice of using
slightly modified ID token validation SDKs (when ID token themselves aren’t
directly used in lieu of ATs for API calls, as done by the likes of
Kubernetes and other mainstream products, which hopefully will eventually
consider this profile instead).

As a last resort, nothing forces the AS to stop at varying sub values only
per resource; it could go farther and supply a different sub value at every
token issuance for the same authenticating principal if it so chooses, and
still adhere to the letter of this profile while preventing cross operation
correlation. That would adhere to the letter of this interop spec if not
the the spirit, given that layout would be respected and one can creatively
define principals in its own system. If Apple can assign anti correlation
emails, nothing prevents an AS doing the same with sub at different
granularity.
That would break the job to be done that sub is meant to enable, but would
prevent correlation in practice AND it would allow for us to include a
piece of info that proved to be useful for a large portion of known cases.
But to reiterate, even if this workaround would not be possible, I would
still be OK with admitting cross operation correlation within the same
resource as by design.

On Mon, Apr 13, 2020 at 18:05 Dick Hardt <[email-masked]> wrote:

>>> The sub doesn’t have to be a user, if you look at the earlier
>>> discussions the case in which the token has been issued for an application
>>> via client creds (hence non user) has been debated at length.
>>>>> An access token is to prove authorization. The RS may not need "sub"
>>>>> to constrain fulfilling the client request.
>>>>>
>>>>>> unique to*
>>>>>> *Both claim names should be OPTIONAL *to allow to support the
>>>>>> privacy principle of unlinkability.
>>>>>>

---

From: Denis <[email-masked]>
Date: Tue, 14 Apr 2020 16:23:02 +0200

Vittorio, some comments in line:

> When I think about support for sub in this case, I am not thinking 
> about just parsing the sub value if it’s present or not surfacing it 
> in an object model if it’s not- i think about reliably offering the 
> higher level jobs to be done that are made possible by the sub 
> presence (such as the correlation with the calling subject and local 
> information, exactly as in your example all the movies a user watched 
> thru that particular API).
>
> considering correlation across resources, but across calls to the same 
> API. And you are right that in that case, an API would be able to 
> correlate the user across subsequent API calls.
> system, but sub was actually used by all of them- with one of them 
> omitting it only in a particular circumstance, for tokens issued via 
> client credentials grant, and leveraging its absence as a way of 
> deducing the nature of the token (user or app identity). During 
> earlier drafts we debated at length the issue of providing mechanics 
> to perform that distinction and the outcome was that there was no 
> interest in providing it; and in the same debate it was established 
> that sub applies to the authenticated entity, hence it can describe 
> the app principal as well.
> Again, the fact that the main analyzed systems don’t make a strong 
> case for the absence of sub doesn’t imply that no such case exist; but 
> I believe it is a strong indicator of sub usefulness in real world 
> scenarios. In fact, together with iss and aud, sub is the only claim 
> appearing in every provider JWT AT examined (Tho both sub and aud have 
> each one exception due to special circumstances).
>
> I am fine with explicitly calling out that the presence of a mandatory 
> sub makes it possible for an API to correlate subsequent calls on the 
> same entity.

I agree with you that the ability of performing correlation inter-API is 
a goal on most systems. However, this correlation *alone *CANNOT be 
achieved
using the sub claim using the definition of sub as defined in RFC 7519 
(4.1.2):

         The subject value MUST either be scoped to be *locally unique 
in the context of the issuer or be globally unique*.

Using the sub claim for inter-API correlation purposes would necessarily 
allow correlation across different resources.

In the "Privacy considerations" section, whether sub is REQUIRED or 
OPTIONAL, the reader should be warned that the presence of the "sub" 
(subject) claim
in a JWT makes it possible for different resources to correlate 
different calls, as well as for the same resource to correlate between 
inter-API calls.

> I am ready to bet it won’t be a surprise for people using proprietary 
> JWT ATs, also thanks to the widespread practice of using slightly 
> modified ID token validation SDKs
> (when ID token themselves aren’t directly used in lieu of ATs for API 
> calls, as done by the likes of Kubernetes and other mainstream 
> products, which hopefully will
> eventually consider this profile instead).
>
> As a last resort, nothing forces the AS to stop at varying sub values 
> only per resource; it could go farther and supply a different sub 
> value at every token issuance
> for the same authenticating principal if it so chooses, and still 
> adhere to the letter of this profile while preventing cross operation 
> correlation.

Unfortunately, this is not possible since RFC 7519 (4.1.2) states:

         The subject value MUST either be scoped to be *locally unique 
in the context of the issuer or be globally unique*.

> That would adhere to the letter of this interop spec if not the the 
> spirit, given that layout would be respected and one can creatively 
> define principals in its own system.
> If Apple can assign anti correlation emails, nothing prevents an AS 
> doing the same with sub at different granularity.
> That would break the job to be done that sub is meant to enable, but 
> would prevent correlation in practice AND it would allow for us to 
> include a piece of info
> that proved to be useful for a large portion of known cases. But to 
> reiterate, even if this workaround would not be possible,
> I would still be OK with admitting cross operation correlation within 
> the same resource as by design.

...  and I hope you are also OK for admitting cross correlation of 
subjects between different resources. The question whether this was also 
done "by design" (or not) is left open.

Similar considerations apply for the client_id (client identifier) since 
RFC 6749 (2.2) states:

       The client identifier [i.e. a unique string representing the 
registration information provided by the client] is *unique to the 
authorization server*.

Denis

>
>
> On Mon, Apr 13, 2020 at 18:05 Dick Hardt <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>
>
>     On Mon, Apr 13, 2020 at 1:40 PM Vittorio Bertocci
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>         On Mon, Apr 13, 2020 at 13:13 Vittorio Bertocci
>         <[email-masked] <mailto:[email-masked]>> wrote:
>
>             It’s certainly possible to conceive ATs without subs, but
>             I think the profile would be way less useful for SDK
>             developers.
>             On the objections:
>             The sub doesn’t have to be a user, if you look at the
>             earlier discussions the case in which the token has been
>             issued for an application via client creds (hence non
>             user) has been debated at length.
>             Knowing the subject does not necessarily lead to API being
>             able to collide and track users, given that the sub can be
>             a PPID that is different for every resource even if the
>             authenticated subject was the same.
>
>
>     The privacy correlation I described is not solved by a per
>     resource directed identifier as the resource is learning that the
>     same user is doing different transactions -- or per my example,
>     the resource is learning all the movies the user is seeing.
>
>
>             The sub is mandatory here because it was present in nearly
>             every token among the ones observed,
>
>
>             and although one should not overindex on those scenarios,
>             I took that as strong indication that it is a frequently
>             used field and guaranteeing its presence facilitates
>             embedding in SDKs lots of downstream features, such as
>             correlating with locally stored attributes, which would
>             otherwise left as exercise to the reader.
>
>
>     NOT correlating all the different actions by the user may be the
>     desired privacy goal by a deployment.
>
>             Per the points above, there are no obvious downsides in
>             requiring the presence of the sub and significant upsides.
>             Again, the AS is in full control of the sub content hence
>             none of the privacy concerns mentioned here are mandated
>             by the sheer presence of the sub claim. If you feel the
>             privacy section should be stronger in warning an AS
>             against the possibility of collusion if global ide rockers
>             are used, I am happy to reword accordingly
>
>
>     Per Aaron's comment, if this profile is NOT intended to support
>     use cases where the RS should not be able to correlate a user
>     between resource accesses, then it is fine for "sub" to be
>     required. If so, then the document should strongly point that out.
>
>
>             On Mon, Apr 13, 2020 at 10:16 Aaron Parecki
>             <aaron@parecki..com <mailto:[email-masked]>> wrote:
>
>                 This is a good point, I often use the hotel key
>                 analogy as well. The room door is the RS, the key is
>                 the access token, the door does not need to know who
>                 the user is in order to know if it’s okay to unlock
>                 given a particular key.
>
>                 If sub is required, then this profile is limited in
>                 use to cases where user identifiers are part of the
>                 system, and there will be situations in which it’s not
>                 appropriate to use this profile for access tokens. If
>                 that’s okay, this should be clarified in the overview
>                 section to describe when this profile should be used.
>
>                 Aaron
>
>
>
>                 On Mon, Apr 13, 2020 at 10:08 AM Dick Hardt
>                 <[email-masked] <mailto:[email-masked]>>
>                 wrote:
>
>                     An access token is to prove authorization. The RS
>                     may not need "sub" to constrain fulfilling the
>                     client request.
>
>                     For example, it the access token has the same
>                     properties as a movie ticket, the RS does not need
>                     to have any identifier for who purchased the movie
>                     ticket.
>
>                     The privacy implication is the RS can correlate
>                     across API calls to know it is the same subject.
>
>
>
>
>                     On Mon, Apr 13, 2020 at 8:16 AM Denis
>                     <[email-masked] <mailto:[email-masked]>>
>                     wrote:
>
>                         Hello,
>
>                         If *sub *is *REQUIRED *for this profile, then
>                         this allows all resource servers to link
>                         accesses made by the same client on different
>                         servers.
>
>                         *2) client_id  REQUIRED*
>
>                         RFC 8693 states:
>
>                             The client_id claim carries the client
>                             identiﬁer of the OAuth 2.0 [RFC 6749]
>                             client that requested the token.
>
>                         RFC 6749 states:
>
>                             2.2.  Client Identifier
>                                alone for client authentication. *The
>                             client identifier is unique to**
>                         If *client_id* is REQUIRED for this profile,
>                         this also allows all resource servers to link
>                         accesses made by the same client on different
>                         servers.
>
>                         *Both claim names should be OPTIONAL *to allow
>                         to support the privacy principle of unlinkability.
>
>                         Would both names remain *REQUIRED*, the
>                         Privacy considerations section should mention
>                         that such a linkage by different resource servers
>>                         I have uploaded the second presentation for
>>                         today's session, the JWT Profile for Access
>>                         Tokens.
>                         [email-masked] <mailto:[email-masked]>
>                     [email-masked] <mailto:[email-masked]>
>                 aaronparecki.com <http://aaronparecki.com>
>                 [email-masked] <mailto:[email-masked]>

---

From: Denis <[email-masked]>
Date: Tue, 14 Apr 2020 16:38:09 +0200

Vittorio, one comment in line.
> discussions the case in which the token has been issued for an 
> application via client creds (hence non user) has been debated at length.
> collide and track users, given that the sub can be a PPID that is 
> different for every resource even if the authenticated subject was the 
> same.
>
> among the ones observed, and although one should not overindex on 
> those scenarios, I took that as strong indication that it is a 
> frequently used field and guaranteeing its presence facilitates 
> embedding in SDKs lots of downstream features, such as correlating 
> with locally stored attributes, which would otherwise left as exercise 
> to the reader. Per the points above, there are no obvious downsides in 
> requiring the presence of the sub and significant upsides. Again, the 
> AS is in full control of the sub content hence none of the privacy 
> concerns mentioned here are mandated by the sheer presence of the sub 
> claim.

> If you feel the privacy section should be stronger in warning an AS 
> [identifiers] are used, I am happy to reword accordingly.

Text needs to added into the Privacy consideration section stating more 
than that.

Since RFC 7519 (4.1.2) states:

     The subject value MUST either be scoped to be *locally unique* in 
the context of the issuer *or* be *globally unique*.

the presence of the sub claim in a JWT allows (1) different resource 
servers to perform correlations of actions performed by the same subject
on these different resource servers and (2) a single resource server to 
perform inter-API correlations of actions performed by the same subject.
Since a single claim parameter is being used, it is not possible to have 
only one of the two previous cases.

Denis

>
> On Mon, Apr 13, 2020 at 10:16 Aaron Parecki <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     This is a good point, I often use the hotel key analogy as well.
>     The room door is the RS, the key is the access token, the door
>     does not need to know who the user is in order to know if it’s
>     okay to unlock given a particular key.
>
>     If sub is required, then this profile is limited in use to cases
>     where user identifiers are part of the system, and there will be
>     situations in which it’s not appropriate to use this profile for
>     access tokens. If that’s okay, this should be clarified in the
>     overview section to describe when this profile should be used.
>
>     Aaron
>
>
>
>     On Mon, Apr 13, 2020 at 10:08 AM Dick Hardt <[email-masked]
>         An access token is to prove authorization. The RS may not need
>         "sub" to constrain fulfilling the client request.
>
>         For example, it the access token has the same properties as a
>         movie ticket, the RS does not need to have any identifier for
>         who purchased the movie ticket.
>
>         The privacy implication is the RS can correlate across API
>         calls to know it is the same subject.
>
>
>
>
>         <mailto:[email-masked]>> wrote:
>
>             Hello,
>
>             If *sub *is *REQUIRED *for this profile, then this allows
>             all resource servers to link accesses made by the same
>             client on different servers.
>
>             *2) client_id  REQUIRED*
>
>             RFC 8693 states:
>
>                 The client_id claim carries the client identiﬁer of
>                 the OAuth 2.0 [RFC 6749] client that requested the token.
>
>             RFC 6749 states:
>
>                 2.2.  Client Identifier
>                    alone for client authentication. *The client
>                 identifier is unique to**
>             If *client_id* is REQUIRED for this profile, this also
>             allows all resource servers to link accesses made by the
>             same client on different servers.
>
>             *Both claim names should be OPTIONAL *to allow to support
>             the privacy principle of unlinkability.
>
>             Would both names remain *REQUIRED*, the Privacy
>             considerations section should mention that such a linkage
>             by different resource servers
>>             I have uploaded the second presentation for today's
>>             session, the JWT Profile for Access Tokens.

---

From: George Fletcher <[email-masked]>
Date: Tue, 14 Apr 2020 11:03:54 -0400

> in the context of the issuer or be globally unique*.
Regarding this phrase from RFC 7519, I don't agree that it prevents the 
solution Vittorio suggested. While for any token issued the 'sub' claim 
must be unique (local to the issuer or globally); that doesn't mean it 
can't be different with every issued token. This would require the 
client to request a new token before every API invocation but it would 
suffice to protect against the suggested privacy correlation issues.

Note that inter-API correlation prevention is VERY difficult and really 
requires a unique token for every API call as the token itself can be a 
correlation handle (e.g. hash the token and it becomes the correlation 
identifier if the token is being reused for multiple API calls).

Thanks,
George

---

From: Denis <[email-masked]>
Date: Tue, 14 Apr 2020 17:23:07 +0200

George,

I disagree with you:

    The 'sub' claim must be unique (local to the issuer or globally)
    with every issued token.

In addition, inter-API correlation prevention does not necessarily 
require a unique token for every API call,
since in many cases a session can be opened and one JWT can be used 
during the whole session (during successive calls).

Denis

> Regarding this phrase from RFC 7519, I don't agree that it prevents 
> the solution Vittorio suggested. While for any token issued the 'sub' 
> claim must be unique (local to the issuer or globally); that doesn't 
> mean it can't be different with every issued token. This would require 
> the client to request a new token before every API invocation but it 
> would suffice to protect against the suggested privacy correlation 
> issues.
>
> Note that inter-API correlation prevention is VERY difficult and 
> really requires a unique token for every API call as the token itself 
> can be a correlation handle (e.g. hash the token and it becomes the 
> correlation identifier if the token is being reused for multiple API 
> calls).
>
> Thanks,
> George
>

---

From: George Fletcher <[email-masked]>
Date: Tue, 14 Apr 2020 11:32:54 -0400

Hi Denis,

If the same token is used (within a session) for multiple API calls then 
all those API calls can be correlated together even if the token does 
not have a 'sub' claim because the token itself is the correlating 
identifier (same is true for the session identifier).

In regards to the AS issuing a token with a 'sub' claim, after 
re-reading the spec (rfc 7519) I believe the AS could issue the 'sub' 
value as "urn:anonymous:<large random number>" and create a new value 
with every token that is issued. This is similar to how Shibboleth 
supports attribute based access control with SAML assertions. Given it 
appears we disagree in our interpretations of the spec, I'm fine 
agreeing to disagree :)

Thanks,
George

On 4/14/20 11:23 AM, Denis wrote:
>>>         The subject value MUST either be scoped to be *locally 
>>> unique in the context of the issuer or be globally unique*.
>> mean it can't be different with every issued token. This would 
>> require the client to request a new token before every API invocation 
>> but it would suffice to protect against the suggested privacy 
>> correlation issues.
>>

---

From: Vittorio Bertocci <[email-masked]>
Date: Tue, 14 Apr 2020 18:07:41 +0000

Thanks George, you described exactly what I was thinking.
I agree with your conclusions throughout the thread. Now that we have JTI mandatory, preventing tracking intra-API could be achieved only by issuing a new token for every transaction regardless of the presence of a sub, and a sub whose values change at every issuance would achieve the same.
One subtlety that perhaps is worth spelling out is that “unique” in this context shouldn’t be interpreted as “singleton”. An identifier is unique if it cannot be used to indicate any entity other than the intended one, but that doesn’t prevent the same entity from having multiple unique identifiers as long as they all satisfy that uniqueness criterion. And again, I maintain that preventing intra-API tracking is a non-goal in most scenarios.

That said, this was a great discussion. I am going to add explicit language in the privacy considerations warning readers about the possibility of correlation, and hinting at some of the measures described here as possible mitigations.
Thanks everyone!
V.

From: OAuth <[email-masked]> on behalf of George Fletcher <gffletch=[email-masked]>
Date: Tuesday, April 14, 2020 at 08:35
To: Denis <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2020-04-13

Hi Denis,

If the same token is used (within a session) for multiple API calls then all those API calls can be correlated together even if the token does not have a 'sub' claim because the token itself is the correlating identifier (same is true for the session identifier).

In regards to the AS issuing a token with a 'sub' claim, after re-reading the spec (rfc 7519) I believe the AS could issue the 'sub' value as "urn:anonymous:<large random number>" and create a new value with every token that is issued. This is similar to how Shibboleth supports attribute based access control with SAML assertions. Given it appears we disagree in our interpretations of the spec, I'm fine agreeing to disagree :)

Thanks,
George

I disagree with you:

In addition, inter-API correlation prevention does not necessarily require a unique token for every API call,
since in many cases a session can be opened and one JWT can be used during the whole session (during successive calls).

Denis

        The subject value MUST either be scoped to be *locally unique in the context of the issuer or be globally unique*.
Regarding this phrase from RFC 7519, I don't agree that it prevents the solution Vittorio suggested. While for any token issued the 'sub' claim must be unique (local to the issuer or globally); that doesn't mean it can't be different with every issued token. This would require the client to request a new token before every API invocation but it would suffice to protect against the suggested privacy correlation issues.

Note that inter-API correlation prevention is VERY difficult and really requires a unique token for every API call as the token itself can be a correlation handle (e.g. hash the token and it becomes the correlation identifier if the token is being reused for multiple API calls).

Thanks,
George

---

From: "Manger, James" <[email-masked]>
Date: Wed, 15 Apr 2020 07:37:17 +0000

> the AS could issue the 'sub' value as "urn:anonymous:<large random number>" and create a new value with every token that is issued

But it those cases it would be better to omit "sub", instead of sending a per-token value (we have "jti" as a per-token id). That at least avoids other parties misinterpreting these unusual "sub"s as long-term ids (and, for example, creating persistent user entries for each one).

--
James Manger

---

From: Vittorio Bertocci <[email-masked]>
Date: Wed, 15 Apr 2020 08:39:07 +0000

Thanks James!
If those scenarios would be an explicit target, then omitting the sub would indeed eliminate any chance of misinterpreting. However those remain fairly theoretical, and would already be pretty problematic in themselves given the need to get a new token per call in order to prevent jti based correlation- I don’t think it’s worth introducing in the spec the possibility to omit the sub, and risk not having it when it’s useful if it’s omitted by mistake in a mainstream scenario, to prevent a possible misinterpretation in a less common scenario.
If you feel very strongly about this, we can complement the warning in the privacy considerations in draft-06 to highlight this scenario- but honestly that seems overkill to me :)
Thanks
V.

From: "Manger, James" <[email-masked]>
Date: Wednesday, April 15, 2020 at 00:37
To: Vittorio Bertocci <[email-masked]>, George Fletcher <[email-masked]>, Denis <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2020-04-13

> the AS could issue the 'sub' value as "urn:anonymous:<large random number>" and create a new value with every token that is issued

But it those cases it would be better to omit “sub”, instead of sending a per-token value (we have “jti” as a per-token id). That at least avoids other parties misinterpreting these unusual “sub”s as long-term ids (and, for example, creating persistent user entries for each one).

--
James Manger

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Fri, 17 Apr 2020 12:25:46 -0400

All,

You can find this meeting minutes at the following link:
https://datatracker.ietf.org/doc/minutes-interim-2020-oauth-04-202004131200/

Thanks to *Jared Jennings *for taking these notes.

Regards,
 Rifaat & Hannes