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

[Aaron Parecki <[e-mail]>]

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