Re: [OAUTH-WG] Question regarding RFC 7592
Dick Hardt <dick.hardt@gmail.com> Sun, 15 September 2019 05:05 UTC
Return-Path: <dick.hardt@gmail.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 CFE581200EC for <oauth@ietfa.amsl.com>; Sat, 14 Sep 2019 22:05:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.996
X-Spam-Level:
X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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=gmail.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 OvYBLJQcDfd0 for <oauth@ietfa.amsl.com>; Sat, 14 Sep 2019 22:05:29 -0700 (PDT)
Received: from mail-lf1-x143.google.com (mail-lf1-x143.google.com [IPv6:2a00:1450:4864:20::143]) (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 4F9AB1200B8 for <oauth@ietf.org>; Sat, 14 Sep 2019 22:05:29 -0700 (PDT)
Received: by mail-lf1-x143.google.com with SMTP id y127so1696452lfc.0 for <oauth@ietf.org>; Sat, 14 Sep 2019 22:05:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=07GAVW7q+BJyddEdsfqylk0bxQXJzvTPXGFpu1DP7fw=; b=hE3FHPpMwvbE2HrnP1PwcAU7bzWsjeGuwH0eftj5ohjfQptNzc2Vojcupv9c9aFDrn vwkhcYlL8+g43h4gD6vA9XGevtvZYuCzvW3MW2UWqHZ9Kd+XueunOSwLqfY7Nr8EcOIU /xB6BgTllUFQFnPKIKzv/ItvK+sJDkwe0oZi9l2YmZM/iGzzKSyPi7Q6fEzbnSuSxC06 kbZPJv0GUV1wXOH2q4bjEaAYT48w2qfWEqD62nUScR4PZHYS1z9e8QS+kmF0P8qYpR72 aimYp80Q22hG/epfMVcE/Y9qUhAbslXfVZctgJ06G5fyZXDuanrilk1/9sjb/GzlMqMS CnaQ==
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=07GAVW7q+BJyddEdsfqylk0bxQXJzvTPXGFpu1DP7fw=; b=FQtbipNG+03FtFs9/ZL2511o09UFyMfgpaVEeNTi+6/xEgFGOvQiifRbduTEwMjvaC dAjrKl2ENrUh/SP9wgtHqKLAwmB0XksxkW/atRbm/hoOJ1dn3TemvnI1wEu1TM9wx+oh Xx9L16DJmxwh3bwp9zv0rvox+SO+tzfVw4s2TPxHjNn4J15dEDpao+4anPbFYsPPlmI3 2j2Tg1O36oHvlkB9s7HyUvunlIJwDOfvNIzD9JW1uteKDmLC4K8LXf7ypPJBSmCMk2Ll g3/GetrRd5XpCSmOvpcrHR/U3QWCt2b/Qoz/vfpV8pE2PSYH2qnaQv5mFNBZjR4AlQNS Mw+g==
X-Gm-Message-State: APjAAAULIwfq0e6mOIMN+afR99paQfq/qgYBgkimnEaYkjqf082lvSE1 sohPVoBINFC4zOC7uxhXWGP7uisizeMiOlJOKOM=
X-Google-Smtp-Source: APXvYqxvnTCja1kTa+tVWYM9QR412E5dNHkpZgiPg583pXQ6uT8CiM/BYS9yYzit3Q4QkD1WP508BNh5+fCKa5Cn7ZA=
X-Received: by 2002:a19:f247:: with SMTP id d7mr27578160lfk.191.1568523927304; Sat, 14 Sep 2019 22:05:27 -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>
In-Reply-To: <827BB5C3-2143-450A-BC3D-72F98CD0B475@mit.edu>
From: Dick Hardt <dick.hardt@gmail.com>
Date: Sat, 14 Sep 2019 22:05:16 -0700
Message-ID: <CAD9ie-s-_WgCFF9BrxF2bWjcJEi9rF+gD-P-DMPvbuzKfVXRyw@mail.gmail.com>
To: Justin Richer <jricher@mit.edu>
Cc: Robache Hervé <herve.robache@stet.eu>, "oauth@ietf.org" <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000008240580592906fa9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/Sz8sL3hweitjKSUIiB4N4yUn2tI>
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: Sun, 15 Sep 2019 05:05:33 -0000
Curious why the client management API uses bearer tokens rather than JWTs per RFC 7523 for the client to authenticate. The client management API seems more similar to a token endpoint than a resource. ᐧ On Fri, Sep 13, 2019 at 12:08 PM Justin Richer <jricher@mit.edu> wrote: > Travis has this correct — the “registration access token” is passed to the > client for the express purpose of accessing the client management API, and > is not the same as, or entangled with, any access tokens that the client > requests through the OAuth process after the registration has occurred. The > reasons for this separation are many, but at the core it comes down to the > client always acting on its own behalf when it does registration, and > acting on behalf of some other party (usually a user) when it’s doing > OAuth. Additionally, registration management is a function of the AS, > whereas the protected APIs are a function of the RS — note this is a > logical separation and there’s nothing stopping AS and RS functions from > being deployed in any number of patterns. > > A few common questions we got asked when writing this functionality into > the spec: > > *Why use an access token at all*? Because it’s a credential for a > specific API issued by the AS and handed to the client in a programmatic > manner. This is exactly what OAuth tokens were made for. > > *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. > > *Why not issue an authorization code*? Because then the client would need > to make yet another round trip, and not all clients are > authorization-code-grant clients to begin with. > > *Why not make a new grant type*? Because then the client would need to > make yet another round trip, and we’d have to invent a whole new grant type > with a new temporary credential when we could just use that temporary > credential directly instead. > > — Justin > > On Sep 13, 2019, at 8:23 AM, Robache Hervé <herve.robache@stet.eu> wrote: > > Thanks Travis > > I understand that, once the client has retrieved its [client_id] through > RFC7591 initial registration, it is then able to ask for an access token > that will be used for accessing the RFC7592 entry-points. Am I right? > > Best regards > > Hervé > > *De :* Travis Spencer [mailto:travis.spencer@curity.io > <travis.spencer@curity.io>] > *Envoyé :* ven. 13 13:30 > *À :* Robache Hervé > *Cc :* oauth@ietf.org > *Objet :* Re: [OAUTH-WG] Question regarding RFC 7592 > > No. The initial access token is issued by the AS when registration is > protected (appendix 1.2 in RFC 7591). As stated in section 1.2, the method > and means by which this is obtained can vary. The registration access token > in RFC 7592 is used to protect the registration management API and allow > updates to the client after it is registered. You might have one (the > registration access token) but not the other (initial access token) when > open registration is allowed (appendix 1.1 in RFC 7591). > > HTH! > > On Fri, Sep 13, 2019 at 7:37 AM Robache Hervé <herve.robache@stet.eu> > wrote: > > Hi > > RFC 7592 introduces a « Registration Access Token ». Are this token and > the way to get it similar to what is specified as “Initial Access Token” in > RFC 7591/Appendix A ? > > If so, can the Open Dynamic Client Registration (RFC7591/A.1.1) be > extrapolated to RFC7592 as the same way? > > Thanks in advance for your clarification. > > Hervé ROBACHE > Direction Marketing et Développement > > LIGNE DIRECTE > T. +33(0)1 55 23 55 45 > herve.robache@stet.eu > > <image001.png> > > > > <image002.png> > > STET (SIEGE SOCIAL) > 100, Esplanade du Général de Gaulle > Cœur Défense – Tour B > 92932 La Défense cedex > > www.stet.eu > > > > Ce message et toutes les pièces jointes sont établis à l'intention > exclusive de ses destinataires et sont confidentiels. > Si vous recevez ce message par erreur ou s'il ne vous est pas destiné, > merci de le détruire ainsi que toute copie de votre système et d'en avertir > immédiatement l'expéditeur. > Toute lecture non autorisée, toute utilisation de ce message qui n'est pas > conforme à sa destination, toute diffusion ou toute publication, totale ou > partielle, est interdite. > L'Internet ne permettant pas d'assurer l'intégrité de ce message > électronique susceptible d'altération, STET décline toute responsabilité au > titre de ce message dans l'hypothèse où il aurait été modifié, déformé ou > falsifié. > N'imprimez ce message que si nécessaire, pensez à l'environnement. > > This message and any attachments is intended solely for the intended > addressees and is confidential. > If you receive this message in error, or are not the intended > recipient(s), please delete it and any copies from your systems and > immediately notify the sender. > Any unauthorized view, use that does not comply with its purpose, > dissemination or disclosure, either whole or partial, is prohibited. > Since the internet cannot guarantee the integrity of this message which > may not be reliable, STET shall not be liable for the message if modified, > changed or falsified. > Do not print this message unless it is necessary, please consider the > environment. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > Ce message et toutes les pièces jointes sont établis à l'intention > exclusive de ses destinataires et sont confidentiels. > Si vous recevez ce message par erreur ou s'il ne vous est pas destiné, > merci de le détruire ainsi que toute copie de votre système et d'en avertir > immédiatement l'expéditeur. > Toute lecture non autorisée, toute utilisation de ce message qui n'est pas > conforme à sa destination, toute diffusion ou toute publication, totale ou > partielle, est interdite. > L'Internet ne permettant pas d'assurer l'intégrité de ce message > électronique susceptible d'altération, STET décline toute responsabilité au > titre de ce message dans l'hypothèse où il aurait été modifié, déformé ou > falsifié. > N'imprimez ce message que si nécessaire, pensez à l'environnement. > > This message and any attachments is intended solely for the intended > addressees and is confidential. > If you receive this message in error, or are not the intended > recipient(s), please delete it and any copies from your systems and > immediately notify the sender. > Any unauthorized view, use that does not comply with its purpose, > dissemination or disclosure, either whole or partial, is prohibited. > Since the internet cannot guarantee the integrity of this message which > may not be reliable, STET shall not be liable for the message if modified, > changed or falsified. > Do not print this message unless it is necessary, please consider the > environment. > _______________________________________________ > 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 >
- [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