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

Vittorio Bertocci <Vittorio@auth0.com> Mon, 06 May 2019 19:42 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 9D097120139 for <oauth@ietfa.amsl.com>; Mon, 6 May 2019 12:42:31 -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 yKoML6YXoLwJ for <oauth@ietfa.amsl.com>; Mon, 6 May 2019 12:42:29 -0700 (PDT)
Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (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 952D91200F9 for <oauth@ietf.org>; Mon, 6 May 2019 12:42:28 -0700 (PDT)
Received: by mail-lj1-x229.google.com with SMTP id f23so12184826ljc.0 for <oauth@ietf.org>; Mon, 06 May 2019 12:42:28 -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=oBAHtMRaqZcC1uxevOEdDDu57f6QNpcmqBVzkXBQFFA=; b=AIZ9cBU0KxkVDl7KGq6rXtr84S0kQGtn5mubm8QYCejRlnnibDZBYKAkwfR6N/0AO1 f8EepUmAATzZrvIxgB4pBoQcawnOjcx19IcM7iuVhJ06hFA547jKrxCTYHG0AekQ47NB cqyggX4sSnBQbY2uDJyoot7KLADquSDFj6KPlSYT66Y0ppdfqT30bqH8E9GskhifScyN eJrOhQgWpqct5lgsXjcq/r1YwGpxo5pDrBveW2EPMJH70lu3UTgooaFNKAu/V7I4CKpF C6b2znODpHikb9YydOdG2b3VJjpH20D9EItmR76B1mXTdRsXZqzsbOkAsGw+XgbweNKp bHJQ==
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=oBAHtMRaqZcC1uxevOEdDDu57f6QNpcmqBVzkXBQFFA=; b=eEZQGJnXzg8Q9NJAIm9gBW/f2u+fwmw3AupG0EVyawYlhwJprj21A+muKzfXgfuuCX cEyOAg9KVPeFTLm4u16Xf+3Og9dmNW052F3qxh2GZf++1n6bwJbSEsuosDIpLI7Mc7bF uhlhwyZiwwfz/Iz8zwaqDdDTHcwjlfLKaJDsaIHFe+xCZlPFUMlB5/mSOFA+MZYcJ53I QgViHrSK5PJyxeefo8ik1l0d5iPH0126byqJcKRUHxZyoh995DgLKUOGTEWWJBdzXr1a RtaOnkcvoi3dOK+gpskiirY2hiYUVhxRX5kNc/cQwYTBHROYLmjF6YXdTn5/NJGU+VQS ZLeQ==
X-Gm-Message-State: APjAAAUMZ+aabxUw281Y0+14hDEDAJ2nflr65XKv6t/Pj+DEM42ZA546 0vYaatT/raDWAwhL1vR4TtcAZ9lmuoUnTyd1PAXWcg==
X-Google-Smtp-Source: APXvYqwzDQw+R/KCxH7v7oJ0YSxvDvuRD+g/NjxHQ1QSYdsIcx2TWD54n8hQm6NvUa8n8VkUya8Qr3lFmHsALg9JcVo=
X-Received: by 2002:a2e:a0c9:: with SMTP id f9mr14514089ljm.62.1557171746557; Mon, 06 May 2019 12:42:26 -0700 (PDT)
MIME-Version: 1.0
References: <CAO_FVe6eWy3zppQAij7qxD+ycYL8ebqGJKG0y-A7GhN+0=kb4g@mail.gmail.com> <CAHsNOKewL9xCFt6SsP4dz+W0CN_NUZaGMJahF7mSgos_Xbnhhw@mail.gmail.com> <CAO_FVe7c6jLRJ8mD7gw=a6NY3oZcgCh_b5dR8uRXa6Q2c2gmGg@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> <3ec04cf7-e0ed-2b9a-20f7-a94dea4d559b@connect2id.com> <CAO_FVe6sLxbkk0tEjH5sb8k36q4_sJLU6HAgU05fAqOGaqo8MA@mail.gmail.com> <61adde0e-8709-5b88-8b64-ac8cc4549f51@connect2id.com>
In-Reply-To: <61adde0e-8709-5b88-8b64-ac8cc4549f51@connect2id.com>
From: Vittorio Bertocci <Vittorio@auth0.com>
Date: Mon, 06 May 2019 12:42:18 -0700
Message-ID: <CAO_FVe4HQKPvL5bdbAerHRU0TCiZKLJS9JgDrYkXNokri9oBaA@mail.gmail.com>
To: Vladimir Dzhuvinov <vladimir@connect2id.com>
Cc: IETF oauth WG <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000cee4b505883d4c81"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/SdGbd_37rhrY_TYjJ7LUFl5gR3c>
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: Mon, 06 May 2019 19:42:32 -0000

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 <vladimir@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 <
> vladimir@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
>
>
>