Re: [OAUTH-WG] Use case document

"Zeltsan, Zachary (Zachary)" <> Fri, 22 June 2012 16:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4870321F86C6 for <>; Fri, 22 Jun 2012 09:53:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DJO1vaZIiMN2 for <>; Fri, 22 Jun 2012 09:53:32 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D9A4621F86B4 for <>; Fri, 22 Jun 2012 09:53:25 -0700 (PDT)
Received: from ( []) by (8.13.8/IER-o) with ESMTP id q5MGrJ7I027918 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 22 Jun 2012 11:53:19 -0500 (CDT)
Received: from ( []) by (8.14.3/8.14.3/GMO) with ESMTP id q5MGrJVK018737 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 22 Jun 2012 11:53:19 -0500
Received: from ([]) by ([]) with mapi; Fri, 22 Jun 2012 11:53:19 -0500
From: "Zeltsan, Zachary (Zachary)" <>
To: 'Hannes Tschofenig' <>, "' WG ('" <>
Date: Fri, 22 Jun 2012 11:53:15 -0500
Thread-Topic: [OAUTH-WG] Use case document
Thread-Index: Ac1QRcXDmBFpqxinT4KSYdJpnH1v+QASojKA
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on
X-Scanned-By: MIMEDefang 2.64 on
Subject: Re: [OAUTH-WG] Use case document
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 22 Jun 2012 16:53:34 -0000


Thank you for the review and comments. My responses (which start with Z:) are below.

-----Original Message-----
From: [] On Behalf Of Hannes Tschofenig
Sent: Friday, June 22, 2012 3:08 AM
To: WG (
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.


OAuth mailing list