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 stuffHans. On Mon, May 6, 2019 at 11:22 PM Vittorio Bertocci <[email protected]> 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 <[email protected]> > 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 <[email protected]> >> 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 <[email protected]> >>> 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 <[email protected]> >>>> 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 <[email protected]> >>>>> 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= >>>>>> [email protected]> 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 < >>>>>>> [email protected]> 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 < >>>>>>> [email protected]> 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 < >>>>>>>> [email protected]> >>>>>>>> > 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 >>>>>>>> >> [email protected] >>>>>>>> >> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>> >> >>>>>>>> -- >>>>>>>> Vladimir Dzhuvinov >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> [email protected] >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> [email protected] >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> [email protected] >>>>>> ZmartZone IAM - www.zmartzone.eu >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> [email protected] >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>>> >>>> >>>> -- >>>> [email protected] >>>> ZmartZone IAM - www.zmartzone.eu >>>> >>> >> >> -- >> [email protected] >> ZmartZone IAM - www.zmartzone.eu >> > -- [email protected] ZmartZone IAM - www.zmartzone.eu
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
