On Tue, Aug 17, 2010 at 11:48 AM, David Recordon <[email protected]> wrote: > Luke's point still holds true of the core spec needing to allow a 200 status > code on an error in this scenario. I'd also rather see this as part of the > core spec as it reduces the number of things that implementors will need to > read for common use cases.
For the record, I think any implementer that is relying on protected resources returning special response codes for any type of OAuth protocol issue is probably going to get burned. Variation in protected resource behavior has been a consistent problem in OAuth 1.0, and I doubt that can change in OAuth 2. It's tough to get protected resource servers to be consistent; they frequently have good reasons (e.g. jsonp) to be inconsistent. Authorization servers are simpler beasts. _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
