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

The spec organization isn't about reusing prose, but about providing a consistent and well-defined protocol architecture. WRAP called the different flows for each client 'profiles' which was wrong in WRAP because it wasn't actually profiling anything - it was describing completely separate flows. The current spec went back to calling them profiles because now they are truly profiles of the generic framework defined by the two endpoints.

I am unhappy with the current state of the client profiles in the introduction so we agree on that. But where you call for a complete restructure, I prefer making the current structure more useful.

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".

EHL

On 7/10/10 9:15 PM, "Brian Eaton" <beaton@google.com> wrote:

I think it would be a good idea to return to the draft 6 organization.

Draft 6: normative language for each flow was called out separately,
and was described from start to finish, in chronological order, with
no interruption.  Each step showed what a client should send, and what
an authorization server should return.

Draft 7 and further: flows are merged to reuse spec language.  Steps
for any given use case are now interrupted with steps for other use
cases.

For example, consider a client developer who wants to implement the
web server flow.

First they have to read section 3.1, to describe the redirect they
need to send to the authorization server.

Then they read section 3.2, to see the redirect back.

Then they read section 4.1.1, to see the request they send to the
authorization server.

Then they skip a few pages, because they don't care about assertions
or passwords or refresh tokens.

They they read section 4.2, to see the response from the authorization server.

Then they skip several more pages to get to section 5, so they can access data.

Then they skip back to section 4.1.4, because they need to refresh their token.

Compare this to draft 6:
- read section 2.5
   this is everything you need to get a token, with no intervening
cruft about credentials you don't have.

- read section 4
   this is everything you need to use a token.

- read section 3
   this is everything you need to refresh a token.

Cheers,
Brian
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth