Re: [OAUTH-WG] A Proposal for Dynamic Registration

[Sergey Beryozkin <[e-mail]>]

For whatever it is worth, let me add my 2c, I've briefly looked through 
the latest Dynamic Registration Draft, and also briefly looked at SCIM - 
interesting specification, did not know it even exists :-).

IMHO these are 2 rather different texts, SCIM looks very useful, look 
forward to understanding it better :-), but it appears to be at a higher 
level than Dyn Reg Draft is - the latter is centric around a specific 
use case as far as I can see and the whole language of the latter is 
about addressing this specific use case. Appears to me SCIM and DynReq 
of OAuth2 Clients texts complement each other as opposed to 'compete' 
with each other, and they intersect simply because they use some similar 
terminology. I may be repeating some of what is said below.

Re the use of assertions: I'd like to think that getting the assertions 
flowing in OAuth2 applications is useful only when we have a task of 
integrating with existing IDPs or some other involved scenarios. Using 
them as the central pieces of the protocol will raise the complexity bar.

Apologies for not commenting inline - the above is just the comments 
after a brief overview of the documents :-)

Cheers, Sergey

On 12/08/13 22:30, Justin Richer wrote:
> 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
>> [e-mail]
>>
>>
>>
>>
>>
>> On 2013-08-12, at 4:09 PM, Justin Richer <[e-mail]> 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
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>> _______________________________________________
>>> OAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth