Vittorio, some comments in line:
> 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 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 <dick.ha...@gmail.com
<mailto:dick.ha...@gmail.com>> wrote:
An SDK is going to support "sub" wether it is required or optional.
On Mon, Apr 13, 2020 at 1:40 PM Vittorio Bertocci
<vitto...@auth0.com <mailto:vitto...@auth0.com>> wrote:
“Ide rockers” is iPhone autocorrect jargon for “identifiers”,
of course :P
On Mon, Apr 13, 2020 at 13:13 Vittorio Bertocci
<vitto...@auth0.com <mailto:vitto...@auth0.com>> 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,
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.
On Mon, Apr 13, 2020 at 10:16 Aaron Parecki
<aa...@parecki..com <mailto:aa...@parecki.com>> 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
<dick.ha...@gmail.com <mailto:dick.ha...@gmail.com>>
wrote:
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
<denis..i...@free.fr <mailto:denis.i...@free.fr>>
wrote:
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 Identifier) Claim
The client_id claim carries the client
identifier 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
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
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
--
----
Aaron Parecki
aaronparecki.com <http://aaronparecki.com>
@aaronpk <http://twitter.com/aaronpk>
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
