Subject: [OAUTH-WG] draft-ietf-oauth-v2-05.txt editorial and clarification

From: Kristoffer Gronowski <[email-masked]>
Date: Tue, 18 May 2010 16:40:26 -0400

Hi!

I am in the middle of implementing both the client and server side and noted some things.
Tried to check a while back to see that the issues was not raised earlier but if I happen to raise a sensitive issue discussed earlier, let me know.

First two minor comments on the spec.
Page 30 code param is not stated if it is required or optional. A qualified guess would be that it should be required.
Page 38 & 39 two parameters named "format" one optional one required.

Page 43 Contradicting statement: Access tokens SHOULD NOT be sent in the clear... while the next paragraph talks about how to do it.
It could be ok to keep this option but it should probably be balanced better. The problem is not writing the server but the client side.

One big issue is that there is no way of querying what flows a server supports. This might result in expensive and non portable library implementations.
There could be multiple solutions:
* A new rest request that can answer what flows are supported.
* Use of a HTTP header (such as Accept)
* Standardized response with and error code 404 or even better 501 with a list of the ones supported

In the response format issue I would put my vote on HTTP POST body due to less library dependency. It should at least be the default and the client needs to understand and make use of it in many of the flows anyway.
JSON would be my second pick due to the ease of integration on browsers and JavaScript. If possible remove XML.

All this options adds to complexity and IMO will raise the cost of implementation and significant need for bake off between different systems.
Another point that could simplify is to only allow for parameters in the Authorization header for access (Scrap URI param and FORM).
This has proven to be a large source of wasted implementation time with Oauth 1.0 from the client side since the spec was too open.
A developer needs to probe for every community he tries to integrate to.

BR Stoffe

P.s. Sorry but can't attend and discuss the proposals on Thursday due to Google IO, but will try to show up at the next meeting.