Re: [OAUTH-WG] Should registration request be form-urlencoded or JSON?

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:jricher@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.Jones@microsoft.com 
> <mailto:Michael.Jones@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
>