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

[Vittorio Bertocci <[e-mail]>]

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
>