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>, Robache Hervé <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.
- [OAUTH-WG] Question regarding RFC 7592 Robache Hervé
- Re: [OAUTH-WG] Question regarding RFC 7592 Travis Spencer
- Re: [OAUTH-WG] Question regarding RFC 7592 Robache Hervé
- Re: [OAUTH-WG] Question regarding RFC 7592 Travis Spencer
- Re: [OAUTH-WG] Question regarding RFC 7592 Justin Richer
- Re: [OAUTH-WG] Question regarding RFC 7592 Dick Hardt
- Re: [OAUTH-WG] Question regarding RFC 7592 Justin Richer
- Re: [OAUTH-WG] Question regarding RFC 7592 Dick Hardt
- Re: [OAUTH-WG] Question regarding RFC 7592 Neil Madden
- Re: [OAUTH-WG] Question regarding RFC 7592 Justin Richer
- Re: [OAUTH-WG] Question regarding RFC 7592 Travis Spencer
- Re: [OAUTH-WG] Question regarding RFC 7592 Dick Hardt
- Re: [OAUTH-WG] Question regarding RFC 7592 Robache Hervé
- Re: [OAUTH-WG] Question regarding RFC 7592 Travis Spencer