Re: [OAUTH-WG] Refactoring Dynamic Registration
Justin Richer <jricher@mitre.org> Tue, 27 August 2013 18:42 UTC
Return-Path: <jricher@mitre.org>
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 E546D11E81D7 for <oauth@ietfa.amsl.com>; Tue, 27 Aug 2013 11:42:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.524
X-Spam-Level:
X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3PlySEexOQxq for <oauth@ietfa.amsl.com>; Tue, 27 Aug 2013 11:42:46 -0700 (PDT)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 9C16821E8084 for <oauth@ietf.org>; Tue, 27 Aug 2013 11:42:46 -0700 (PDT)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id EA8F21F08CF; Tue, 27 Aug 2013 14:42:45 -0400 (EDT)
Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id B47FA1F04F0; Tue, 27 Aug 2013 14:42:45 -0400 (EDT)
Received: from [10.146.15.13] (129.83.31.56) by IMCCAS02.MITRE.ORG (129.83.29.79) with Microsoft SMTP Server (TLS) id 14.2.342.3; Tue, 27 Aug 2013 14:42:45 -0400
Message-ID: <521CF31D.7080108@mitre.org>
Date: Tue, 27 Aug 2013 14:42:37 -0400
From: Justin Richer <jricher@mitre.org>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130623 Thunderbird/17.0.7
MIME-Version: 1.0
To: Anthony Nadalin <tonynad@microsoft.com>
References: <D4C71EFB-AE88-4E42-AED2-D9202247A3DB@mitre.org> <57d0cc93671e43c09d04fb7f46528b90@BY2PR03MB189.namprd03.prod.outlook.com>
In-Reply-To: <57d0cc93671e43c09d04fb7f46528b90@BY2PR03MB189.namprd03.prod.outlook.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [129.83.31.56]
Cc: oauth mailing list <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Refactoring Dynamic Registration
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
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, 27 Aug 2013 18:42:52 -0000
-1, I believe that the management spec is vital for interoperability and well within the scope of this working group, and that the management spec needs to move forward in tandem with the core spec. -- Justin On 08/27/2013 02:41 PM, Anthony Nadalin wrote: > I believe the http://tools.ietf.org/html/draft-richer-oauth-dyn-reg-management-00 is out of scope for this WG and needs to go to the APPS area since we don't deal with other OAuth management issues > > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Richer, Justin P. > Sent: Tuesday, August 27, 2013 7:06 AM > To: oauth mailing list > Subject: [OAUTH-WG] Refactoring Dynamic Registration > > After last week's design team call, at Derek's suggestion, I took time today to refactor the Dynamic Registration draft into two pieces: "core" and "management". The former contains the definition of the Registration Endpoint and the semantics surrounding that, the latter contains the Client Configuration Endpoint as well as the "non-essential" client metadata parameters. > > I did this refactoring with an axe, so there are almost certainly bits and pieces that are in the wrong document. In particular, I've kept the use cases in the "core" document even though they reference concepts and constructs defined in the "management" spec. This way people that don't want to deal with a configuration management API can implement just the "core" registration spec and call it a day, while people who want to have full lifecycle control can do the "management" spec on top of it. This does increase the optionality by making the client configuration endpoint parameters optional, but that's the tradeoff for having things cut this way. > > You can read both the specs here: > > http://tools.ietf.org/html/draft-richer-oauth-dyn-reg-core-00 > > http://tools.ietf.org/html/draft-richer-oauth-dyn-reg-management-00 > > I've uploaded these as individual submissions for now. If the working group decides to move forward with this refactoring, I expect both documents to move in tandem through the RFC approval process. > > -- Justin > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
- [OAUTH-WG] Refactoring Dynamic Registration Richer, Justin P.
- Re: [OAUTH-WG] Refactoring Dynamic Registration Anthony Nadalin
- Re: [OAUTH-WG] Refactoring Dynamic Registration Justin Richer
- Re: [OAUTH-WG] Refactoring Dynamic Registration Anthony Nadalin
- Re: [OAUTH-WG] Refactoring Dynamic Registration Justin Richer
- Re: [OAUTH-WG] Refactoring Dynamic Registration Anthony Nadalin
- Re: [OAUTH-WG] Refactoring Dynamic Registration Anthony Nadalin
- Re: [OAUTH-WG] Refactoring Dynamic Registration Justin Richer
- Re: [OAUTH-WG] Refactoring Dynamic Registration Justin Richer
- Re: [OAUTH-WG] Refactoring Dynamic Registration John Bradley
- Re: [OAUTH-WG] Refactoring Dynamic Registration Eve Maler
- Re: [OAUTH-WG] Refactoring Dynamic Registration Anthony Nadalin
- Re: [OAUTH-WG] Refactoring Dynamic Registration Justin Richer