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

[George Fletcher <[e-mail]>]

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:
> 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
>
>>
>>
>> On 4/14/20 10:23 AM, Denis wrote:
>>> 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*.
>> 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
>>