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