There are 3 general ways to deal with this: 1. Break on unrecognized parameters - this tends to make the use of extensions hard, and at a minimum requires an error to include the bad parameter in a machine readable way (so a library can figure out an extension is not supported).
2. Ignore unrecognized parameters - this is the usual way of dealing with extensible protocols. It has security implications when extension parameters must not be ignored. However, the workaround is simply to break something else (i.e. replace the client_id with something else that will cause the normal flow to break). 3. Same as #2 but include a directive which means 'must not ignore any parameter; return error if any parameter is unknown'. XRD used to include such a 'must-support' attribute for properties but was dropped due to lack of use cases. I think #2 offers a good enough balance here, but am happy to discuss #3 if people have actual use cases where ignoring an extension will cause security issues. Note that with the expectation of error codes, my upcoming extensibility proposal does not allow adding any new parameter values (only new parameters). EHL From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Yaron Goland Sent: Monday, June 28, 2010 3:02 PM To: oauth@ietf.org Subject: [OAUTH-WG] How do we deal with unrecognized elements in requests and responses? In a private thread with Eran an issue came up regarding how to handle unrecognized arguments in OAuth requests and responses. For example, if a token endpoint receives an access token request that contains both a client_id and a client_foo_bar argument, what should it do? Should it reject the request since it doesn't recognize client_foo_bar? Should it ignore client_foo_bar and just process the request based on client_id? Similarly imagine that a response to an access token request contains a JSON member with some unrecognized name. What's the right behavior? Ignore the unrecognized value? Or treat the response as badly formatted and fail out? We need to define in the spec how to deal with unrecognized extensions. Typically the rule is 'ignore what you don't recognize' but there is a countervailing rule which applies here which is "security is different". Typically ignoring unrecognized elements in a security context can lead to security holes. Just looking at the history of OAuth I suspect we need to go with the ignore rule and then explore ad nauseam in the security considerations section all the ways that the ignore rule can go wrong if extensions aren't handled carefully. Thoughts? Thanks, Yaron
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
