Ignore as in, pretend it wasn't sent (from either the client or server). EHL
> -----Original Message----- > From: Justin Richer [mailto:jric...@mitre.org] > Sent: Thursday, July 01, 2010 6:03 AM > To: Eran Hammer-Lahav > Cc: Yaron Goland; OAuth WG > Subject: Re: [OAUTH-WG] How do we deal with unrecognized elements in > requests and responses? > > #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
