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