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