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

[Hans Zandbelt <[e-mail]>]

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