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 <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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
