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

[Dale Olds <[e-mail]>]

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
>
>
> On Feb 4, 2013, at 4:25 PM, Mike Jones <[e-mail] 
> <mailto:[e-mail]>>
>  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
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth