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
>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
