Re: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2020-04-13

[Denis <[e-mail]>]

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 <[e-mail] 
> <mailto:[e-mail]>> 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 <[e-mail]
>     <mailto:[e-mail]>> 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 <[e-mail]
>         <mailto:[e-mail]>> 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
>             [e-mail] <mailto:[e-mail]>
>             https://www.ietf.org/mailman/listinfo/oauth
>
>         _______________________________________________
>         OAuth mailing list
>         [e-mail] <mailto:[e-mail]>
>         https://www.ietf.org/mailman/listinfo/oauth
>
>     -- 
>     ----
>     Aaron Parecki
>     aaronparecki.com <http://aaronparecki.com>
>     @aaronpk <http://twitter.com/aaronpk>
>
>     _______________________________________________
>     OAuth mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth