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
