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

From: Mike Jones <[email-masked]>
Date: Mon, 4 Feb 2013 21:25:22 +0000

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

---

From: "Richer, Justin P." <[email-masked]>
Date: Mon, 4 Feb 2013 21:34:03 +0000

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 <[email-masked]<mailto:[email-masked]>>
 wrote:

                                                                -- Mike

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: "Richer, Justin P." <[email-masked]>
Date: Mon, 4 Feb 2013 21:35:50 +0000

Additionally:

This begs the question, why not just do SCIM here? CloudFoundry's UAA has a SCIM class for OAuth clients that they use for dynamic registration today.

 -- Justin

                                                                -- Mike

---

From: Mike Jones <[email-masked]>
Date: Mon, 4 Feb 2013 21:46:44 +0000

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:[email-masked]]
Sent: Monday, February 04, 2013 1:34 PM
To: Mike Jones
Cc: [email-masked]
Subject: Re: [OAUTH-WG] Should registration request be form-urlencoded or JSON?

Pro:

Con:

-- Justin

                                                                -- Mike

---

From: Tim Bray <[email-masked]>
Date: Mon, 4 Feb 2013 13:51:00 -0800

>From the point of view of developer experience, meh, the degree of
difficulty of generating/parsing JSON & form/url is about the same.

JSON has the advantage that it forces you to use UTF-8, and is more
pleasant to debug when things get weird.

For my money, anything that forces anyone to use UTF-8 is A Good Thing.  -T

On Mon, Feb 4, 2013 at 1:46 PM, Mike Jones <[email-masked]>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:[email-masked]]
> *Sent:* Monday, February 04, 2013 1:34 PM
> *To:* Mike Jones
> *Cc:* [email-masked]
> *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 <[email-masked]>****
>
>  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***
> *
>
>  ****
>
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth****
>
> ** **
>
> [email-masked]

---

From: John Bradley <[email-masked]>
Date: Mon, 4 Feb 2013 15:49:20 -0700

For debugging JSON is cleaner than form encoded.  I hate faking arrays with space separated list (yes like scopes).

It is the way it is to be consistent with OAuth.

I think that should be a separate issue from url templates etc.

John 

On 2013-02-04, at 2:51 PM, Tim Bray <[email-masked]> wrote:

> From the point of view of developer experience, meh, the degree of difficulty of generating/parsing JSON & form/url is about the same.
> 
> JSON has the advantage that it forces you to use UTF-8, and is more pleasant to debug when things get weird.
> 
> On Mon, Feb 4, 2013 at 1:46 PM, Mike Jones <[email-masked]> 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
> 
>  
> 
> On Feb 4, 2013, at 4:25 PM, Mike Jones <[email-masked]>
> 
>  wrote:
> 
> 
> 
>

---

From: Dale Olds <[email-masked]>
Date: Mon, 04 Feb 2013 23:42:17 -0800

Rather surprised (and pleased) to see a reference to the UAA here, but I 
would like to make a quick clarification.

Justin, I think we concluded that what the UAA is doing is static client 
registration via SCIM extensions, not dynamic client registrations. The 
UAA has been serving OAuth2 and SCIM requests in the cloudfoundry.com 
PaaS for over a year now -- there was no client registration standard at 
that time, and SCIM provides what we need.

I agree with your point that we should not invent unnecessary standards, 
and SCIM is working quite well for us in combination with OAuth2 for 
static client registrations. That said, I expect we will have a future 
need for dynamic client registrations and that there may be some 
significant differences.

And my preference would also be json in and json out.

--Dale

On 02/04/2013 01:35 PM, Richer, Justin P. wrote:
> Additionally:
>
> This begs the question, why not just do SCIM here? CloudFoundry's UAA 
> has a SCIM class for OAuth clients that they use for dynamic 
> registration today.
>
>  -- Justin
>
>
>> 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.
>> should do it now.
>> form-url-encoded.
>> [email-masked] <mailto:[email-masked]>

---

From: Justin Richer <[email-masked]>
Date: Tue, 5 Feb 2013 10:04:09 -0500

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.
>
> 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:[email-masked]]
> *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:
>
> templates and verbs)
> 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
>

---

From: Justin Richer <[email-masked]>
Date: Tue, 5 Feb 2013 10:11:59 -0500

Dale is correct, I was misremembering slightly -- UAA does not do what 
we would really call dynamic registration with SCIM, but rather does a 
static client provisioning using SCIM as the API for provisioning the 
client objects. Still, it's a real-life implementation of something 
similar that we can look at.

  -- Justin

On 02/05/2013 02:42 AM, Dale Olds wrote:
> Rather surprised (and pleased) to see a reference to the UAA here, but 
> I would like to make a quick clarification.
>
> Justin, I think we concluded that what the UAA is doing is static 
> client registration via SCIM extensions, not dynamic client 
> registrations. The UAA has been serving OAuth2 and SCIM requests in 
> the cloudfoundry.com PaaS for over a year now -- there was no client 
> registration standard at that time, and SCIM provides what we need.
>
> I agree with your point that we should not invent unnecessary 
> standards, and SCIM is working quite well for us in combination with 
> OAuth2 for static client registrations. That said, I expect we will 
> have a future need for dynamic client registrations and that there may 
> be some significant differences.
>