Another use case for signatures is gross management of relationships, controlling the secrets in use for (I'll misuse the term) peers allows a single point of control for that relationship.
> -----Original Message----- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Freeman, Tim > Sent: Wednesday, October 27, 2010 11:09 AM > 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
