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" <[email protected]> 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 [email protected] https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
