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