I agree.
I think we indeed should clearly articulate the use cases driving
discovery (maybe Zachary could report on those?), but I also think that
we will probably need to get something like "procedures," which describe
expected usages, within the protocol specification. For one thing, all
extensions whose support is essential under specific circumstances
should be described listing such circumstances and recommending the
action. (I also think that the idea of specifying pre- and post-
conditions in use cases will help.)
Igor
Eran Hammer-Lahav wrote:
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:record...@gmail.com]
*Sent:* Monday, June 28, 2010 6:11 PM
*To:* Eran Hammer-Lahav
*Cc:* Yaron Goland; OAuth WG (oauth@ietf.org)
*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
<e...@hueniverse.com <mailto: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>
[mailto: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 <mailto: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 <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
------------------------------------------------------------------------
_______________________________________________
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
