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: =?UTF-8?Q?Robache_Herv=C3=A9?= <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
>