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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
