IETF Logo Mail Archive

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

Nat <sakimura@gmail.com> Fri, 16 July 2010 00:09 UTC

Return-Path: <sakimura@gmail.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 9CC273A6893 for <oauth@core3.amsl.com>; Thu, 15 Jul 2010 17:09:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.203
X-Spam-Level:
X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396]
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 x7gFlI7K0xcI for <oauth@core3.amsl.com>; Thu, 15 Jul 2010 17:09:49 -0700 (PDT)
Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 6AC553A67EE for <oauth@ietf.org>; Thu, 15 Jul 2010 17:09:49 -0700 (PDT)
Received: by pwj1 with SMTP id 1so739828pwj.31 for <oauth@ietf.org>; Thu, 15 Jul 2010 17:09:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:references:in-reply-to :mime-version:content-transfer-encoding:content-type:message-id:cc :x-mailer:from:subject:date:to; bh=5qS/xNYUg6imFYQwcHzZibmgtECniJl2WiuUpJc20OU=; b=SuTpbCkiLzLnldM+7zSBnyx3vc8qu29ts/bJIzQRNzcaTWTROBr6mp2u+nBbMqdILV BXHNTtEXc6ebrwb9ulXdCSV4f9/OMbfRnzzJ79LrFqCB9IREmfWeWGvL0dTPcSyCy1SX Ww6UuCi6tZQu1ZzqDM4N7EREVafXPoXCOtqlc=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; b=ppw6/lESlojNSpNABO0CLUco9XhCMrJ97PaH2h4FsVR3uoCamW+UzpXlgYo1vtCQFE DmB1GQF0ucDbw163ITsEhdxkrxRUCPqM9DP7U0vS/a7TfqX0gGdbE+h7tyS4c1ac4Ue1 /uDvSZpJL4J/7FQbwpaqC4R8BafQFED/yqNS8=
Received: by 10.114.39.7 with SMTP id m7mr337838wam.92.1279238997298; Thu, 15 Jul 2010 17:09:57 -0700 (PDT)
Received: from [126.251.161.250] (pw126251161250.11.tss.panda-world.ne.jp [126.251.161.250]) by mx.google.com with ESMTPS id x9sm12236909waj.15.2010.07.15.17.09.52 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 15 Jul 2010 17:09:54 -0700 (PDT)
References: <AANLkTimcEk_sweiG0unTWegnbJNh4IkkMNiM65GGslvS@mail.gmail.com> <C861D023.37150%eran@hueniverse.com> <AANLkTilZsj2V4zAxD0Fv54JgW23tNLM6TeWdfZLVRozH@mail.gmail.com>
In-Reply-To: <AANLkTilZsj2V4zAxD0Fv54JgW23tNLM6TeWdfZLVRozH@mail.gmail.com>
Mime-Version: 1.0 (iPhone Mail 8A293)
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="us-ascii"
Message-Id: <99AAAB32-624D-4C33-A9D4-D0A6A6F643FC@gmail.com>
X-Mailer: iPhone Mail (8A293)
From: Nat <sakimura@gmail.com>
Date: Fri, 16 Jul 2010 09:10:18 +0900
To: Brian Eaton <beaton@google.com>
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: Fri, 16 Jul 2010 00:09:53 -0000

As I see, the current draft is half way towards the complete modularization. It has abstracted what parameters are needed for each end points from various flows but failed to stop there and included how they are to be passed as well. IMHO, how they are passed is the profile/binding issue and all these language should be removed and moved to profile specs. 

=nat @ Tokyo via iPhone

On 2010/07/15, at 14:32, Brian Eaton <beaton@google.com> wrote:

> 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
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

v2.37.1 | Report a Bug | By Email | System Status