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 <oauth-boun...@ietf.org> on behalf of George Fletcher
<gffletch=40aol....@dmarc.ietf.org>
Date: Tuesday, April 14, 2020 at 08:35
To: Denis <denis.i...@free.fr>, "oauth@ietf.org" <oauth@ietf.org>
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
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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
