>* Use cases that justify a feature seem to require two parts -- an example >>where the feature is absent and therefore a particular problem cannot be >>solved, and an example where the feature is present and the same problem >can >then be solved.
There are use cases that can be supported by more than one solution. For example, the use case specified in the original OAuth specifications (authorizing a client to print private photos) relies on the signature-based solutions. The same use case in OAuth 2.0 -v10 (Web Server) is supported by a solution that does not use signatures, but requires to use TLS. So, the same problem is solved in two different ways and each solution justifies different features. Zachary -----Original Message----- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Freeman, Tim Sent: Wednesday, October 27, 2010 2:09 PM To: oauth@ietf.org Subject: [OAUTH-WG] So back to use cases? (was RE: Call for Consensus on Document Split) On the face of it, it seems that discussion of whether and how to split the document has derailed collection of use cases. If we had consensus on a list of use cases, that would mean we have identified the problems we're trying to solve. This would still allow slimy political manipulation of the process by manipulating the use case list, but that would be progress. It's better to have a protocol that solves a politically-defined set of problems than to have a politically-defined protocol that solves no identified problem. It's also possible that such collection is going on via private email and I am not aware of it. The questions currently interesting to me about use cases are: * The only use cases that made sense to me about signatures used them for auditability, where they enabled blame to be properly placed after information leaked to the wrong people. People were proposing use cases that claimed that signatures improved privacy, that is, the ability to keep the information out of the hands of the wrong people. So far as I know all use cases where signatures improved privacy seemed to fall apart after a few minutes inspection. Do we agree that signatures improve auditability but not privacy, or does someone still believe in a use case where signatures improve privacy? * Use cases that justify a feature seem to require two parts -- an example where the feature is absent and therefore a particular problem cannot be solved, and an example where the feature is present and the same problem can then be solved. Last I checked the existing use case list seemed to only have the second type where problems were successfully solved and it was unclear to me that the proposed features were really required in order to do that. Do we agree that justifying a feature requires both a use case where absence of the feature makes a problem unsolvable and presence of the feature makes the same problem solvable? (Alternatives are to believe that there is some other way to justify having a feature, or to believe we should have features that do not have a clearly described technical justification. Maybe the features are required by law, are esthetically pleasing, make use of the right patents and not the wrong ones, look impressive on one's resume, etc.) * The simplest signature schemes seem have the consequence of preventing server A from delegating work to server B, since the work must be done by making requests signed by server A. Do we want to support use cases where one server delegates work to another server? Do we want to do by allowing A's right to do certain things to be traded in for something that gives B the right to do some of those things, by bearer tokens, by some other means, or not at all? Tim Freeman Email: tim.free...@hp.com Desk in Palo Alto: (650) 857-2581 Home: (408) 774-1298 Cell: (408) 348-7536 -----Original Message----- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Mike Jones Sent: Wednesday, October 27, 2010 9:57 AM To: Hannes Tschofenig; Blaine Cook; oauth@ietf.org Subject: Re: [OAUTH-WG] Call for Consensus on Document Split Thanks for your confidence in me. I look forward to completing a specification that meets the industry needs. I plan to sync with Eran this week. I also plan to hold a "listening tour" at IIW to understand stakeholders' perspectives on where we stand with OAuth 2.0 today and what remains to do finish it. Please come talk to me at IIW if you're there and you're building or deploying OAuth 2.0 and want me to understand your views. E-mail and phone calls are also welcome. Once I've synced with Eran and gathered input from stakeholders, I'll plan on announcing target dates for drafts. -- Mike -----Original Message----- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig Sent: Wednesday, October 27, 2010 4:34 AM To: Blaine Cook; oauth@ietf.org Subject: Re: [OAUTH-WG] Call for Consensus on Document Split Hi all, based on the feedback from the group on the list we go forward with the document split. Mike had kindly offered to edit the bearer specification and we are happy to hear that. Thank you Mike. I am looking forward to see the first document. Ciao Hannes On 10/14/10 3:32 AM, "Blaine Cook" <rom...@gmail.com> wrote: > Over the past few weeks, the working group debated the issues around > the introduction of signatures and the structure of the specification. > The working group seems to endorse the proposal to split the current > specification into two parts: one including section 5 (bearer token) > and the other including the rest (how to obtain a token), with an > additional specification covering signature use cases. > > This serves as a call for consensus on the proposed editorial work. > Before we proceed with the changes, the chairs would like to ask if > anyone has any concerns or objections against this proposal. > > In addition, the chairs are seeking a volunteer to take over the > bearer token specification (section 5) as editor. > > Please submit your comments by Wednesday, October 20th. > > - The OAuth Working Group Chairs > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
