Re: [OAUTH-WG] Dynamic Client Registration

"Richer, Justin P." <jricher@mitre.org> Tue, 13 January 2015 23:31 UTC

Return-Path: <jricher@mitre.org>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DC481B2BEF for <oauth@ietfa.amsl.com>; Tue, 13 Jan 2015 15:31:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 MJrYUEG1qbj9 for <oauth@ietfa.amsl.com>; Tue, 13 Jan 2015 15:31:20 -0800 (PST)
Received: from smtpvbsrv1.mitre.org (smtpvbsrv1.mitre.org [198.49.146.234]) by ietfa.amsl.com (Postfix) with ESMTP id B52AE1B2BCD for <oauth@ietf.org>; Tue, 13 Jan 2015 15:30:36 -0800 (PST)
Received: from smtpvbsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 6083072E04F; Tue, 13 Jan 2015 18:30:36 -0500 (EST)
Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpvbsrv1.mitre.org (Postfix) with ESMTP id 5749272E038; Tue, 13 Jan 2015 18:30:36 -0500 (EST)
Received: from IMCMBX01.MITRE.ORG ([169.254.1.185]) by IMCCAS04.MITRE.ORG ([129.83.29.81]) with mapi id 14.03.0224.002; Tue, 13 Jan 2015 18:30:35 -0500
From: "Richer, Justin P." <jricher@mitre.org>
To: Phil Hunt <phil.hunt@oracle.com>
Thread-Topic: [OAUTH-WG] Dynamic Client Registration
Thread-Index: AQHQLlidU4rOELMb8EiQ/dpBvkV0+Zy/AvOAgAAEM4CAAAHVAA==
Date: Tue, 13 Jan 2015 23:30:34 +0000
Message-ID: <A1276C65-DC09-4012-8CA5-31904DD25EAE@mitre.org>
References: <54B3ABF8.8050007@gmx.net> <9013AEED-9B4E-4F22-8E91-AE1430372530@mitre.org> <C4B77F5C-25F9-4CE2-A784-CD526714BE2F@oracle.com>
In-Reply-To: <C4B77F5C-25F9-4CE2-A784-CD526714BE2F@oracle.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.146.15.76]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <42346A2E8F609449B9A3A2AB3C3A914E@imc.mitre.org>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/F5g9TpM5u3H2fL2vV3BPaG9jtZo>
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Dynamic Client Registration
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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, 13 Jan 2015 23:31:22 -0000

>> 
>>> It also does not make sense to
>>> show the developer in the box together with the client since the
>>> developer does not execute a protocol exchange with the client
>>> registration endpoint.
>> 
>> That's not true, a developer (person or organization) could very easily be using the dynamic registration protocol on behalf of the software that they're developing. This is actually used in practice in a number of places, and if you'd like a concrete example just go to the MIT integration test site: https://mitreid.org/manage/dev/dynreg (log in with user/password).
> 
> IMO. This defeats the purpose of dynamic registration. A developer that wants to hand register would go through the SP’s developer support pages as they do now.
> 
> It also won’t work in cases where an individual client will negotiate a client key (where the actual key is not shared and thus the developer (or any other MITM) can’t get in between.

If it were only authenticated portal pages, then I'd agree with you, but it's not. The page I pointed to above is just a wrapper shell around the dynamic registration endpoint -- it doesn't even *need* the user's credentials to function, but that's how our server is set up to present the page, which might be confusing people. On our server, only server admins can access the "real" client registration page, which isn't as limited as the dynamic registration page. There are other use cases that have things like build frameworks that do the registration on behalf of a client instance or version, where it's the developer (in this case an organization/system) and not the client software doing the registration. 

Basically, there was a strong argument for leaving that particular door open, all of which is documented in the Use Cases appendix and liberally on the list.

 -- Justin