Vittorio, one comment in line.
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
[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 <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
