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

"Freeman, Tim" <tim.freeman@hp.com> Wed, 27 October 2010 18:09 UTC

Return-Path: <tim.freeman@hp.com>
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 004533A6991 for <oauth@core3.amsl.com>; Wed, 27 Oct 2010 11:09:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.448
X-Spam-Level:
X-Spam-Status: No, score=-106.448 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z5ouI9oqJHg7 for <oauth@core3.amsl.com>; Wed, 27 Oct 2010 11:09:15 -0700 (PDT)
Received: from g5t0007.atlanta.hp.com (g5t0007.atlanta.hp.com [15.192.0.44]) by core3.amsl.com (Postfix) with ESMTP id A7B043A6803 for <oauth@ietf.org>; Wed, 27 Oct 2010 11:09:15 -0700 (PDT)
Received: from G6W0641.americas.hpqcorp.net (g6w0641.atlanta.hp.com [16.230.34.77]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by g5t0007.atlanta.hp.com (Postfix) with ESMTPS id B1F19147FC for <oauth@ietf.org>; Wed, 27 Oct 2010 18:11:05 +0000 (UTC)
Received: from G4W1852.americas.hpqcorp.net (16.234.97.230) by G6W0641.americas.hpqcorp.net (16.230.34.77) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 27 Oct 2010 18:09:26 +0000
Received: from GVW0432EXB.americas.hpqcorp.net ([16.234.32.146]) by G4W1852.americas.hpqcorp.net ([16.234.97.230]) with mapi; Wed, 27 Oct 2010 18:09:25 +0000
From: "Freeman, Tim" <tim.freeman@hp.com>
To: "oauth@ietf.org" <oauth@ietf.org>
Date: Wed, 27 Oct 2010 18:09:23 +0000
Thread-Topic: So back to use cases? (was RE: [OAUTH-WG] Call for Consensus on Document Split)
Thread-Index: AQHLazd3pTJ/WW6MjUa2saVGmJKCG5NVNKoA///jsGCAAAIRoA==
Message-ID: <59DD1BA8FD3C0F4C90771C18F2B5B53A653ACE4C0B@GVW0432EXB.americas.hpqcorp.net>
References: <AANLkTik30oVX+AevGCZDHajjyrDnEVB=fp6rAdihkPFz@mail.gmail.com> <C8EDE8E4.2517%hannes.tschofenig@nsn.com> <4E1F6AAD24975D4BA5B1680429673943245A1D1F@TK5EX14MBXC207.redmond.corp.microsoft.com>
In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943245A1D1F@TK5EX14MBXC207.redmond.corp.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [OAUTH-WG] So back to use cases? (was RE: Call for Consensus on Document Split)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Oct 2010 18:09:17 -0000

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.freeman@hp.com
Desk in Palo Alto: (650) 857-2581
Home: (408) 774-1298
Cell: (408) 348-7536


-----Original Message-----
From: oauth-bounces@ietf.org [mailto:oauth-bounces@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-bounces@ietf.org [mailto:oauth-bounces@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" <romeda@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