#2 makes most sense to me On Thu, Jul 1, 2010 at 9:03 AM, Justin Richer <jric...@mitre.org> wrote: > #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 >
-- http://agree2.com - Reach Agreement! http://stakeventures.com - My blog about startups and agile banking _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
