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> 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> > 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> 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
