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