Re: [OAUTH-WG] return to draft 6 spec org?

[Brian Eaton <[e-mail]>]

On Sun, Jul 11, 2010 at 7:37 AM, Eran Hammer-Lahav <[e-mail]> wrote:
> I think the way to solve it is to make them more detailed and normative.
> This will retain the general framework as current specified, but will
> provide a reference-able description of useful profiles. This will also make
> it easier to discuss the security attributes of each profile. In addition,
> it is probably only be useful to define the user-agent and web-based as
> fully specified profiles, given that the rest are not really profiles but
> vague guidelines as to how to use OAuth for other “stuff”.

Actually, the old "vague guidelines" weren't vague, and they weren't
guidelines.  They were very specific instructions on how flows should
be implemented.  They dated back to the WRAP specification, which
multiple organizations reviewed carefully because they were all going
to implement those flows the exact same way.

The new spec has turned what used to be very precise language into
mush.  It's introduced confusion and security problems that weren't
present originally.  Please fix them.

The client credentials flow is a great point of comparison.

Here's dick's draft:
http://tools.ietf.org/html/draft-hardt-oauth-01#section-5.1.2

Here's draft 6: http://tools.ietf.org/html/draft-ietf-oauth-v2-06#section-2.9.1

Here's draft 10: http://tools.ietf.org/html/draft-ietf-oauth-v2-10#section-4.1

Dick's draft:
- clear guidance on use case
- obvious normative language specifying exactly one way to send a request,
- one success response
- one error response
- normative language specifying error handling

Draft 6:
- vague guidance on use case
- obvious normative language specifying exactly one way to send a request,
- two success responses, with no way to distinguish which the server
should send.  But one of them is insecure.
- one error response
- no normative language specifying error handling

Draft 10:
- no guidance on use case
- confusing normative language
- two success responses, with no way to distinguish which the server
should send.  But one of them is insecure.
- six different error responses (most of which don't make sense for
the use case and will never be used.)
- no normative language specifying error handling

Cheers,
Brian