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

[Prateek Mishra <[e-mail]>]

+1

I dont see a consensus within the community in this area.

My own sense is that people are exploring many different approaches to 
the problem; there seem to be wide-variety of use-cases involved.

- prateek

> +1
>
> I also would like to explore the assertion exchange concept that doesn't require any endpoint.
>
> I see no point in rushing here.
>
> More than one method makes no sense unless there is a fundamental reason. We have none.
>
> Dyn reg duplicates scim and we have to reconcile this now or with the iesg.
>
> Phil
>
> On 2013-08-07, at 14:59, Anthony Nadalin <[e-mail]> wrote:
>
>> This proposal provisions and de-provisions clients and allows a client to read/update provisioning data (and it also has to deal with schema extensibility, internationalization among the other things), very similar to SCIM, why do we want different ways to do this ? We also have the JIT proposals in SCIM which make even more sense for quick provisioning clients with limited data. This is a lot of repeat of SCIM.
>>
>> Schema extensibility is not just the ability to add or replace but the flexibility to model desired objects and relationships that are in the target store schema. We would certainly not want to create yet another store/directory just to register clients.
>>
>> -----Original Message-----
>> From: Justin Richer [mailto:[e-mail]]
>> Sent: Wednesday, August 7, 2013 8:19 AM
>> To: Anthony Nadalin
>> Cc: [e-mail]
>> Subject: Re: [OAUTH-WG] A Proposal for Dynamic Registration
>>
>> Addressing your points inline:
>>
>> On 08/07/2013 10:58 AM, Anthony Nadalin wrote:
>>> I see plenty of fractures, we discussed many of these at the meeting and several side meetings last week. Specification that are brought to IETF undergo changes, morf into something different all the time regardless of who has implemented the original specifications, OAUTH Core is a fine example of how lots of running code was changed because the specification changed, so because you may have code based upon this is not a reason that it is correct and should not change.
>> And all that has happened with this draft as well. Things have changed quite a bit from the original specs, breaking changes that caused huge ripples through existing implementations. Eventually though you need to say "it's good enough" -- if you keep changing things and don't declare something done, people will just get bored and move on. I'm glad that you mention OAuth core because it is a great example of our previous failure at this -- we took so long to get it out there that there are several major non-compliant implementations on the web today, most notably Facebook, who have no incentive to change to the final draft just because the IETF says so. Let's not screw this up again.
>>
>>>   I'm not aware of many people using this draft, as in the meeting last week I think we had 2 examples, so more people saying that they have implemented this at scale and the problems it solves would be a good thing.
>> I agree that more people implementing it would be a good thing, but you're ignoring the people that already are. There are also a number of people that I've spoken to who are hesitant to implement until things are deemed fairly "stable", if not final. Those people will come up with their own, mutually-incompatible versions.
>>
>>> Here are the problems that I see with the current proposal and why we would/could not use it:
>>>
>>> 1. The schema proposal is not extensible, please look at the issues with SCIM and how the scheme was made extensible in SCIM.
>> Yes, it is extensible, I really don't know where you're getting that.
>> It's JSON, schema-by-fiat. If you want an extension parameter, just add it. Your server has to deal with (as in, not crash if it sees) anything in the base spec, and it it has to ignore anything that it doesn't understand. Best thing I could think to add here would be an IANA registry for the client metadata names -- I personally find such things overkill but if the WG wants to go that route, we certainly can.
>>> 2. This proposal requires that I now provide management at the registration endpoint to manage users and secrets, this is costly.
>> What users are you talking about here? There aren't any users here that I know of. As for secrets, you already have to manage client secrets.
>>
>>> 3. Yet the development of another endpoint.
>> Adding an endpoint for specific functionality is a good thing, it lets you separate out concerns. You talk like URLs are expensive, which is ludicrous. Would you propose we try to cram everything through a single URL like SOAP? Let's learn from the mistakes of the past instead of repeating them.
>>
>>> 4. I don't see any use cases, maybe these should be documented (or point people to these) so we understand what this is actually trying to solve, as this is somewhat of a mystery to me and others.
>> Read appendix B. That's why it's there. If there are more cases that we can add, suggest text.
>>> 5. There are a lot of issues that OAUTH does not solve, I don't think
>>> that this issue (as I understand it) is in the realm of OAUTH, maybe
>>> the applications area would be a better place for this specification
>> This was a chartered item for the group to solve (check the charter for yourself), we discussed it several times over the last few years before it was made a chartered item (check the archives for yourself), and there are people willing to work on the document. That's all it takes for this to be in scope in the IETF. Trying to boot it into another working group at this stage is just odd to me.r
>>
>>   -- Justin
>>>
>>>
>>> -----Original Message-----
>>> From: Justin Richer [mailto:[e-mail]]
>>> Sent: Wednesday, August 7, 2013 7:09 AM
>>> To: Anthony Nadalin
>>> Cc: [e-mail]
>>> Subject: Re: [OAUTH-WG] A Proposal for Dynamic Registration
>>>
>>> Tony, it happened several months ago:
>>>
>>>     http://www.ietf.org/mail-archive/web/oauth/current/msg11326.html
>>>
>>> This triggered a lot of discussion and brought up several changes in the document, in general for the good. The vast majority of changes were editorial in nature, clearing up the intent of the text, but the underlying protocol is pretty solid and not very different qualitatively from draft -10. At this point, I believe that all open issues are addressed in the document or directed towards specific proposed extensions, and I haven't heard anything to the contrary.
>>>
>>> And I think you're reading the tone content of the discussion incorrectly. As I tried to carefully lay out below, I don't see fractures. I see multiple components that can work together and fit fairly nicely into a larger system. The existence of multiple solutions does not invalidate the applicability of a known good solution. We can not shelve something good just because there's a hint of something else on the horizon (which might be good or bad, we don't know yet).
>>>
>>> There is a lot of support for the Dynamic Registration draft that's there today, just look at the number of implementers and protocols that are actually using it. This is not a theoretical draft, this is not an intellectual exercise, this is not a speculative document -- this is a codification of real practice that we know works and has been implemented and deployed and tested.
>>>
>>> And speaking of these other protocols and systems -- they're going to move on whether we at the IETF want them to or not. Nobody is going to sit around and wait for the IETF-blessed version of this functionality.
>>> As a matter of fact, this document was born of the output of two groups who specifically *didn't* wait around for the IETF to solve this problem. We brought it "in house" here because we believed that it would be better to have a generally applicable solution than to have a dozen proprietary implementations. That's where true fragmentation comes from:
>>> implementations and deployments, not from minor quibbles about syntax.
>>> So could we stuff dynamic registration on a shelf and wait for a perfect solution to descend from heaven? Sure we could, but that would be so profoundly stupid that I would question the sanity of everyone in this working group. But if we come up with a solution that works, can be implemented, and is done in a timely fashion, then the world *will* use it. That's what we have, and that's what I want to move forward.
>>>
>>> There's also a lot of support for extensions (software statements) and different instantiations (SCIM) of the same basic protocol. These are good things, and they speak to the strength of the registration protocol, not its weakness.  I believe that what I've laid out below is a solid and reasonable plan for moving things forward and addressing everything that's been brought up, and so I invite the commentary of the whole of the working group. After all, the IETF is an organization of individuals and we work on rough consensus and running code.
>>>
>>>    -- Justin
>>>
>>> On 08/06/2013 07:18 PM, Anthony Nadalin wrote:
>>>> I think that the IETF meeting and session on Dynamic Registration showed how fractured it was and how we don't have consensus on what needs to be done and how it needs to be done. I would not support moving any draft further along in the IETF process. I looked on mailing list and could not find out where any dynamic registration document went to WGLC, so maybe someone can point me to that.
>>>>
>>>> -----Original Message-----
>>>> From: [e-mail] [mailto:[e-mail]] On
>>>> Behalf Of Justin Richer
>>>> Sent: Tuesday, August 6, 2013 2:18 PM
>>>> To: [e-mail]
>>>> Subject: [OAUTH-WG] A Proposal for Dynamic Registration
>>>>
>>>> At last week's IETF meeting, there was quite a lot of talk about the Dynamic Registration draft as well as a few other related drafts in this space. I would like to propose to the group what I think would be a positive working structure among the different approaches that would let us move everything forward. The source documents in discussion here are the WG's Dynamic Registration (draft 14) and Phil Hunt's individual submission of a SCIM-based alternative with some software assertion components to it. I suggest we refactor these into three documents:
>>>>
>>>>     - OAuth Dynamic Registration
>>>>     - SCIM-based OAuth Dynamic Registration
>>>>     - Software Statements for OAuth Dynamic Registration
>>>>
>>>> I think that they all have their place in the world, and this is how I see them fitting together:
>>>>
>>>>
>>>> OAuth Dynamic Registration
>>>>
>>>> What it is: Essentially the draft we have today, draft 14. This draft
>>>> defines a standalone RESTful API for dealing with client
>>>> registrations, it allows for open registration as well as protected
>>>> registration, and perhaps most importantly we know that it works
>>>> because people have implemented it as part of several different APIs.
>>>> This could have an informational pointer to the SCIM draft and the
>>>> Software Statements draft. We could call this one "core" or "basic"
>>>> or some other modifier, but I don't think that's necessary because it
>>>> already does what it says on the tin.
>>>>
>>>> What it needs to concentrate on: This needs to be a "base" document
>>>> with extension hooks in key places (such as the client metadata,
>>>> which is already extensible, and places that have been made
>>>> extensible like the token_endpoint_auth_method, and perhaps others).
>>>> It needs to get its job done, allowing for full specification of the
>>>> simple case in an interoperable way (anonymous registration of
>>>> self-asserted client metadata to receive a client identifier and
>>>> manage the registration) and be extensible and flexible enough for the more complex cases.
>>>>
>>>> What we should do: I think that we should continue shepherding this
>>>> document through WGLC in the OAuth WG because there are no specific
>>>> open issues in the spec (that I, the editor, am aware of) and I've
>>>> seen what I would personally consider to be rough consensus on it
>>>> (not unanimous, but that's not necessary anyway).
>>>>
>>>>
>>>>
>>>> SCIM-based OAuth Dynamic Registration:
>>>>
>>>> What it is: Most of Phil's draft, this defines a SCIM profile for
>>>> managing OAuth clients dynamically. This will accomplish the same
>>>> kinds of things that the OAuth Dynamic Registration Draft will
>>>> accomplish, but in a SCIM-like manner. This will have a normative
>>>> dependency on SCIM (of some version), and probably an informational
>>>> dependency on OAuth Dynamic Registration. This could have an
>>>> informational pointer to the Software Statements draft. This draft is
>>>> very useful if you're already deploying a SCIM based system, and if
>>>> you're investing in SCIM then it's going to be a smaller step to support this than it would be the base draft.
>>>> However, I strongly believe that SCIM is a really big jump for
>>>> implementing basic functionality that this is trying to accomplish.
>>>>
>>>> What it needs to concentrate on: Tracking with the overall SCIM
>>>> specification (on which it depends) and tracking with the data model
>>>> and general usage of the OAuth Dynamic Registration protocol
>>>> (wherever it makes sense to do so).
>>>>
>>>> What we should do: I think that this draft should be picked up and
>>>> worked on as an IETF document, but I think that it probably makes
>>>> more sense for that work to be done inside of the SCIM working group.
>>>> The reasons for this are twofold: First, this draft really should
>>>> look and feel like SCIM, and to do that it really needs the attention
>>>> of the group that's defining SCIM. Second, SCIM isn't completed and
>>>> likely won't be for some time to come, and this draft needs to track
>>>> with that protocol as it moves through the IETF process.
>>>>
>>>>
>>>>
>>>> Software Statements for OAuth Dynamic Registration
>>>>
>>>> What it is: Section 4 of Phil's draft (plus a few other bits,
>>>> discussed here), this defines a method for presenting signed and/or
>>>> verifiable claims to the registration server's endpoint. This is most
>>>> useful when an authorization server can verify the claims being
>>>> presented, such as being able to discover the signing key from the
>>>> "iss" claim and validate the signature. This could also be used (with
>>>> some additional
>>>> specification) by a discovery-based system that could fix ahead of
>>>> time some of the claims for a given piece of software (like we've
>>>> done with
>>>> BlueButton+). In some circumstances, this assertion could even
>>>> BlueButton+contain
>>>> all relevant bits of the registration, leaving the rest of the
>>>> metadata fields blank. This is essentially the "use the assertion as
>>>> the registration" flow that Phil discussed at the meeting, from what
>>>> I understand. In all of these cases, it can give us a higher
>>>> assurance for the registration and means to tie together multiple
>>>> instances of a piece of software across a network.
>>>>
>>>> What it needs to concentrate on: Making the software statements
>>>> interoperable. I don't think this is going to be an easy task, and I
>>>> think it's going to be a long process to get it *right* for all players.
>>>>
>>>> What we should do: I think that this draft should be picked up by the
>>>> OAuth Working Group as a WG document, and it should be built as an
>>>> extension to both the OAuth Dynamic Registration and SCIM-based OAuth
>>>> Dynamic Registration documents. I think it's important, but it's
>>>> added functionality on top of either the RESTful or the SCIM-based
>>>> registration documents, and as such it should have a normative
>>>> reference to both of them with detailed profiles of how to use them.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> So in all, we've got three main documents, each with different
>>>> purposes and concentrations, and with different timelines. I don't
>>>> see any problem with these coexisting, and I think doing things this
>>>> way can cover all of our known use cases and let us actually progress
>>>> these documents and move forward.
>>>>
>>>>     -- Justin
>>>> _______________________________________________
>>>> 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