Personally I think we should go with #2.
Those who need 'mandatory to implement' extensions should do exactly what Eran
suggested and implement the extension in a way that breaks the core syntax so
they are guaranteed that those who don't support the extension will fail.
Just my two cents,
Yaron
From: [email protected] [mailto:[email protected]] On Behalf Of Eran
Hammer-Lahav
Sent: Monday, June 28, 2010 6:17 PM
To: David Recordon
Cc: OAuth WG ([email protected])
Subject: Re: [OAUTH-WG] How do we deal with unrecognized elements in requests
and responses?
There are times when the client wants the server to fail if it doesn't support
an extension. The client developer might consider the server as being less
secure without the added protection of the extension and would like the server
to be able to tell it was making such a request and fail.
This clearly belongs in the use cases driving discovery, as in the core
specification, the client is expected to be familiar with the details of the
server. So we just need to make sure that we don't prevent such use cases. #2
doesn't prevent it, but requires the client to break something else. For
example, an extension having to do with client identity should replace the
client_id parameter with something else, making a server unaware of this
extension fail (because the required client_id parameter will be missing).
EHL
From: David Recordon [mailto:[email protected]]
Sent: Monday, June 28, 2010 6:11 PM
To: Eran Hammer-Lahav
Cc: Yaron Goland; OAuth WG ([email protected])
Subject: Re: [OAUTH-WG] How do we deal with unrecognized elements in requests
and responses?
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
<[email protected]<mailto:[email protected]>> 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: [email protected]<mailto:[email protected]>
[mailto:[email protected]<mailto:[email protected]>] On Behalf Of
Yaron Goland
Sent: Monday, June 28, 2010 3:02 PM
To: [email protected]<mailto:[email protected]>
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
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
