Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

Vittorio Bertocci <Vittorio@auth0.com> Wed, 08 May 2019 20:57 UTC

Return-Path: <vittorio.bertocci@auth0.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0C2E12022D for <oauth@ietfa.amsl.com>; Wed, 8 May 2019 13:57:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auth0.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x1lI5hSXU7jC for <oauth@ietfa.amsl.com>; Wed, 8 May 2019 13:57:11 -0700 (PDT)
Received: from mail-lj1-x242.google.com (mail-lj1-x242.google.com [IPv6:2a00:1450:4864:20::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E45121200EC for <oauth@ietf.org>; Wed, 8 May 2019 13:57:10 -0700 (PDT)
Received: by mail-lj1-x242.google.com with SMTP id r76so88140lja.12 for <oauth@ietf.org>; Wed, 08 May 2019 13:57:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=i2pcK6FGMbFw1Myr3NgPJaqC9OTGQh4q39gFNoAJruY=; b=VwDjL0SNlE+m02sCYAweXtH/Hy6ufOxD8eQ57/CGDNaD+Oizs/nXdeP5WfSg1UbLkT xc6uaOY3Ieu6Oa+Ew9DZCEdlhGFHv+MSamcLyiSnQiGr8me9G6PvSVb31vvmxm7tDMbw P89yQdjWuOO6aqVyWPKL6zItSUetCm4TruQmmTaLitB06oBV7YpjmgOeuF+X/XWCkVRT ZtkHc9DQjeZStMR31FYqONvT0WgcUuDBDN+brdgS/3n0T4ezxxv5WC9gxRGZMqq8il0c 7jz3LAd/pFWVPPQR7sZ8JDh2ifXbvXcjQdqhNLsipGvMHbL4fC7zm9DFniMGhhwHvcoo AL3w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=i2pcK6FGMbFw1Myr3NgPJaqC9OTGQh4q39gFNoAJruY=; b=XbsRXs9yJw+TZXg+i6R7xvIr2KSEBIPxX8OtUhszUCrwVHixyPlW5DJHKiLlZlpPnq /REWOvKX+NmyVhoVRUgiEEgvz4SxKSsATVmPTteXyJyA41zrt/aCV3wDlzIEGSs7s610 IOgoVIngzt9+7i71JtfTOs6k6Q1b4924mV1NDNoI34lqWu7dy5+iYuY8tHzTmxz6eU92 JuUwutMYqwzCZFwirVOGapTYOeRANbg6vK+x0aFjWPj2Tle37otaXpp3hLEZnwf7zhKd /6njRkYGYzY+OZDxMLrNhS2OFkGsHJfTxKm2GhANc/dgY/Sc0+lr5NLFO14ImukdHYN5 VX7g==
X-Gm-Message-State: APjAAAVFsheIJ62u+nXEmW/voykN+mK0CNNhYeduxdYJWevB7iRU7d56 Lmtx6xui7jtdRvt6x9sjjkoh4v3mcleXWeBIcZQYCw==
X-Google-Smtp-Source: APXvYqwgmsHlFc8HtI0UJFYpBu5fFTS84Ymy/CpIAIf6wFL84jWRYgTVXsRSqxqxr7xj34/xFW5LXqhjwcMvQkp+XRA=
X-Received: by 2002:a2e:9a0a:: with SMTP id o10mr12264237lji.67.1557349028117; Wed, 08 May 2019 13:57:08 -0700 (PDT)
MIME-Version: 1.0
References: <CAO_FVe6eWy3zppQAij7qxD+ycYL8ebqGJKG0y-A7GhN+0=kb4g@mail.gmail.com> <CA+iA6uje229zrAos3c1TCuJEM+2vmVifNQ2FnKDuj2T4ET2SYA@mail.gmail.com> <a34edf0e-012a-ecc9-e547-3cdc61dca5a4@aol.com> <CA+iA6uh6Q901wEaqGSK7An0z0_iJTjCfvPVN44Qwpb=M_rDONg@mail.gmail.com> <239f40ab-da4d-03fe-4524-0b21a0bcc63e@aol.com> <SN6PR00MB0304BC3C7D438F8A5715B36DF5500@SN6PR00MB0304.namprd00.prod.outlook.com> <CA+iA6ugr+xPfeTFXK2gGBFX8Yw+zGArGfav=Ci5A3qNYUqB7rw@mail.gmail.com> <SN6PR00MB030459810B40D98370728BBAF5500@SN6PR00MB0304.namprd00.prod.outlook.com> <CA+iA6ug1NOpMcPsSr8o24CM3xWy-3z_pxiZhiyPeKxvScMACmg@mail.gmail.com> <CAO_FVe4AP5aWgXAAGj1QxPDFPjyfeaZGWd-b5azrz=ajuHuJdQ@mail.gmail.com> <466CE750-3ACD-432A-9DB7-51D02F17533B@forgerock.com> <CAO_FVe44BzKLo3oZ4dy=9d5kh-8YUFZqBzUOJP2hZh2=Ta=a6g@mail.gmail.com> <E11839C5-56B3-4C55-9ADC-7235A2FE24B7@forgerock.com> <d3ebf51f-6760-026a-d206-15ae5d44ae2b@connect2id.com> <9A6B2BA8-2651-4A27-A658-2BFB9D7996EC@forgerock.com> <77d825e3-1fe8-87a6-90e4-52018f9e8c59@connect2id.com>
In-Reply-To: <77d825e3-1fe8-87a6-90e4-52018f9e8c59@connect2id.com>
From: Vittorio Bertocci <Vittorio@auth0.com>
Date: Wed, 08 May 2019 13:56:56 -0700
Message-ID: <CAO_FVe5q-C8Mn90ATCWZytOd0Vt=Mye6ypiUZRAGJPQsA2uy3g@mail.gmail.com>
To: Dominick Baier <dbaier@leastprivilege.com>, Vladimir Dzhuvinov <vladimir@connect2id.com>
Cc: IETF oauth WG <oauth@ietf.org>, Neil Madden <neil.madden@forgerock.com>
Content-Type: multipart/alternative; boundary="0000000000009cd226058866932a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/5yn6qFX57OekwVO_5shAfXA-jCg>
Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 May 2019 20:57:32 -0000

One case I have seen back in the AAD days was when a RS wants to authorize
calls from specific clients. In there a client can act both as confidential
and as public client, and in the case of public client the client_id can be
reused by any app really - hence just looking at the client_id in the
incoming token doesn’t prove anything (even assuming that the RS knows
about the specific client_id, which might not always be the case). AAD had
a special claim saying whether the token was obtained from an authenticated
client, which would solve this particular scenario, but when I suggested
introducing such a claim in the initial proposal discussion that was
strongly discouraged hence I dropped it (tho I think I did add some
comments in the draft).
Having a sub_type (or whatever we’ll name it) would solve this for the most
obvious cases (client_crednetials, assertions representing clients).

Dominick mentioned that he uses the absence of sub in app token scenarios
to recognize the incoming tokens as such, hence he might have more
scenarios where the RS needs to be able to tell the difference.

On Wed, May 8, 2019 at 08:06 Vladimir Dzhuvinov <vladimir@connect2id.com>
wrote:

> On 08/05/2019 11:57, Neil Madden wrote:
> > Why does the RS need to know if the subject is a client vs a user? I
> suspect the answers to that question are about as problematic as the RS
> needing to know about the grant type.
>
> I have the exact same question.
>
> Could someone comment on that?
>
> I cannot think of a good reason, unless perhaps for logging / audit.
>
> > I’m not a fan of the client_credentials grant, better off using a real
> service account in most cases. Hopefully no new grants will be added that
> repeat that mistake.
>
> What do you mean by service account in this context?
>
> > Not sure I understand the point about JWT assertion grant type. If you
> use a JWT assertion for client authentication then that’s just the
> client_credentials grant again with a different token auth method, right?
>
> That was my point, that the JWT assertion grant as the client
> credentials grant can be used by a client acting on its own behalf.
>
> > — Neil
> >
> >> On 8 May 2019, at 08:51, Vladimir Dzhuvinov <vladimir@connect2id.com>
> wrote:
> >>
> >> grant_type would be horrible for RS developers to deal with, just to
> find out whether "sub" effectively == "client_id".
> >>
> >> Why?
> >> RS developers will need to learn more OAuth stuff - there are better
> ways to motivate people than that :)
> >> The OAuth grant types are unbounded. If at some point a new grant gets
> devised / implemented, RS developers will need to update the code that maps
> grant_types to ("sub" effectively == "client_id")
> >> We have at least one grant - JWT assertion - where checking the grant
> type is not sufficient to determine if "sub" effectively == "client_id"
> >> I believe we should aim for a spec where RS developers shouldn't be
> required to know more than how to process JWTs.
> >>
> >> The AS has all the necessary information to indicate whether "sub"
> effectively == "client_id". We don't need to push that logic to the RS.
> >> Vladimir
> >>
> >> On 07/05/2019 12:16, Neil Madden wrote:
> >>> Ah, that makes sense. Well, we already add a grant_type claim to our
> JWT-based access tokens, so I’m in favour of that solution :-)
> >>>
> >>>
> >>>> On 7 May 2019, at 09:48, Vittorio Bertocci <Vittorio@auth0.com>
> <mailto:Vittorio@auth0.com> wrote:
> >>>>
> >>>> Thanks Neil, one more reason to avoid that.
> >>>> TL;DR,
> >>>> The context is the discussion we had pre-IIW about whether sub should
> be included always or only for tokens issued to ROs. Some exiting
> implementations rely on that heuristic.
> >>>> Turns out that 7519 has language suggesting sub should be there for
> both tokens issued for the RO and for apps (via client creds, etc).
> >>>> We don't want to contradict 7519 but we also want to preserve the
> ability for a RS to tell whether an AT was issued via RO auth or app auth,
> hence the discussion. Suggestions ranged from adding a grant_type claim
> (Vlad made a convincing argument against it), to relying to the
> client_id==sub heuristic (which i pushed back on) to the introduction of a
> new claim (name TBD given that sub_type is taken already) that can
> explicitly declare whether the token has been issued authenticating th RO
> or via app credentials.
> >>>>
> >>>> On Tue, May 7, 2019 at 1:37 AM Neil Madden <neil.madden@forgerock.com
> <mailto:neil.madden@forgerock.com> <mailto:neil.madden@forgerock.com>
> <mailto:neil.madden@forgerock.com>> wrote:
> >>>> I wasn’t at IIW so I may be missing some context.
> >>>>
> >>>> There is a potential security issue if the client_id is used as the
> “sub” for an AT obtained via client_credentials. If the client can register
> itself with a self-chosen client_id then it may deliberately chose a
> client_id that matches the user name of a privileged user. An RS that just
> blindly looks at the “sub” claim may then erroneously let the client
> perform privileged actions.
> >>>>
> >>>> Is this the context of the discussion?
> >>>>
> >>>> Given that there are a lot of RSes in existence, many of which are
> probably just looking at the “sub” claim to identify the resource owner, I
> think the onus is on the AS to ensure that no such ambiguity can arise in
> the first place by ensuring that the space of “sub” values for client
> credentials is disjoint with the space for genuine users or by disallowing
> the client_credentials grant altogether.
> >>>>
> >>>> This issue already arises in token introspection though, so maybe
> ought to be mentioned in the OAuth security topics draft rather than
> specific to the JWT AT draft?
> >>>>
> >>>> — Neil
> >>>>
> >>>>> On 6 May 2019, at 18:32, Vittorio Bertocci <Vittorio=
> 40auth0.com@dmarc.ietf.org <mailto:Vittorio=40auth0.com@dmarc.ietf.org>
> <mailto:Vittorio=40auth0.com@dmarc.ietf.org> <mailto:Vittorio=
> 40auth0.com@dmarc.ietf.org>> wrote:
> >>>>>
> >>>>> Hi all,
> >>>>> thanks for your patience during this month long hiatus, and thanks
> for the comments.
> >>>>> Last week at IIW I had the opportunity to discuss this with many of
> the people on the list. Here's a summary of where the discussion landaed on
> the subject of the sub (pun intended).
> >>>>>
> >>>>> - It seems that RFC 7519 has pretty clear language on the use of
> sub- I didn't check it back when we started the discussion. I do agree with
> the people saying that we shouldn't violate existing specifications, hence
> it looks like we do need to have sub also in the case in which we have
> app-only tokens carrying claims about the app itself. I understand this
> will cause some implementation to break, but unfortunately that's intrinsic
> in the process of coming up with a common approach and standards compliance
> is probably one of the strongest reasons to tolerate that.
> >>>>> - That said, I am strongly committed to preserve existing
> functionality. One of the main reasons that was brought up for including
> sub only for user based ATs was to use it as heuristic for telling those
> tokens apart from app-only ones. 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?
> >>>>> Note, John Bradley observed that in some cases this might lead to
> ambiguous results if an extension grant is used (say an assertion profile)
> but that seems like a relatively fringe occurrence.
> >>>>>
> >>>>> On Thu, Apr 4, 2019 at 1:11 PM Hans Zandbelt <
> hans.zandbelt@zmartzone.eu <mailto:hans.zandbelt@zmartzone.eu> <mailto:
> hans.zandbelt@zmartzone.eu> <mailto:hans.zandbelt@zmartzone.eu>> wrote:
> >>>>> I also meant to say that (of course) the JWT standard doesn't say
> that the JWT is supposed to be about the client or about the resource
> owner, hence both are valid
> >>>>>
> >>>>> Hans.
> >>>>>
> >>>>> On Thu, Apr 4, 2019 at 10:09 PM Mike Jones <
> Michael.Jones@microsoft.com <mailto:Michael.Jones@microsoft.com> <mailto:
> Michael.Jones@microsoft.com> <mailto:Michael.Jones@microsoft.com>> wrote:
> >>>>> I get that existing practice is likely to be all over the map, but
> if we’re to create a JWT access token standard, it’s reasonable to require
> that the claims usage comply with the JWT standards.
> >>>>>
> >>>>>
> >>>>>
> >>>>>                                                                 --
> Mike
> >>>>>
> >>>>>
> >>>>>
> >>>>> From: Hans Zandbelt <hans.zandbelt@zmartzone.eu <mailto:
> hans.zandbelt@zmartzone.eu> <mailto:hans.zandbelt@zmartzone.eu> <mailto:
> hans.zandbelt@zmartzone.eu>>
> >>>>> Sent: Thursday, April 4, 2019 12:59 PM
> >>>>> To: Mike Jones <Michael.Jones@microsoft.com <mailto:
> Michael.Jones@microsoft.com> <mailto:Michael.Jones@microsoft.com> <mailto:
> Michael.Jones@microsoft.com>>
> >>>>> Cc: George Fletcher <gffletch=40aol.com@dmarc.ietf.org <mailto:
> gffletch=40aol.com@dmarc.ietf.org> <mailto:40aol.com@dmarc...ietf.org>
> <mailto:40aol.com@dmarc...ietf.org>>; Vittorio Bertocci <Vittorio=
> 40auth0.com@dmarc.ietf.org <mailto:Vittorio=40auth0.com@dmarc.ietf.org>
> <mailto:40auth0.com@dmarc.ietf.org> <mailto:40auth0.com@dmarc.ietf.org>>;
> IETF oauth WG <oauth@ietf.org <mailto:oauth@ietf.org> <mailto:
> oauth@ietf.org> <mailto:oauth@ietf.org>>
> >>>>> Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00
> >>>>>
> >>>>>
> >>>>>
> >>>>> the definition of RFC 7519 is actually "petitio principii" and a lot
> of deployments put claims about the Resource Owner in the access token (as
> a Resource Server implementer I've suffered a lot from this)
> >>>>>
> >>>>>
> >>>>>
> >>>>> Hans.
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Thu, Apr 4, 2019 at 9:48 PM Mike Jones <
> Michael.Jones@microsoft.com <mailto:Michael.Jones@microsoft.com> <mailto:
> Michael.Jones@microsoft.com> <mailto:Michael.Jones@microsoft.com>> wrote:
> >>>>>
> >>>>> I agree with George that the subject of a token must be the
> principal of that token.  That what the JWT “sub” claim is for.  Indeed,
> the first sentence of the “sub” definition at
> https://tools.ietf.org/html/rfc7519#section-4.1.2 <
> https://tools.ietf.org/html/rfc7519#section-4.1.2> <
> https://tools.ietf.org/html/rfc7519#section-4.1.2> <
> https://tools.ietf.org/html/rfc7519#section-4.1.2> is:
> >>>>>
> >>>>> The "sub" (subject) claim identifies the principal that is the
> subject of the JWT.
> >>>>>
> >>>>>
> >>>>>
> >>>>> If an access token uses “sub”, its usage must comply with the
> definition from RFC 7519.
> >>>>>
> >>>>>
> >>>>>
> >>>>>                                                                 --
> Mike
> >>>>>
> >>>>>
> >>>>>
> >>>>> From: OAuth <oauth-bounces@ietf.org <mailto:oauth-bounces@ietf.org>
> <mailto:oauth-bounces@ietf.org> <mailto:oauth-bounces@ietf.org>> On
> Behalf Of George Fletcher
> >>>>> Sent: Thursday, April 4, 2019 8:51 AM
> >>>>> To: Hans Zandbelt <hans.zandbelt@zmartzone.eu <mailto:
> hans.zandbelt@zmartzone.eu> <mailto:hans.zandbelt@zmartzone.eu> <mailto:
> hans.zandbelt@zmartzone.eu>>
> >>>>> Cc: Vittorio Bertocci <Vittorio=40auth0.com@dmarc.ietf.org <mailto:
> Vittorio=40auth0.com@dmarc.ietf.org> <mailto:40auth0.com@dmarc.ietf.org>
> <mailto:40auth0.com@dmarc.ietf.org>>; IETF oauth WG <oauth@ietf.org
> <mailto:oauth@ietf.org> <mailto:oauth@ietf.org> <mailto:oauth@ietf.org>>
> >>>>> Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00
> >>>>>
> >>>>>
> >>>>>
> >>>>> The more I think about this the more I land in the "No" camp.
> >>>>>
> >>>>> The subject of a token should be the principal of that token. It
> shouldn't matter whether that is a machine, a user, or a device. Trying to
> separate out "humans" as a special class will just make things more
> complicated. If we need a claim to identify the subject is a "human" then
> why not just add that. This doesn't break anything and makes it easy for
> people to detect this case in those use cases where it's required.
> >>>>>
> >>>>> Thanks,
> >>>>> George
> >>>>>
> >>>>> On 4/3/19 4:56 PM, Hans Zandbelt wrote:
> >>>>>
> >>>>> I will argue that in a way such deployments are already broken e.g.
> in the typical use case of onboarding client accounts in the same
> directory/OU/namespace as user accounts and we don't need to cater for that.
> >>>>>
> >>>>>
> >>>>>
> >>>>> Hans.
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Wed, Apr 3, 2019 at 10:48 PM George Fletcher <gffletch@aol.com
> <mailto:gffletch@aol.com> <mailto:gffletch@aol.com> <mailto:
> gffletch@aol.com>> wrote:
> >>>>>
> >>>>> I agree that this will break a lot of existing flows... especially
> those using any form of the client_credentials flow. In that sense I'm not
> completely on board yet :)
> >>>>>
> >>>>> On 3/26/19 12:56 PM, Hans Zandbelt wrote:
> >>>>>
> >>>>> great summary! this will hurt quite a few existing m2m deployments
> but I do like the rigidness of it all: it is very explicit, cannot
> misinterpreted and thus prevents failure (which is really what Dominick is
> after); I'm on board
> >>>>>
> >>>>>
> >>>>>
> >>>>> Hans.
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Tue, Mar 26, 2019 at 5:49 PM Vittorio Bertocci <Vittorio=
> 40auth0.com@dmarc.ietf.org <mailto:Vittorio=40auth0.com@dmarc.ietf.org>
> <mailto:40auth0.com@dmarc.ietf.org> <mailto:40auth0.com@dmarc.ietf.org>>
> wrote:
> >>>>>
> >>>>> thank you Steinar and everyone else for the comments on this!
> >>>>>
> >>>>> To summarize the situation so far: Dominick, Steinar, Rob, David,
> Nov, Bertrand recommend using sub only for users. Martin would like to have
> the sub for app only flows as well. Hans is neutral.
> >>>>>
> >>>>> That does sound like the sub as user has more consensus, tho before
> changing it I'd wait for the people currently at IETF104 to have more time
> to comment as well.
> >>>>>
> >>>>> Clarification. If the goal is to be able to apply the logic "if
> there's a sub, it's a user flow", we have to explicitly disallow (MUST NOT)
> the use of sub when that's not the case. Are all OK with it?
> >>>>>
> >>>>>
> >>>>>
> >>>>> Dave, the suggestion of having explicit typing for app only vs user
> only is interesting! For the purpose of putting together an interoperable
> profile, tho, I would suggest we table it for v1 in the interest of getting
> to something easy to adopt (hence with small delta vs existing
> implementations) faster.
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Tue, Mar 26, 2019 at 1:40 AM Steinar Noem <steinar@udelt.no
> <mailto:steinar@udelt.no> <mailto:steinar@udelt.no> <mailto:
> steinar@udelt.no>> wrote:
> >>>>>
> >>>>> Hi Vittorio, we  (the national federation-gateway for the health
> services in norway - "HelseID")  think his is a really valuable initiative!
> >>>>>
> >>>>> We also agree with Dominick concerning definition of the "sub" claim.
> >>>>>
> >>>>>
> >>>>>
> >>>>> <mvh>Steinar</mvh>
> >>>>>
> >>>>>
> >>>>>
> >>>>> tir. 26. mar. 2019 kl. 07:25 skrev Dominick Baier <
> dbaier@leastprivilege.com <mailto:dbaier@leastprivilege.com> <mailto:
> dbaier@leastprivilege.com> <mailto:dbaier@leastprivilege.com>>:
> >>>>>
> >>>>> >From an access token consumer (aka API) developer point of view, I
> prefer this logic
> >>>>>
> >>>>>
> >>>>>
> >>>>> "If sub is present - client acts on behalf of a user, if not - not."
> >>>>>
> >>>>>
> >>>>>
> >>>>> Anything more complicated has a potential of going wrong.
> >>>>>
> >>>>>
> >>>>>
> >>>>> On 26. March 2019 at 01:34:53, Nov Matake (matake@gmail.com <mailto:
> matake@gmail.com> <mailto:matake@gmail.com> <mailto:matake@gmail.com>)
> wrote:
> >>>>>
> >>>>> Hi Vittorio,
> >>>>>
> >>>>>
> >>>>>
> >>>>> Yeah, I’m concerning user & client ids collision.
> >>>>>
> >>>>> I haven’t seen such implementations, but user-select username as
> sub, or incremental integer as sub & client_id will be easily collide.
> >>>>>
> >>>>>
> >>>>>
> >>>>> If you can enforce collision resistant IDs between user & client
> instances, it’ll works fine. I feel its overkill though.
> >>>>>
> >>>>>
> >>>>>
> >>>>> Sent from my iPhone
> >>>>>
> >>>>>
> >>>>> On Mar 26, 2019, at 8:51, Vittorio Bertocci <Vittorio@auth0.com
> <mailto:Vittorio@auth0.com> <mailto:Vittorio@auth0.com> <mailto:
> Vittorio@auth0.com>> wrote:
> >>>>>
> >>>>> Hey Nov, Dominick, Hans-
> >>>>>
> >>>>> thanks for the comments. That was an area I was expecting to cause
> more discussion, and I am glad we are having this opportunity to clarify.
> >>>>>
> >>>>> The current language in the draft traces the etymology of sub to
> OpenID Connect core, hence Dominick observation is on point. However in the
> description I express something in line with 7519, which was in fact my
> intent.
> >>>>>
> >>>>>
> >>>>>
> >>>>> The idea was to provide an identifier of the calling subject that is
> guaranteed to be present in all cases- this would allow an SDK developer to
> use the same code for things like lookups and membership checks regardless
> of the nature of the caller (user in a delegated case, app in app-only
> grants). The information to discriminate between user and app callers is
> always available in the token (say, the caller is a user if sub!=client_id,
> where client_id is always guaranteed to be present as well) hence there's
> no loss in expressive power, should that difference be relevant for the
> resource server.
> >>>>>
> >>>>>
> >>>>>
> >>>>> Dominick, Hans- I probably missed the security issue you guys are
> thinking of in this case. Of course, if this would introduce a risk I
> completely agree it should be changed- I'd just like to understand better
> the problem. Could you expand it in a scenario/use case to clarify the risk?
> >>>>>
> >>>>> Nov- playing this back: is the concern that a user and a client
> might have the same identifier within an IDP? When using collision
> resistant IDs, as it is usually the case, that seems to be a remote
> possibility- did you stumble in such scenario in production?
> >>>>>
> >>>>>
> >>>>>
> >>>>> Thanks
> >>>>>
> >>>>> V.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Mon, Mar 25, 2019 at 7:44 AM Hans Zandbelt <
> hans.zandbelt@zmartzone.eu <mailto:hans.zandbelt@zmartzone.eu> <mailto:
> hans.zandbelt@zmartzone.eu> <mailto:hans.zandbelt@zmartzone.eu>> wrote:
> >>>>>
> >>>>> I believe there are plenty of OAuth 2.0 only use cases out there...
> but nevertheless I agree with the potential confusion and thus security
> problems arising from that (though one may argue the semantics are the
> same).
> >>>>>
> >>>>>
> >>>>>
> >>>>> Hans.
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Mon, Mar 25, 2019 at 3:39 PM Dominick Baier <
> dbaier@leastprivilege.com <mailto:dbaier@leastprivilege.com> <mailto:
> dbaier@leastprivilege.com> <mailto:dbaier@leastprivilege.com>> wrote:
> >>>>>
> >>>>> Yes I know - and I think in hindsight it was a mistake to use the
> same claim type for multiple semantics.
> >>>>>
> >>>>>
> >>>>>
> >>>>> All the “this is OIDC not OAuth” arguments are making things more
> complicated than they need to be - in my experience almost no-one (that I
> know) does OIDC only - nor OAuth only. They always combine it.
> >>>>>
> >>>>>
> >>>>>
> >>>>> In reality this leads to potential security problems - this spec has
> the potential to rectify the situation.
> >>>>>
> >>>>>
> >>>>>
> >>>>> Dominick
> >>>>>
> >>>>> On 25. March 2019 at 14:58:56, Hans Zandbelt (
> hans.zandbelt@zmartzone.eu <mailto:hans.zandbelt@zmartzone.eu> <mailto:
> hans.zandbelt@zmartzone.eu> <mailto:hans.zandbelt@zmartzone.eu>) wrote:
> >>>>>
> >>>>> Without agreeing or disagreeing: OIDC does not apply here since it
> is not OAuth and an access token is not an id_token.
> >>>>>
> >>>>> The JWT spec says in
> https://tools.ietf.org/html/rfc7519#section-4.1.2 <
> https://tools.ietf.org/html/rfc7519#section-4.1.2> <
> https://tools.ietf.org/html/rfc7519#section-4.1.2> <
> https://tools.ietf.org/html/rfc7519#section-4.1.2>:
> >>>>>
> >>>>>
> >>>>>
> >>>>> "The "sub" (subject) claim identifies the principal that is the
> >>>>>
> >>>>>    subject of the JWT.  The claims in a JWT are normally statements
> >>>>>
> >>>>>    about the subject.  The subject value MUST either be scoped to be
> >>>>>
> >>>>>    locally unique in the context of the issuer or be globally unique.
> >>>>>
> >>>>>    The processing of this claim is generally application specific"
> >>>>>
> >>>>>
> >>>>>
> >>>>> which kind of spells "client" in case of the client credentials
> grant but I also do worry about Resource Servers thinking/acting only in
> terms of users
> >>>>>
> >>>>>
> >>>>>
> >>>>> Hans.
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Mon, Mar 25, 2019 at 2:41 PM Dominick Baier <
> dbaier@leastprivilege.com <mailto:dbaier@leastprivilege.com> <mailto:
> dbaier@leastprivilege.com> <mailto:dbaier@leastprivilege.com>> wrote:
> >>>>>
> >>>>> IMHO the sub claim should always refer to the user - and nothing
> else.
> >>>>>
> >>>>>
> >>>>>
> >>>>> OIDC says:
> >>>>>
> >>>>>
> >>>>>
> >>>>> "Subject - Identifier for the End-User at the Issuer."
> >>>>>
> >>>>>
> >>>>>
> >>>>> client_id should be used to identify clients.
> >>>>>
> >>>>>
> >>>>>
> >>>>> cheers
> >>>>>
> >>>>> Dominick
> >>>>>
> >>>>>
> >>>>>
> >>>>> On 25.. March 2019 at 05:13:03, Nov Matake (matake@gmail.com
> <mailto:matake@gmail.com> <mailto:matake@gmail.com> <mailto:
> matake@gmail.com>) wrote:
> >>>>>
> >>>>> Hi Vittorio,
> >>>>>
> >>>>>
> >>>>>
> >>>>> Thanks for the good starting point of standardizing JWT-ized AT.
> >>>>>
> >>>>>
> >>>>>
> >>>>> One feedback.
> >>>>>
> >>>>> The “sub” claim can include 2 types of identifier, end-user and
> client, in this spec.
> >>>>>
> >>>>> It requires those 2 types of identifiers to be unique each other in
> the IdP context.
> >>>>>
> >>>>>
> >>>>>
> >>>>> I prefer omitting “sub” claim in 2-legged context, so that no such
> constraint needed.
> >>>>>
> >>>>>
> >>>>>
> >>>>> thanks
> >>>>>
> >>>>>
> >>>>>
> >>>>> nov
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Mar 25, 2019, at 8:29, Vittorio Bertocci <vittorio.bertocci=
> 40auth0.com@dmarc.ietf.org <mailto:vittorio.bertocci=
> 40auth0.com@dmarc.ietf.org> <mailto:vittorio.bertocci=
> 40auth0.com@dmarc.ietf.org> <mailto:vittorio.bertocci=
> 40auth0.com@dmarc.ietf.org>> wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>> Dear all,
> >>>>>
> >>>>> I just submitted a draft describing a JWT profile for OAuth 2.0
> access tokens. You can find it in
> https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/ <
> https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/> <
> https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/> <
> https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/>.
> >>>>>
> >>>>> I have a slot to discuss this tomorrow at IETF 104 (I'll be
> presenting remotely). I look forward for your comments!
> >>>>>
> >>>>>
> >>>>>
> >>>>> Here's just a bit of backstory, in case you are interested in how
> this doc came to be. The trajectory it followed is somewhat unusual.
> >>>>>
> >>>>> Despite OAuth2 not requiring any specific format for ATs, through
> the years I have come across multiple proprietary solution using JWT for
> their access token. The intent and scenarios addressed by those solutions
> are mostly the same across vendors, but the syntax and interpretations in
> the implementations are different enough to prevent developers from reusing
> code and skills when moving from product to product.
> >>>>> I asked several individuals from key products and services to share
> with me concrete examples of their JWT access tokens (THANK YOU Dominick
> Baier (IdentityServer), Brian Campbell (PingIdentity), Daniel Dobalian
> (Microsoft), Karl Guinness (Okta) for the tokens and explanations!).
> >>>>> I studied and compared all those instances, identifying
> commonalities and differences.
> >>>>> I put together a presentation summarizing my findings and suggesting
> a rough interoperable profile (slides:
> https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt_profile_for_ats.pptx
> <
> https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt_profile_for_ats.pptx>
> <https://sec..
> uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt_profile_for_ats.pptx>
> <https://sec..
> uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt_profile_for_ats.pptx>
> ) - got early feedback from Filip Skokan on it. Thx Filip!
> >>>>> The presentation was followed up by 1.5 hours of unconference
> discussion, which was incredibly valuable to get tight-loop feedback and
> incorporate new ideas. John Bradley, Brian Campbell Vladimir Dzhuvinov,
> Torsten Lodderstedt, Nat Sakimura, Hannes Tschofenig were all there and
> contributed generously to the discussion. Thank you!!!
> >>>>> Note: if you were at OSW2019, participated in the discussion and
> didn't get credited in the draft, my apologies: please send me a note and
> I'll make things right at the next update.
> >>>>> On my flight back I did my best to incorporate all the ideas and
> feedback in a draft, which will be discussed at IETF104 tomorrow. Rifaat,
> Hannes and above all Brian were all super helpful in negotiating the
> mysterious syntax of the RFC format and submission process.
> >>>>> I was blown away by the availability, involvement and willingness to
> invest time to get things right that everyone demonstrated in the process.
> This is an amazing community.
> >>>>>
> >>>>> V.
> >>>>>
> >>>>> _______________________________________________
> >>>>> OAuth mailing list
> >>>>> OAuth@ietf.org <mailto:OAuth@ietf.org> <mailto:OAuth@ietf.org>
> <mailto:OAuth@ietf.org>
> >>>>> https://www.ietf.org/mailman/listinfo/oauth <
> https://www.ietf.org/mailman/listinfo/oauth> <
> https://www.ietf.org/mailman/listinfo/oauth> <
> https://www.ietf.org/mailman/listinfo/oauth>
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> OAuth mailing list
> >>>>> OAuth@ietf.org <mailto:OAuth@ietf.org> <mailto:OAuth@ietf.org>
> <mailto:OAuth@ietf.org>
> >>>>> https://www.ietf.org/mailman/listinfo/oauth <
> https://www.ietf.org/mailman/listinfo/oauth> <
> https://www.ietf.org/mailman/listinfo/oauth> <
> https://www.ietf.org/mailman/listinfo/oauth>
> >>>>> _______________________________________________
> >>>>> OAuth mailing list
> >>>>> OAuth@ietf.org <mailto:OAuth@ietf.org> <mailto:OAuth@ietf.org>
> <mailto:OAuth@ietf.org>
> >>>>> https://www.ietf.org/mailman/listinfo/oauth <
> https://www.ietf.org/mailman/listinfo/oauth> <
> https://www.ietf.org/mailman/listinfo/oauth> <
> https://www.ietf.org/mailman/listinfo/oauth>
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>>
> >>>>> hans.zandbelt@zmartzone.eu <mailto:hans.zandbelt@zmartzone.eu>
> <mailto:hans.zandbelt@zmartzone.eu> <mailto:hans.zandbelt@zmartzone.eu>
> >>>>> ZmartZone IAM - www.zmartzone.eu <http://www.zmartzone.eu/> <
> http://www.zmartzone.eu/> <http://www.zmartzone.eu/>
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>>
> >>>>> hans.zandbelt@zmartzone.eu <mailto:hans.zandbelt@zmartzone.eu>
> <mailto:hans.zandbelt@zmartzone.eu> <mailto:hans.zandbelt@zmartzone.eu>
> >>>>> ZmartZone IAM - www.zmartzone.eu <http://www.zmartzone.eu/> <
> http://www.zmartzone.eu/> <http://www.zmartzone.eu/>
> >>>>> _______________________________________________
> >>>>> OAuth mailing list
> >>>>> OAuth@ietf.org <mailto:OAuth@ietf.org> <mailto:OAuth@ietf.org>
> <mailto:OAuth@ietf.org>
> >>>>> https://www.ietf.org/mailman/listinfo/oauth <
> https://www.ietf.org/mailman/listinfo/oauth> <
> https://www.ietf.org/mailman/listinfo/oauth> <
> https://www.ietf.org/mailman/listinfo/oauth>
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>>
> >>>>> Vennlig hilsen
> >>>>>
> >>>>>
> >>>>>
> >>>>> Steinar Noem
> >>>>>
> >>>>> Partner Udelt AS
> >>>>>
> >>>>> Systemutvikler
> >>>>>
> >>>>>
> >>>>>
> >>>>> | steinar@udelt.no <mailto:steinar@udelt.no> <mailto:steinar@udelt..no>
> <mailto:steinar@udelt..no> | hei@udelt.no <mailto:hei@udelt.no> <mailto:
> hei@udelt.no> <mailto:hei@udelt.no>  | +47 955 21 620 | www.udelt.no <
> http://www.udelt.no/> <http://www.udelt.no/> <http://www.udelt.no/> |
> >>>>>
> >>>>> _______________________________________________
> >>>>> OAuth mailing list
> >>>>> OAuth@ietf.org <mailto:OAuth@ietf.org> <mailto:OAuth@ietf.org>
> <mailto:OAuth@ietf.org>
> >>>>> https://www.ietf.org/mailman/listinfo/oauth <
> https://www.ietf.org/mailman/listinfo/oauth> <
> https://www.ietf.org/mailman/listinfo/oauth> <
> https://www.ietf.org/mailman/listinfo/oauth>
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>>
> >>>>> hans.zandbelt@zmartzone.eu <mailto:hans.zandbelt@zmartzone.eu>
> <mailto:hans.zandbelt@zmartzone.eu> <mailto:hans.zandbelt@zmartzone.eu>
> >>>>> ZmartZone IAM - www.zmartzone.eu <http://www.zmartzone.eu/> <
> http://www.zmartzone.eu/> <http://www.zmartzone.eu/>
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> OAuth mailing list
> >>>>> OAuth@ietf.org <mailto:OAuth@ietf.org> <mailto:OAuth@ietf.org>
> <mailto:OAuth@ietf.org>
> >>>>> https://www.ietf.org/mailman/listinfo/oauth <
> https://www.ietf.org/mailman/listinfo/oauth> <
> https://www.ietf.org/mailman/listinfo/oauth> <
> https://www.ietf.org/mailman/listinfo/oauth>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>>
> >>>>> hans.zandbelt@zmartzone.eu <mailto:hans.zandbelt@zmartzone.eu>
> <mailto:hans.zandbelt@zmartzone.eu> <mailto:hans.zandbelt@zmartzone.eu>
> >>>>> ZmartZone IAM - www.zmartzone.eu <http://www.zmartzone.eu/> <
> http://www.zmartzone.eu/> <http://www.zmartzone.eu/>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>>
> >>>>> hans.zandbelt@zmartzone.eu <mailto:hans.zandbelt@zmartzone.eu>
> <mailto:hans.zandbelt@zmartzone.eu> <mailto:hans.zandbelt@zmartzone.eu>
> >>>>> ZmartZone IAM - www.zmartzone.eu <http://www.zmartzone.eu/> <
> http://www.zmartzone.eu/> <http://www.zmartzone.eu/>
> >>>>>
> >>>>> --
> >>>>> hans.zandbelt@zmartzone.eu <mailto:hans.zandbelt@zmartzone.eu>
> <mailto:hans.zandbelt@zmartzone.eu> <mailto:hans.zandbelt@zmartzone.eu>
> >>>>> ZmartZone IAM - www.zmartzone.eu <http://www.zmartzone.eu/> <
> http://www.zmartzone.eu/> <http://www.zmartzone.eu/>
> >>>>> _______________________________________________
> >>>>> OAuth mailing list
> >>>>> OAuth@ietf.org <mailto:OAuth@ietf.org> <mailto:OAuth@ietf.org>
> <mailto:OAuth@ietf.org>
> >>>>> https://www.ietf.org/mailman/listinfo/oauth <
> https://www.ietf.org/mailman/listinfo/oauth> <
> https://www.ietf.org/mailman/listinfo/oauth> <
> https://www.ietf.org/mailman/listinfo/oauth>
> >>>
> >>>
> >>> _______________________________________________
> >>> OAuth mailing list
> >>> OAuth@ietf.org <mailto:OAuth@ietf.org>
> >>> https://www.ietf <https://www.ietf/>
> >> _______________________________________________
> >> 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
>