It looks like we'll have to agree to disagree on this one :) to me we
aren't using 3 claims to say that the token is about the client. Sub and
client_id have their independent reasons to be in the token. Expressing the
fact that a token is about an app should not have the side effect of
forbidding a sub to be RS-specific, for example.
On Tue, May 7, 2019 at 12:30 AM Hans Zandbelt <hans.zandb...@zmartzone.eu>
wrote:
> using 2 existing + 1 new (=3) claims to say the token is about the client
> to me suggests something went sideways in the past and were unable to fix
> it in a clean way
>
> Hans.
>
> On Tue, May 7, 2019 at 8:25 AM Vittorio Bertocci <vitto...@auth0.com>
> wrote:
>
>> For many of the products I have been and I am working on, sub and
>> client_id can't be arbitrarily changed - the examples I provided aren't
>> hypothetical: in my research *all *the providers adding sub in their app
>> only ATs (Azure AD, Auth0, Ping Identity) had different values in sub and
>> in the claim they used to indicate the client identifier. For at least
>> Auth0 and AAD you can't use arbitrary client_ids/formats, you get them
>> assigned by the system.
>> That's not really legacy, it's current practice - with no counter
>> indications, really. It's not that we are being soft, handling sub and
>> client_id differently isn't some kind of bad practice nor has any security
>> implications. It's an internal implementation detail.
>>
>> I am not sure I see how having a specialized claim would paint us in a
>> corner more than imposing the constraint you are suggesting. That seems to
>> do the exact opposite: it helps ASes to provide the desired functionality
>> without imposing changes that will ripple across their codebase well beyond
>> this particular use case.
>>
>> On Tue, May 7, 2019 at 12:07 AM Hans Zandbelt <hans.zandb...@zmartzone.eu>
>> wrote:
>>
>>> 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 <vitto...@auth0.com>
>>> 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 <hans.zandb...@zmartzone.eu>
>>>> 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 <vitto...@auth0.com>
>>>>> 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 <
>>>>>> hans.zandb...@zmartzone.eu> 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 <
>>>>>>> vitto...@auth0.com> 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 <
>>>>>>>> hans.zandb...@zmartzone.eu> 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=
>>>>>>>>> 40okta....@dmarc.ietf.org> 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=40auth0....@dmarc.ietf.org> 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 <
>>>>>>>>>> vladi...@connect2id.com> 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 <
>>>>>>>>>>> vladi...@connect2id.com>
>>>>>>>>>>> > 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
>>>>>>>>>>> >> OAuth@ietf.org
>>>>>>>>>>> >> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>>>>> >>
>>>>>>>>>>> --
>>>>>>>>>>> Vladimir Dzhuvinov
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>> OAuth mailing list
>>>>>>>>>> OAuth@ietf.org
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> OAuth mailing list
>>>>>>>>>> OAuth@ietf.org
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> hans.zandb...@zmartzone.eu
>>>>>>>>> ZmartZone IAM - www.zmartzone.eu
>>>>>>>>> _______________________________________________
>>>>>>>>> OAuth mailing list
>>>>>>>>> OAuth@ietf.org
>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> hans.zandb...@zmartzone.eu
>>>>>>> ZmartZone IAM - www.zmartzone.eu
>>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> hans.zandb...@zmartzone.eu
>>>>> ZmartZone IAM - www.zmartzone.eu
>>>>>
>>>>
>>>
>>> --
>>> hans.zandb...@zmartzone.eu
>>> ZmartZone IAM - www.zmartzone.eu
>>>
>>
>
> --
> hans.zandb...@zmartzone.eu
> ZmartZone IAM - www.zmartzone.eu
>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
