In general, you are correct. However in this case, since OAuth 2.0 does not attempt to guarantee interop between a generic client and any vendor, the vendor has the right to define its own requirements as long as they are within the spec boundaries.
For example, a vendor can define a missing or empty scope to mean no scope and reject the request. That's allowed since the definition of scope is left for the vendor to define. Personally, I would not write a server implementation with this behavior and instead define a default scope that's sufficient in most cases. EHL From: [email protected] [mailto:[email protected]] On Behalf Of agks mehx Sent: Sunday, January 08, 2012 2:13 PM To: [email protected] Subject: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in Specification My client implementation per latest draft did not work against a major vendor's server implementation. This was because the vendor REQUIRES the scope parameter in the initial request. If I do not supply the scope parameter, it calls back the URL with an error response stating that the request is invalid: error=invalid_request&error_description=Missing+required+parameter:+scope I reported this to the vendor and the vendor claims that the IETF draft specification says scope is OPTIONAL and that means the vendor is free to make it required in a conforming implementation. After a careful reading of the relevant sections of the draft specification, I do not believe that is what is the intent of the specification. It says "OPTIONAL" is to be interpreted per RFC2119, which in turn says: "an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.)" This leads me to believe that if I do not supply scope I should not get an error -- I may not be able to perform any API calls but I should get a token back that proves to me that the user was *some* user at the vendor. Could you please clarify or disambiguate?
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
