Re: [OAUTH-WG] Question regarding RFC 7592

Travis Spencer <travis.spencer@curity.io> Mon, 14 October 2019 11:01 UTC

Return-Path: <travis.spencer@curity.io>
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 F3357120043 for <oauth@ietfa.amsl.com>; Mon, 14 Oct 2019 04:01:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=curity-io.20150623.gappssmtp.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 MGTld1VDVcce for <oauth@ietfa.amsl.com>; Mon, 14 Oct 2019 04:01:56 -0700 (PDT)
Received: from mail-yb1-xb32.google.com (mail-yb1-xb32.google.com [IPv6:2607:f8b0:4864:20::b32]) (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 C534212001E for <oauth@ietf.org>; Mon, 14 Oct 2019 04:01:56 -0700 (PDT)
Received: by mail-yb1-xb32.google.com with SMTP id r68so5281375ybf.5 for <oauth@ietf.org>; Mon, 14 Oct 2019 04:01:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=curity-io.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Qwcy2xxBaTeQ8rqSocbhdcLE+qzt4ByluouLIj00Uus=; b=kItiJlfrABaYim2AAzAoeUMTx2KLPWKEONmNA90XyjePT5vkdeejBWK87A9keUAgin e0glUsTCk+lS4enDOHCGmqRNQvSa1SnYx+LaOJ5AJexydgdC78B7p0gUsfQxlU/JibAl fZAMrRuA2WC6fOdeoA7TmAwCFQs3BOObGfbzbMxVl7f7xDHFiMTOcqLDgwinfmksG4cZ lBcuIH98mmIDf+GDvyI1stfJlWZCI8xjG1pLIqYJSLquX6h1C6pvZ4W3A+Yx7EFHILe/ FvvkfDFlwfHDlJeAtJo8E8Psi5vXFHJcOGJBgYgee2ySFxAldsAHU10oYBK+VcZwZfmf sATQ==
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:content-transfer-encoding; bh=Qwcy2xxBaTeQ8rqSocbhdcLE+qzt4ByluouLIj00Uus=; b=Iuixi2f7LmMCT09pob0TLPv2w/AK80mJu56HH7ScEz+KNvSX8xtXhKw+SEr3F0ry9+ +FRywfOyfl/PEJ3Ukhtj5x4mljVZ6Q50fw3/mujm+4SOOnK7LsjdKhJCJePyHKbIHaPf HlePnNfADv0xD2IirhcMoNhsrqs6m66ThhBiz+jkGfCEsNGdNuW5S33wUczI288aXskV +zdRXaase/wmTISID/bJ5hC+vxB7plloQ8GkgHCgWGJrQheJQvtdahf3nHS5UrXg8ArF 5wYDTWazNtQzAo0hxIv0BGodvLvvuhaQaRnbdquOmP7+isg7+rCJpvgiV7OhnxbHtGoG DB/Q==
X-Gm-Message-State: APjAAAVypHoit5iLIgxOvKO4IhAynEQqnQq3bo0b2vyKlCWCXxIAfFMK ceqBummzACu89gkxIc63mcjJ9uvcY5/3D2pq0vGCNQ==
X-Google-Smtp-Source: APXvYqyQ9MQZAzBhPAfktJjg/Elv3HHbJnl/dI7WxD9j5SqA4+NsrCUcfzBP0oVtDg57AZkwtfMIGQxjcOvQTbaMpU8=
X-Received: by 2002:a25:1802:: with SMTP id 2mr17668405yby.369.1571050915887; Mon, 14 Oct 2019 04:01:55 -0700 (PDT)
MIME-Version: 1.0
References: <ae35a0f3b9f74618add918d9339be753@STEMES002.steteu.corp> <CAEKOcs3EtjLHRaRmpCa_GrpuXtqVMWHrmH0oPBB-b+2yzhKHaw@mail.gmail.com> <db205bcad6ac495bb558e2b6181ba546@STEMES002.steteu.corp> <827BB5C3-2143-450A-BC3D-72F98CD0B475@mit.edu> <CAD9ie-s-_WgCFF9BrxF2bWjcJEi9rF+gD-P-DMPvbuzKfVXRyw@mail.gmail.com> <1BEA1464-9B31-4FBF-8619-16096F13BBDD@mit.edu> <CAD9ie-uKQPk5GqapT-o80ZocaOk-fawZSzHeJwSeL=Zm2g2Bpg@mail.gmail.com> <ACE2CFA3-0D17-4EB1-BF31-01BEBBB7222C@mit.edu> <CAD9ie-t1W=+HUwpXebMP+zjDSTqd8EeX_tyN15zqQtrdt3e+cg@mail.gmail.com>
In-Reply-To: <CAD9ie-t1W=+HUwpXebMP+zjDSTqd8EeX_tyN15zqQtrdt3e+cg@mail.gmail.com>
From: Travis Spencer <travis.spencer@curity.io>
Date: Mon, 14 Oct 2019 13:01:44 +0200
Message-ID: <CAEKOcs08vX2g-GUCutGzadH6qA3aLGW20EV6x5E_AOwvVge29Q@mail.gmail.com>
To: Dick Hardt <dick.hardt@gmail.com>
Cc: Justin Richer <jricher@mit.edu>, =?UTF-8?Q?Robache_Herv=C3=A9?= <herve.robache@stet.eu>, "oauth@ietf.org" <oauth@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/buzFOtqAuU6RqByj_IyeDHwqBIw>
Subject: Re: [OAUTH-WG] Question regarding RFC 7592
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, 14 Oct 2019 11:01:59 -0000

On Wed, Sep 18, 2019 at 4:24 PM Dick Hardt <dick.hardt@gmail.com> wrote:
>
> What happens if the access token is lost or compromised? Does the app need to be completely re-registered?

Yes. Re-registration breaks many things though, so it's often not an
option. In these cases, the client is pretty much stuck with only bad
choices :-/

The token lifecycle of DCR(M) is one of the areas that would be great
to improve IMO. We originally had planned to always issue a dynamic
client a secret that it could use to get a DCRM scoped token using the
CC flow. We opted not to do that in the end because the client could
be using certs, for example, and a secret for management would lower
the security of the client. Using the credential (like a signed JWT
using an asymmetric key as you mention, Dick) could be a good way to
handle this. Perhaps RFC 7592 (DCRM) should be updated with some info
about allowing the client to use the CC flow with whatever credential
it registers with, just for the purpose of obtaining a new DCRM-scoped
registration management token.

Justin mentioned this though:

>  Why not use the client’s credentials? Because not all clients are set up to have credentials, plus we’d be spreading the requirement to support different kinds of client credentials to another endpoint.

IMO, the dynamic client should go to the token endpoint with whatever
credential it registered with using the CC flow and a scope of "dcrm".
So, the last concern about spreading the need to authenticate to other
endpoints would be moot. I'm not sure what to say about public
clients. ATM, in our product at least, we don't support public clients
registering, so this wouldn't pose an issue for us. Could for others I
suppose. Short of CC though, I can't think of a good way to get a new
registration management token.