“Ide rockers” is iPhone autocorrect jargon for “identifiers”, of course :P
On Mon, Apr 13, 2020 at 13:13 Vittorio Bertocci <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 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 are used, I am happy to reword accordingly > > On Mon, Apr 13, 2020 at 10:16 Aaron Parecki <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> 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 >>> <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 >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> -- >> ---- >> Aaron Parecki >> aaronparecki.com >> @aaronpk <http://twitter.com/aaronpk> >> >> _______________________________________________ >> 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
