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
