It also depends on how extensions will work, looking forward to read -09. If extensions are namespaced somehow then you could ignore unknown extension but be strict with core parameters (those would be parameters with no namespace) and with known extensions.
Marius On Mon, Jun 28, 2010 at 3:01 PM, Yaron Goland <yar...@microsoft.com> wrote: > 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
