Three things about draft-05's new format parameter. 1. Error Response: http://tools.ietf.org/html/draft-ietf-oauth-v2-05#section-3.3.2.2
Presumably, the error response format should reflect the format parameter passed by the client. Proposed Text (wording taken from http://tools.ietf.org/html/draft-ietf-oauth-v2-05#section-3.3.2.1): If the token request is invalid or unauthorized, the authorization server constructs a response using the format requested by the client, which includes the common parameters set as well as additional flow-specific parameters. The formatted parameters are sent to the client in the entity body of the HTTP response with a 400 status code (Bad Request). Also, I'm not sure what "the common parameters set" means. Perhaps change both http://tools.ietf.org/html/draft-ietf-oauth-v2-05#section-3.3.2.2 and http://tools.ietf.org/html/draft-ietf-oauth-v2-05#section-3.3.2.1 to read "the common parameters listed here"? 2. Accept Header Could the functionality of the format parameter be replaced by an HTTP Accept header? It's not as flexible (I suppose an AS could define multiple XML formats, for example), and probably can't be used conveniently in GET requests. Currently, all requests defined in the spec that use the format parameter are POST requests, though. Accept: application/json Accept: application/xml Accept: application/x-www-form-urlencoded 3. Naming Conflict The assertion flow now has two format parameters :) Renaming one or requiring the use of an Accept Header as above would solve this. --mdawaffe _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
