If we define that unrecognized arguments / elements are ignored then we can define extensions such that if their arguments / elements are ignored they don't introduce insecurity.
Ian On Tue, Jun 29, 2010 at 10:01 AM, 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 > > -- Ian McKellar <http://ian.mckellar.org/> i...@mckellar.org: email | jabber | msn ianloic: flickr | aim | yahoo | skype | linkedin | etc. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
