Re: [OAUTH-WG] Question regarding RFC 7592

Neil Madden <neil.madden@forgerock.com> Tue, 17 September 2019 06:11 UTC

Return-Path: <neil.madden@forgerock.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 E1722120145 for <oauth@ietfa.amsl.com>; Mon, 16 Sep 2019 23:11:12 -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, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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 (1024-bit key) header.d=forgerock.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 T-uux9gLgIJy for <oauth@ietfa.amsl.com>; Mon, 16 Sep 2019 23:11:09 -0700 (PDT)
Received: from mail-wr1-x441.google.com (mail-wr1-x441.google.com [IPv6:2a00:1450:4864:20::441]) (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 308FF1200E9 for <oauth@ietf.org>; Mon, 16 Sep 2019 23:11:09 -0700 (PDT)
Received: by mail-wr1-x441.google.com with SMTP id l11so1721247wrx.5 for <oauth@ietf.org>; Mon, 16 Sep 2019 23:11:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zizmLPcHFX9eV5scP+CViSNflmSHnnpUDTQI0y+/JXg=; b=EsBIemlT3AJJHICP4qK0KIioTvTzxj8yaQYh7i9mKgJBcahq/IImZ8FMRX7642zdcY Q992fptzd8O8qrv9PhJ7S/a0t1HrtTSOWnKYrkUHCLxFfr+Ia3i6Z56NTIdCNGyLEZEd 9Pef52xFk7kr72sbYoNiqOx9EEhoIkVmm2F18=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zizmLPcHFX9eV5scP+CViSNflmSHnnpUDTQI0y+/JXg=; b=JJc98SYDEHAVdFYA1ZNqW4ZVrzfJZJtPBCAr8Kv++9cl1X9EhJ4FD3JOaMWdQ9kn2G 5Gb8ZUIHRHHGHreUOgEY3q7orkEtyXtIm3CpTD4eNhRwvOsMc2GXhtrm3btS2Rnr5EXJ 9V4JD1R9BoTcXCtGMc0P+qaLILxWs2UsLJsNV/ZEmYFMIOe7UjCCS7fJjnfQpLSGBl5k EsNRP08qVLZvr076Yb3Rulnt/P0GbwKZp1QtQntxxIHw1J/W51G3cvpgjalRnTT+YLIA Gf6ev7PfZ0h+wLcgt0WJ5G2eIBQLUTQN3DDT9rTGi1JLbebNrYPPIAw2mTrc+PUSLcgB 0uSg==
X-Gm-Message-State: APjAAAWlB71B939EERCHXnhxunzOBoO3wodZoP4wWDoRXNRHBrdmFNU+ RU67+C231O5ipU4JgBCVbJ3xww==
X-Google-Smtp-Source: APXvYqyb3+bm803lh41m+/7HbhIFy0e4aL5xTpsoFELgxiUi/dwkRuNN5Bdrzcn2C1BAuCBfUmjtKg==
X-Received: by 2002:a5d:67c3:: with SMTP id n3mr1509631wrw.294.1568700667350; Mon, 16 Sep 2019 23:11:07 -0700 (PDT)
Received: from [192.168.1.65] (253.58.93.209.dyn.plus.net. [209.93.58.253]) by smtp.gmail.com with ESMTPSA id j22sm2636569wre.45.2019.09.16.23.11.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Sep 2019 23:11:06 -0700 (PDT)
Content-Type: multipart/alternative; boundary=Apple-Mail-6B9192D6-4059-4331-BA4A-E0F251CFB4D4
Mime-Version: 1.0 (1.0)
From: Neil Madden <neil.madden@forgerock.com>
X-Mailer: iPhone Mail (16G102)
In-Reply-To: <1BEA1464-9B31-4FBF-8619-16096F13BBDD@mit.edu>
Date: Tue, 17 Sep 2019 07:11:05 +0100
Cc: Dick Hardt <dick.hardt@gmail.com>, =?utf-8?Q?Robache_Herv=C3=A9?= <herve.robache@stet.eu>, "oauth@ietf.org" <oauth@ietf.org>
Content-Transfer-Encoding: 7bit
Message-Id: <EFD20D6C-DFD8-4BCD-A6C6-97A4F4E02907@forgerock.com>
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>
To: Justin Richer <jricher@mit.edu>
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/zCcVSMil6nt3erBIMEvGF1gzsvY>
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: Tue, 17 Sep 2019 06:11:13 -0000

The choice of using an access token here did provoke quite a lot of questions from developers. Does the token have a scope? Who is the resource owner - the client itself? Can the token be introspected? Revoked? Exchanged? Can it have PoP/sender-constrained restrictions?

That said, I think it makes sense to use an access token here, especially if there is a different party doing registration and management on behalf of the client. That party can retain the RAT without needing to impersonate the client. 

— Neil

> On 17 Sep 2019, at 03:36, Justin Richer <jricher@mit.edu> wrote:
> 
> I don’t see a reason to use an assertion here. JWT authentication would require at least a secret if not a key of some type for authentication for all clients, and it was determined that dynamic registration shouldn’t require the clients (even public clients) to support things they weren’t already capable of doing. Besides, the management endpoint isn’t a token endpoint (though I’m curious to hear why you’d say that) — it’s an API you can call to manage a client’s registration data over time. Sounds like an RS, if you ask me.
> 
> — Justin
> 
>> On Sep 15, 2019, at 1:05 AM, Dick Hardt <dick.hardt@gmail.com> wrote:
>> 
>> 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] 
>>>> 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 mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth