I like your response. I think application/json and application/xml would be fine without application/x-www-form-urlencoded. I just thought it made a good lowest common denominator for serialization which I think aids in making it simple to support multiple formats.
On May 26, 2010, at 12:19 AM, Manger, James H wrote: > Kris, > >> The OAuth endpoint should be able to match the format(s) of the API it >> protects. > > I had a quick look at the APIs for 24 services implementing OAuth (v1 or > drafts of v2) as listed on the OAuth wiki. > > Of these 24 APIs, the response formats supported were: > * 21 XML > * 19 JSON > * 16 XML and JSON > * 5 XML only > * 3 JSON only > > Other formats with some support: Atom, RSS, PHP, JSONP, CSV, vCards, > FastInfoset, XML-RPC. > > None use form-encoding for responses. > > >> Once again, I want to plea the case for keeping the response >> simple key/value string pairs so it is trivial to serialize to multiple >> formats. > > Most APIs from this sample offer multiple formats. > None restricted themselves to simple key/value string pairs. > None attempt to serialize to a format with as little structure as > form-encoding. > > > Where OAuth2 differs from most APIs is that it offers a response over 2 > different "channels": an HTTP response body (as APIs do); and in a HTTP > redirect (which most APIs don't do). > If we really want to match the formats of the API being protected, then the > HTTP redirect channel should tunnel exactly the same response that could be > obtained in an API-like response body. Putting base64url-encoded XML or JSON > in the redirect URI is one way to do such tunnelling. Its not the simplest > solution for the simplest use case, but it is clear and future-proof. > > -- > James Manger _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
