Re: [OAUTH-WG] So back to use cases? (was RE: Call for Consensus on Document Split)

[William Mills <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf
> Of Freeman, Tim
> Sent: Wednesday, October 27, 2010 11:09 AM
> To: [e-mail]
> 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: [e-mail]
> Desk in Palo Alto: [phone]
> Home: [phone]
> Cell: [phone]
> 
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of Mike Jones
> Sent: Wednesday, October 27, 2010 9:57 AM
> To: Hannes Tschofenig; Blaine Cook; [e-mail]
> 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: [e-mail] [mailto:[e-mail]] On Behalf
> Of Hannes Tschofenig
> Sent: Wednesday, October 27, 2010 4:34 AM
> To: Blaine Cook; [e-mail]
> 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" <[e-mail]> 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/oauth
> 
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
> 
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth