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