Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

[Vladimir Dzhuvinov <[e-mail]>]

Hi Vittorio,

On 06/05/2019 22:22, Vittorio Bertocci wrote:
> It is true that the grant_type is a client side consideration. I did think
> about the "client_id==sub" heuristic, but that's not always applicable:
> many systems have their own rules for generating sub, and in case they want
> to prevent tracking across RSes the sub might be generated ad-hoc for that
> particular RS.
> Would you prefer to have a dedicated claim that distinguish between user
> and app tokens rather than reusing grant_type?

A dedicated claim to flag client_id effectively == sub would be
preferable, and much easier for RS developers to process.

The AS is the authority and has all the knowledge to set / indicate this.

I want to keep RS developers away from having to deal with grant types
and having to make decisions whether client_id effectively == sub.

Vladimir


> On Mon, May 6, 2019 at 12:16 PM Vladimir Dzhuvinov <[e-mail]>
> wrote:
>
>> On 06/05/2019 20:32, Vittorio Bertocci wrote:
>>> To that end, *Karl MCGuinness suggested that we include
>>> grant_type as a return claim, which the RS could use to the same
>> effect*. I
>>> find the proposal very clever, and the people at IIW thought so as well.
>>> What you think?
>> The grant type is not something that the RS is really concerned with, or
>> should be. Introducing this parameter in the access token will create an
>> additional logical dependency, plus complexity - in the system of
>> client, AS and RS as a whole, as well as for RS developers. The grant
>> type, as a concept, is a matter between the client and AS, and IMO
>> should stay that way.
>>
>> Clear language in the spec should suffice. For instance: "If the sub
>> value matches the client_id value, then the subject is the client
>> application".
>>
>> Vladimir
>>
>> --
>> Vladimir Dzhuvinov
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
-- 
Vladimir Dzhuvinov