Re: [OAUTH-WG] return to draft 6 spec org?

Brian Eaton <beaton@google.com> Thu, 15 July 2010 05:32 UTC

Return-Path: <beaton@google.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 9BF593A6A0E for <oauth@core3.amsl.com>; Wed, 14 Jul 2010 22:32:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.789
X-Spam-Level:
X-Spam-Status: No, score=-105.789 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 LiKIp3uJAQvd for <oauth@core3.amsl.com>; Wed, 14 Jul 2010 22:32:00 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id BF47C3A6A58 for <oauth@ietf.org>; Wed, 14 Jul 2010 22:31:58 -0700 (PDT)
Received: from wpaz21.hot.corp.google.com (wpaz21.hot.corp.google.com [172.24.198.85]) by smtp-out.google.com with ESMTP id o6F5W80Y012992 for <oauth@ietf.org>; Wed, 14 Jul 2010 22:32:08 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1279171928; bh=ER5BFXM1sHPVjAGzHcQHyKfpAkA=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=aeWSZx5eqAtmgglAdKVpACJhljZN62cheR0CA+yb+13GbJ4JclOeicINqfFXFI73k skAbKjg5hnV2lCQnqGNnw==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=hi9ASQizKqhGDitia0/zGvjaxHBgSv2MawqTYjwog3+8b0xvAvHkeO9IrhPd/4Rf7 djuoDztz2Pjxqk291vTcg==
Received: from pwj7 (pwj7.prod.google.com [10.241.219.71]) by wpaz21.hot.corp.google.com with ESMTP id o6F5W7xS013188 for <oauth@ietf.org>; Wed, 14 Jul 2010 22:32:07 -0700
Received: by pwj7 with SMTP id 7so172617pwj.36 for <oauth@ietf.org>; Wed, 14 Jul 2010 22:32:06 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.142.158.14 with SMTP id g14mr7543684wfe.93.1279171926797; Wed, 14 Jul 2010 22:32:06 -0700 (PDT)
Received: by 10.142.193.19 with HTTP; Wed, 14 Jul 2010 22:32:06 -0700 (PDT)
In-Reply-To: <C861D023.37150%eran@hueniverse.com>
References: <AANLkTimcEk_sweiG0unTWegnbJNh4IkkMNiM65GGslvS@mail.gmail.com> <C861D023.37150%eran@hueniverse.com>
Date: Wed, 14 Jul 2010 22:32:06 -0700
Message-ID: <AANLkTilZsj2V4zAxD0Fv54JgW23tNLM6TeWdfZLVRozH@mail.gmail.com>
From: Brian Eaton <beaton@google.com>
To: Eran Hammer-Lahav <eran@hueniverse.com>
Content-Type: text/plain; charset="ISO-8859-1"
X-System-Of-Record: true
Cc: OAuth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] return to draft 6 spec org?
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: Thu, 15 Jul 2010 05:32:02 -0000

On Tue, Jul 13, 2010 at 8:11 AM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
> - client credentials information was always problematic because people
> expressed interest in using it with pre-arranged authorizations, in which
> case, the client may be acting on behalf of an end-user.
...
> I suggested adding actual profiles to the spec, which would accomplish what
> your want to see "restored". However it is not clear to me how to name these
> and how to guide developers when to use them.
...

I've been giving some thought to this problem.

As far as I can tell, here is what has happened.

1) several people have gotten together and put together a
tightly-specified proposal to meet a particular use case
2) that's gotten added
3) others have chimed in with slight modifications to meet slightly
different use cases
4) that's gotten added
5) step 3 and 4 repeat for a while.
6) the detailed proposal written in step 1 and 2 has gotten screwed up

We haven't gotten to step 7 yet, but I'm pretty sure it involves
non-interoperable implementations.

I think the problem here is step 4.  Rather than making everything
optional so we can meet every possible use case, we need to start
telling people to go write up new profiles to meet their use cases.

Given the choice between two tightly specified protocol flows and a
single vague protocol flow, we should prefer tightly specified.

Cheers,
Brian