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

[Vittorio Bertocci <[e-mail]>]

I am not following. We want this to be adopted, right? :) if we provide
guidance that is sound but hard to implement we are going to fail.
Considerations on whether the guidance requires a big effort to be applied
are very much in scope for me.

On Mon, May 6, 2019 at 14:54 Hans Zandbelt <[e-mail]>
wrote:

> the scope and way of generating sub/client_id is orthogonal to the
> semantics IMHO but if I'm the only one who thinks so, I'll rest my case
>
> Hans.
>
> On Mon, May 6, 2019 at 10:49 PM Vittorio Bertocci <[e-mail]>
> wrote:
>
>> See below, Hans- the sub doesn’t have to be global, it could be something
>> generated just for this particular RS. Or the AS might have its own recipe
>> for generating sub values that different from the recipe used to generate
>> client_ids. It would be much easier for an AS to emit a claim making this
>> explicit statement than to change sub and client_id assignment logic.
>>
>> On Mon, May 6, 2019 at 13:49 Hans Zandbelt <[e-mail]>
>> wrote:
>>
>>> I may be missing something but I'd argue that by requiring and comparing
>>> both "sub" and "client_id" we achieve the same semantics without a
>>> new/additional claim (barring name spacing)
>>>
>>> Hans.
>>>
>>> On Mon, May 6, 2019 at 8:58 PM Karl McGuinness <kmcguinness=
>>> [e-mail]> wrote:
>>>
>>>> Makes sense that we don’t want to further couple AS and RS with grant
>>>> types.  I’m OK if we want a dedicated claim to establish whether the token
>>>> is resource owner delegated  vs client acting as itself.
>>>>
>>>> Subject Type is already a concept in RISC.  Just making folks are aware
>>>> of prior art.
>>>>
>>>> https://openid.net/specs/oauth-event-types-1_0-01.html#rfc.section.2.2
>>>> https://openid.net/specs/openid-risc-profile-1_0.html#rfc.section.2.1
>>>>
>>>> -Karl
>>>>
>>>> On May 6, 2019, at 12:42 PM, Vittorio Bertocci <
>>>> Vittorio=[e-mail]> wrote:
>>>>
>>>> *This message originated outside your organization.*
>>>> ------------------------------
>>>> Fair enough! What others think about it?
>>>> Exploring the approach: would we want a bool claim or an enumeration,
>>>> e.g. sub_type = [ resource_owner | client ] ?
>>>>
>>>>
>>>> On Mon, May 6, 2019 at 12:35 PM Vladimir Dzhuvinov <
>>>> [e-mail]> wrote:
>>>>
>>>>> 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
>>>>>
>>>>>
>>>>> _______________________________________________
>>>> OAuth mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>>>
>>>
>>> --
>>> [e-mail]
>>> ZmartZone IAM - www.zmartzone.eu
>>> _______________________________________________
>>> OAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>
>
> --
> [e-mail]
> ZmartZone IAM - www.zmartzone.eu
>