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

[Sergey Beryozkin <[e-mail]>]

Hi Tony,
On 13/08/13 17:38, Anthony Nadalin wrote:
> so the CRUD operations are not an overlap, the provisioning aspects are not an overlap, Interesting view
>
The texts are different, that was really my point, yes, both talk CRUD 
and I guess provisioning, but SCIM text appears to be much more generic 
to me

Cheers, Sergey

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Sergey Beryozkin
> Sent: Tuesday, August 13, 2013 12:45 AM
> To: [e-mail]
> Subject: Re: [OAUTH-WG] A Proposal for Dynamic Registration
>
> 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
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>