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

[Hans Zandbelt <[e-mail]>]

I understand your legacy-breaking point (and do see a name spacing hurdle)
but:
a. I feel we're now painting ourselves into a corner ("soft doctors make
stinking wounds").
b. putting the client_id into the sub value would be something that any
product should be able to do, just like putting an extra claim in; I don't
think that is fundamental stuff

Hans.

On Mon, May 6, 2019 at 11:22 PM Vittorio Bertocci <[e-mail]>
wrote:

> Let me try a different angle. An AS might generate sub claims and
> client_id identifiers using a different format/template. That means that
> there might be a client with client_id X that gets assigned a sub value Y,
> despite the client being the same, hence the check “sub==client_id” would
> fail.
> The logic producing this might be hard for an AS to change as there has
> never been any requirement on client_id or sub formats hence everyone was
> free until now to use whatever logic they chose, including name spacing one
> but not the other and any other variation, and changes might have ripple
> effects downstream on systems that have nothing to do w this spec (eg
> sharing of where clients are stored might depend on the internal structure
> of the client_id). So in other words, an AS might have to touch pretty
> fundamental stuff in its logic and potentially impact scenarios that have
> no direct bearing with the JWT AT profile just for making that condition
> true. On the other plate of the scale, there’s adding a new claim- which I
> can literally already do in various commercial ASes via extensibility
> points, without changing their code.
>
>
> On Mon, May 6, 2019 at 15:11 Hans Zandbelt <[e-mail]>
> wrote:
>
>> I'm suggesting that whichever "sub" and "client_id" the RS is receiving
>> and however it was generated, it must mean something to it in alignment
>> with the JWT/OAuth2/OIDC specs, otherwise it wouldn't be there at all;
>> moreover, if the "sub" has the same value as "client_id" it must be a
>> client talking to the RS on behalf of its own and the claims are associated
>> with the client; if the "sub" has a different value than the "client_id" it
>> must be a scenario where the client presents a token delegated by a
>> Resource Owner and the claims are about the Resource Owner. Problem solved?
>>
>> Hans.
>>
>> On Mon, May 6, 2019 at 11:06 PM Vittorio Bertocci <[e-mail]>
>> wrote:
>>
>>> 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
>>>>
>>>
>>
>> --
>> [e-mail]
>> ZmartZone IAM - www.zmartzone.eu
>>
>

-- 
[e-mail]
ZmartZone IAM - www.zmartzone.eu