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

[Vittorio Bertocci <[e-mail]>]

“Ide rockers” is iPhone autocorrect jargon for “identifiers”, of course :P

On Mon, Apr 13, 2020 at 13:13 Vittorio Bertocci <[e-mail]> 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 <[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]> 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>
>>
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>