Re: [OAUTH-WG] A Proposal for Dynamic Registration
Justin Richer <jricher@mitre.org> Mon, 12 August 2013 19:33 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 7A73F21F8BCE for <oauth@ietfa.amsl.com>; Mon, 12 Aug 2013 12:33:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.519
X-Spam-Level:
X-Spam-Status: No, score=-6.519 tagged_above=-999 required=5 tests=[AWL=0.080, 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 xGj18hShZQZk for <oauth@ietfa.amsl.com>; Mon, 12 Aug 2013 12:33:24 -0700 (PDT)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 6C9BF21F9F12 for <oauth@ietf.org>; Mon, 12 Aug 2013 12:33:24 -0700 (PDT)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id C7E8E1F03C9; Mon, 12 Aug 2013 15:33:22 -0400 (EDT)
Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id A8DCE1F085A; Mon, 12 Aug 2013 15:33:22 -0400 (EDT)
Received: from [10.146.15.13] (129.83.31.56) by IMCCAS01.MITRE.ORG (129.83.29.78) with Microsoft SMTP Server (TLS) id 14.2.342.3; Mon, 12 Aug 2013 15:33:22 -0400
Message-ID: <520937F2.5060700@mitre.org>
Date: Mon, 12 Aug 2013 15:30:58 -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: Phil Hunt <phil.hunt@oracle.com>
References: <52016822.2090703@mitre.org> <5208AC1A.5060606@mnt.se> <5208EC80.3060707@mitre.org> <0C7A9772-5D04-4CF6-8723-42AEF0877B43@oracle.com>
In-Reply-To: <0C7A9772-5D04-4CF6-8723-42AEF0877B43@oracle.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Originating-IP: [129.83.31.56]
Cc: "oauth@ietf.org WG" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] A Proposal for 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: Mon, 12 Aug 2013 19:33:29 -0000
I think you're misunderstanding what I'm saying with regard to the various protocols -- the different registration systems weren't incompatible for any deep seated assumptions or different data models. They were incompatible because of different names, different formats, different things being used to do the same thing. Small, stupid differences that none of the groups were particularly tied to at the time, but getting them all to agree to call something "foo" and not "bar" is where the draft that we have came in. Now you're suggesting that we go back to all these groups and say "well we know we told you to use 'foo' for this field, but now instead we're going to change it to 'bar', except that 'bar' isn't exactly 'bar', it's more like 'baz', and you need to throw out half your use cases". Ridiculous, is it not? All of your questions about what's required or not for supporting dynamic client registration have been brought up and discussed in the history of the document in its various forms over the past couple years. It started out as a one-way registration, no CRUD ops or lifecycle management. Then people started to use it and realized that we needed those things, so we've added them. Once we were in that direction, we realized we were doing CRUD-like operations but weren't being RESTful where it made sense to be, so now it's a JSON-based RESTful API. We used to force client secrets to be used (even by public clients using things like the implicit or assertion flows) to access this API, but then we realized we could eat our own dogfood and use OAuth tokens, and that's where we got the registration access token. We used to have registration be an open POST only, but then there were very real use cases, real deployments, and real extension mechanisms that could be enabled by having the initial registration optionally be protected as an OAuth2 protected resource as well, so that's where we got the initial access token. We originally had a fixed set of client parameters, but groups quickly wanted to add more, so we made that extensible. We originally had simple string values, but people wanted to be able to have localized text as well, so that was added. All of these are visible in the document history, particularly if you look at it across the IETF, UMA, and OpenID specs as a whole. You make it sound as if we simply waved our hands and grabbed a bunch of features out of thin air and implemented them, and that's absolutely not the case. Everything in that draft is the result of lots of discussion, implementation, and deployment. Do I need to mention again that people are actively running this code today? Also, I don't intend to disparage the SCIM protocol -- it's a great protocol for what it does, and in user and group provisioning it's exactly what I look toward. We're looking to potentially deploy it on some of my projects as well, so I'm certainly not against it. However, I'm not one to see it as a silver bullet for solving all RESTful API problems in the world, and that's exactly what I see it being positioned as here. Every function in the Dyn Reg spec that you claim "duplicates" SCIM are actually just things that it gets from being RESTful. So in other words, the similarities are from similar genetics, not from direct competition. Quite frankly, I think that what's happening here is that by taking the SCIM-hammer in hand you're seeing OAuth Dyn Reg as a nail. Also, I still think that you're ignoring the cost of implementing SCIM for people who aren't already doing so, especially when compared to the cost of implementing another (smaller, simpler, fit-to-purpose) RESTful API. As to the direct assertions, I'm interested in seeing where it goes, but I don't yet (today) see how it can work in practice. And in any case it needs a lot more work. Take the code flow, for example -- how does the client present the assertion to the authorization endpoint? And what does it use for client_id (a required parameter)? Also, to the question that I asked at the IETF meeting, what about the case where you've got hundreds of thousands of auth servers protecting the same kind of API -- where does a client go to get its assertion then? As to the "dynamic" nature of the clients, it's the *relationship* that's dynamic. You're once again conflating the code that executes with the instance of the code as seen by a particular authorization server. Also, in my own personal experience, there are things that change for a given piece of code depending on its deployment circumstances -- the redirect_uris for a web client, for instance, are going to be different depending on *where* that client software is served from. Judging by our past conversations, I think that your model of what makes up a client and what makes up an auth server is valid, but limited, and this is continuing to color your view of what this protocol needs. I'd rather have something that works across the many ways that OAuth is being used today and can be used in the future. -- Justin On 08/12/2013 02:43 PM, Phil Hunt wrote: > Inlineā¦ > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > > On 2013-08-12, at 4:09 PM, Justin Richer <jricher@mitre.org> wrote: > >> I think it's very important that we put *some* stake in the ground for the likes of OIDC, BB+, UMA, and the other higher-level protocols and systems that are looking toward us for Dyn Reg now. They weren't, previously -- all of these had mutually incompatible registration systems, but the work we've done so far with Dyn Reg has made a system that everyone can use. If we don't declare a baseline, and do so soon, then I fully believe that these groups will either fracture unnecessarily, or they'll ignore the IETF. Or both. > [PH] Your position here indicates to me that there is not a lot of natural consensus between OIDC, BB+, UMA and others. If these groups are aligning solely because of moral pressure to have a single standard -- which you seem to imply by the need to "put a stake in the ground", it suggests the technical proposal is not right yet. > > Despite your disparaging of SCIM, I don't think that's the issue. Whether SCIM or custom API, the Dyn Reg model places too much complexity solely on the client to registration endpoint relationship. > > For example, the information content of what the client is asserting is *not* dynamic - only the act of registration is. The client app is for the most part, "fixed", coded in a particular way for use with a specific set of APIs. Dyn Reg (and the SCIM variant) go well beyond just issuing a client_id and exchange all oauth protocol information on the assumption any value might change. This is a very complex approach. > > Then there is the issue of needing full CRUD support, I have not bought into the need for apps to be able to update registration. Why would they do this? We do we need de-registration, wouldn't Torsten's revocation draft suffice? > > The reason I think the assertion model might be a better path, is that it assumes a larger multi-party flow which moves complexity away from the registration endpoint to the point that in most cases a simple cert swap is all that is needed from the clients perspective. > > When Tony and I put forward the SCIM variant, we thought that might be a compromise. Still after putting it forward, I now feel the same way about it as I do the Dyn Reg draft. What is useful from it, is the notion of defining a software statement which can be used to simplify the registration process greatly. > >> I'll leave it to the chairs to decide if this gets tagged "experimental" or "standards", but I think that we're doing the world a disservice by not shipping what we have. >> >> -- Justin >> >> On 08/12/2013 05:34 AM, Leif Johansson wrote: >>> On 08/06/2013 11:18 PM, Justin Richer wrote: >>> >>> <snip> >>>> - OAuth Dynamic Registration >>>> - SCIM-based OAuth Dynamic Registration >>>> - Software Statements for OAuth Dynamic Registration >>>> >>> This thread makes me think we should break out the EXPERIMENTAL >>> track: spin two or more proposed solutions as EXPERIMENTAL. Let the >>> various groups do what they're gona do (which they'll do anyway) and >>> the the chips fall where they may. >>> >>> Tony is right in interpreting the discussions in Berlin as quite fractured. >>> Pushing for standards track seems premature. >>> >>> OTOH the transition from EXPERIMENTAL to STANDARDS TRACK can >>> be as quick as a couple of I-Ds describing the outcome of the >>> implementation and deployment work that will happen anyway (as >>> you so correctly observe) after which the WG decides how to move >>> forward. >>> >>> Since bb+ and openidc will do dynreg anyway the document track >>> doesn't really matter which means the usual "vendors won't implement >>> unless its a real RFC"-argument doesn't apply here anyway. >>> >>> Cheers Leif >>> >>> >>> >>> _______________________________________________ >>> 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
- [OAUTH-WG] A Proposal for Dynamic Registration Justin Richer
- Re: [OAUTH-WG] A Proposal for Dynamic Registration Anthony Nadalin
- Re: [OAUTH-WG] A Proposal for Dynamic Registration Justin Richer
- Re: [OAUTH-WG] A Proposal for Dynamic Registration George Fletcher
- Re: [OAUTH-WG] A Proposal for Dynamic Registration Anthony Nadalin
- Re: [OAUTH-WG] A Proposal for Dynamic Registration Justin Richer
- Re: [OAUTH-WG] A Proposal for Dynamic Registration Anthony Nadalin
- Re: [OAUTH-WG] A Proposal for Dynamic Registration Justin Richer
- Re: [OAUTH-WG] A Proposal for Dynamic Registration Josh Mandel
- Re: [OAUTH-WG] A Proposal for Dynamic Registration Anthony Nadalin
- Re: [OAUTH-WG] A Proposal for Dynamic Registration Phil Hunt
- Re: [OAUTH-WG] A Proposal for Dynamic Registration Richer, Justin P.
- Re: [OAUTH-WG] A Proposal for Dynamic Registration Leif Johansson
- Re: [OAUTH-WG] A Proposal for Dynamic Registration Prateek Mishra
- Re: [OAUTH-WG] A Proposal for Dynamic Registration Justin Richer
- Re: [OAUTH-WG] A Proposal for Dynamic Registration Phil Hunt
- Re: [OAUTH-WG] A Proposal for Dynamic Registration Justin Richer
- Re: [OAUTH-WG] A Proposal for Dynamic Registration Sergey Beryozkin
- Re: [OAUTH-WG] A Proposal for Dynamic Registration Anthony Nadalin
- Re: [OAUTH-WG] A Proposal for Dynamic Registration Justin Richer
- Re: [OAUTH-WG] A Proposal for Dynamic Registration Sergey Beryozkin