The counter argument is that if you do something that's half way between
two fairly well-established programming practices, then you can end up
making a strange chimera. I agree that we shouldn't "boil the ocean",
but dictating HTTP verb usage on the endpoint is far from that.
The crux of my argument is this: with the same input format in and out,
we have an opportunity to make something much more RESTful than with the
data formats being asymmetrical, as they are now.
I'll put together a draft of this proposed change to DynReg sometime
this week that's much more fully RESTful, based on Nat's OIDC
registration draft. The pros/cons below still apply, but I think it
might help people to see a concrete proposal. The goal will still be to
have a base DynReg proposal that OIDC, UMA, and others can profile and
extend for their use cases.
-- Justin
On 02/04/2013 04:46 PM, Mike Jones wrote:
I'm not proposing that we boil the ocean. "Diving in with both feet
and define a full RESTful API with all appropriate verbs and CRUD ops"
is an almost sure way to build a complicated spec, most of which isn't
needed, and to have it take a long time.
Everything in the current OpenID Registration spec is motivated by an
actual use case. Stuff that isn't isn't in the spec. That's nearly
true of the closely-related OAuth Registration spec, with what I
believe to be a few exceptions. (Yes, we should harmonize those
differences -- hopefully based upon real use cases.)
I was only proposing that we answer the single question of whether
we're using the right input format or not. I hope we can keep the
discussion to that topic and not use it to generate a passel of new
work items as a side effect.
-- Mike
*From:*Richer, Justin P. [mailto:jric...@mitre.org]
*Sent:* Monday, February 04, 2013 1:34 PM
*To:* Mike Jones
*Cc:* oauth@ietf.org
*Subject:* Re: [OAUTH-WG] Should registration request be
form-urlencoded or JSON?
For history, the original UMA registration spec from whence this all
grew was JSON-in and JSON-out. It's feeling like this is coming back
around.
Pro:
- more REST-ish (particularly if we use real REST style like URL
templates and verbs)
- consistent data structures
- possible use of rich client data structures like lists and sub-objects
Con:
- unlike the rest of OAuth, which is form-in, JSON-out
- major change from existing code
- possible overhead for existing OAuth libraries which haven't had to
deal with JSON from clients
If we're going to do this, we should dive in with both feet and define
a full RESTful API with all appropriate verbs and CRUD ops, and define
it at the OAuth DynReg level as well.
-- Justin
On Feb 4, 2013, at 4:25 PM, Mike Jones <michael.jo...@microsoft.com
<mailto:michael.jo...@microsoft.com>>
wrote:
Now that we're returning the registration state as JSON, it's pretty
inconsistent for the registration request to instead be
form-url-encoded. The case can be made for switching to JSON now -
especially in light of possibly wanting to convey some structured
information at registration time.
I realize that this is a big change, but if we're going to do it, we
should do it now.
As a precedent, apparently SCIM requests are JSON, rather than
form-url-encoded.
-- Mike
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
