Re: [OAUTH-WG] Looking for a compromise on signatures and other open issues

Lukas Rosenstock <lr@lukasrosenstock.net> Thu, 30 September 2010 09:22 UTC

Return-Path: <lr@lukasrosenstock.net>
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 E406A3A69F6 for <oauth@core3.amsl.com>; Thu, 30 Sep 2010 02:22:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.528
X-Spam-Level:
X-Spam-Status: No, score=-1.528 tagged_above=-999 required=5 tests=[AWL=0.448, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
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 kwJgCXLtxETR for <oauth@core3.amsl.com>; Thu, 30 Sep 2010 02:22:22 -0700 (PDT)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id EE9553A6BD4 for <oauth@ietf.org>; Thu, 30 Sep 2010 02:22:21 -0700 (PDT)
Received: by yxl31 with SMTP id 31so767920yxl.31 for <oauth@ietf.org>; Thu, 30 Sep 2010 02:23:06 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.224.6.136 with SMTP id 8mr2329912qaz.149.1285838586613; Thu, 30 Sep 2010 02:23:06 -0700 (PDT)
Received: by 10.229.221.9 with HTTP; Thu, 30 Sep 2010 02:23:00 -0700 (PDT)
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343D460DB5BE@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <90C41DD21FB7C64BB94121FBBC2E72343D460DB5BE@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Date: Thu, 30 Sep 2010 11:23:00 +0200
Message-ID: <AANLkTimDa0aZFgxuOczV9GJEF2EXOV4DSr6BK7mKAoqA@mail.gmail.com>
From: Lukas Rosenstock <lr@lukasrosenstock.net>
To: Eran Hammer-Lahav <eran@hueniverse.com>
Content-Type: multipart/alternative; boundary=0015175ce0c6318fe9049176a001
Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Looking for a compromise on signatures and other open issues
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, 30 Sep 2010 09:22:24 -0000

+1

While it's good to have one document, it's better to have two good documents
instead of one that we're unhappy with.

There'll be "Implementer's Guides" and "Tutorials" later who will do the job
of explaining how to make sense of the two (which of course doesn't mean I'm
advocating specifications which are hard to understand without other
material).

2010/9/28 Eran Hammer-Lahav <eran@hueniverse.com>

> 1. Add a parameter to the token response to include an extensible token
> scheme.
>
>
>
> The default (if omitted) will be whatever the bearer token scheme is
> called. This will allow the authorization server to return any token type it
> deems appropriate, and for other specifications to define additional
> parameters such as token_secret. Others can extend the token request
> endpoint by allow the client to request a specific token scheme.
>
>
>
> 2. Break the core specification into multiple parts.
>
>
>
> Go back to the original working group consensus to break the document into
> two parts: getting a token and using a token. Getting a token will include
> everything from core expect for section 5. Section 5 will become a new
> specification which will describe how to use a bearer token (replacing the
> generic ‘OAuth’ scheme with something more descriptive like).
>
>
>
> 3. Introduce two signature proposals in one or more documents, for the JSON
> token and 1.0a-like method.
>
>
>
> One, both, or none can become working group item.
>