Hannes, Thank you for the review and comments. My responses (which start with Z:) are below.
-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Hannes Tschofenig Sent: Friday, June 22, 2012 3:08 AM To: [email protected] WG ([email protected]) Subject: [OAUTH-WG] Use case document Hi all, I just looked at the use case document and a few questions came to my mind: * Who is the lead editor? Z: I have been doing most of the editing. * The abstract and the introduction explain the history of why the document exists. You may want to change that to an introduction that describes what use cases are in the document and why you have chosen them instead of thousands of others, and why the reader should look into them. After some time (and particularly after the publication as an RFC) it does not matter whether the use cases got collected between IETF 77 and IETF 78. Z: This part will be revised. The cases were chosen of those that had been discussed on the list (are there are less than thousands of such cases :)). * The reference to RFC 2119 is not needed and Section 2 is not needed. Z: I will remove that. * More important, however, is the question of what use cases should be covered in the document and how you call them. Needless to say that there are many use cases for OAuth. For example, I believe it makes little sense to list use cases according to what data is exchanged (social networking information vs. travel plans vs. payment information). So, what are the distinguishing aspects that make it worthwhile for a use cases to be included? Z: I agree with these statements. I am not sure that I understand which text in the draft has generated your comment " it makes little sense to list use cases according to what data is exchanged (social networking information vs. travel plans vs. payment information)", but I agree with this. The intent was to provide the use cases that cover the OAuth flows (i.e., the various uses of OAuth). There are also use cases that have been discussed during the specification development, but are not supported by OAuth 2.0. I would say that the different protocol profiles somehow have to be covered. This includes the different cases for the various authorization grants. I would also say that different security levels matter. If you do that then it would also be useful to connect the individual use cases back to the other working group documents via references. Z: That was an intent - to describe the use cases that employ different authorization grants. For example, the use cases "Web server" and " Client password (shared secret) credentials" aim at doing just that. Other aspects that could matter are different implementation strategies or different user appearance. On the latter the device flow is an example. In any case, you have to decide what the criteria are since this determines your target audience. Who do you expect will most likely benefit from reading this document? Z: I believe that the use cases are helpful for understanding a protocol. It is useful to map a particular OAuth flow to a use case. There are various use cases in the document that are not sufficiently different from the rest unless you highlight some aspects that you think are really essential. Z: I plan to address this your comment (and others too) in the next version. It would be helpful to know which cases appear to you not sufficiently different. Ciao Hannes Zachary _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
