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

[Hans Zandbelt <[e-mail]>]

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