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

[Phil Hunt <[e-mail]>]

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