#2 is the best route forward. If a particular extension requires its parameters to be present and handled, then it has a few different options. One is breaking at the server side, either with an explicit error or throwing away some other required bit, which has been mentioned. Another is looking for a callback return parameter on the client side. If the server doesn't return it, then the server didn't support that extension and the client should break the flow at that point.
I want to ask the list though: what exactly do we mean by ignoring parameters? Is it that a server library will ignore unknown parameters coming in when doing its processing? That I agree with completely. Same with parameters coming back to the client from the server. If you don't know about it, don't try to do anything with it. The one case that I don't think libraries can *ignore* extra parameters is when using a client library to build a request to a server. A particular server implementation may require extra parameters on the request in order to function (such as MediaWiki's title parameter), and a client needs to be able to pass such things through. These parameters can effectively be thought of as part of the address of the server URL, can be ignored by the OAuth part of the server process, but cannot be dropped by the client building the request. So "ignore" in this case means "quietly pass through" and not "drop". In most instances outside of the Big Web Companies, OAuth is going to be the new kid being grafted onto an existing framework or application. As such, it really needs to play nice. -- Justin On Mon, 2010-06-28 at 20:59 -0400, Eran Hammer-Lahav wrote: > 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
