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
