For #2, if an extension defines required parameters then you're not supporting the extension if you ignore them. Or am I missing something?
On Mon, Jun 28, 2010 at 5:59 PM, Eran Hammer-Lahav <e...@hueniverse.com>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 > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
