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

Dick Hardt <dick.hardt@gmail.com> Thu, 30 September 2010 14:44 UTC

Return-Path: <dick.hardt@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 194F93A6A9B for <oauth@core3.amsl.com>; Thu, 30 Sep 2010 07:44:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.51
X-Spam-Level:
X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, 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 bztCWRh42Qey for <oauth@core3.amsl.com>; Thu, 30 Sep 2010 07:44:49 -0700 (PDT)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id A57C63A6918 for <oauth@ietf.org>; Thu, 30 Sep 2010 07:44:49 -0700 (PDT)
Received: by ywk9 with SMTP id 9so823755ywk.31 for <oauth@ietf.org>; Thu, 30 Sep 2010 07:45:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:message-id:references:to :x-mailer; bh=B+5uYW+CCcEzU2xWP419aCs3toeClvowMFiX6zeAX+k=; b=kTZ6FhWktTJRPIiwf/CdynjkmhNfCCMyImVaSgYp5uvyJ6rhcl2ff58HBxvwlc9ZtI c2eVXRvDS3way48LU3IOo8w1WhuIdqVZnbvFeos0GXZiRlLOVR4pv2MrrpURfcbonX6q MlAk9mlALaQuwkzxPzGReMbEsz0+/OTQnjqGk=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; b=yA1nXh1Jws7qfrvhr9TZZtxNOkwqTo3OVkRK0A1yXTTnw+kPRBthPsozZ7VdQsqYT+ h9L5JYGYpFICFsrvPkt9b1GURhbhjj7FlaqzTziiLofsmQD8IBqfPv+/Ec/nGVMV7E/3 QYPrVZ/E/NM/9OLK1A8aD0i69o7jSshoV5PCE=
Received: by 10.224.54.140 with SMTP id q12mr2560436qag.139.1285857934383; Thu, 30 Sep 2010 07:45:34 -0700 (PDT)
Received: from [192.168.1.5] ([24.130.32.55]) by mx.google.com with ESMTPS id t18sm10988595qco.8.2010.09.30.07.45.31 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 30 Sep 2010 07:45:32 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: multipart/alternative; boundary=Apple-Mail-38-460567962
From: Dick Hardt <dick.hardt@gmail.com>
In-Reply-To: <AANLkTimDa0aZFgxuOczV9GJEF2EXOV4DSr6BK7mKAoqA@mail.gmail.com>
Date: Thu, 30 Sep 2010 07:45:29 -0700
Message-Id: <410FEF9C-CE06-4B08-A053-3D87C454D759@gmail.com>
References: <90C41DD21FB7C64BB94121FBBC2E72343D460DB5BE@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTimDa0aZFgxuOczV9GJEF2EXOV4DSr6BK7mKAoqA@mail.gmail.com>
To: Lukas Rosenstock <lr@lukasrosenstock.net>
X-Mailer: Apple Mail (2.1081)
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 14:44:51 -0000

Note there will be three documents not two.

The suggested change does not address the issue that myself and others had raised with having signatures be in the core. The suggestion was that having signatures be a different spec made them reusable by other groups and enabled a more comprehensive signature specification. Having them in core made them OAuth specific.

I think there was consensus with those that had seen the advantage of a different signature spec that including the OAuth 1.0A signature mechanism in core and having a clear extension mechanism was a satisfactory direction. This enables alternative algorithms to be specified

From what I have gathered, the only advantage to breaking it up is participants can "ignore" bearer tokens or signatures if they don't "value" one of those mechanisms. Personally, I think it is important that we all respect the various use cases rather than push one mechanism under the rug because it is not important to us. From what I understand of IETF process, we are striving for rough consensus. If there is not consensus that both bearer tokens and signatures are important, then the I think we need to have a break through in that issue rather than breaking up the document.

As I have reflected on this proposal, I am now a strong -1 for the following reason:

Deep understanding of the full flow and security implications of the full flow is critical to a successful implementation and deployment. As Eran keeps pointing out, understanding the security implications of bearer tokens (and conversely, of using signatures) is a critical security decision. Breaking the document up implies to the reader that not all sections need to be read. If they are not all read, then the reader will not have a complete understanding of the protocol, and hence not a complete understanding of the security implications.

-- Dick

On 2010-09-30, at 2:23 AM, Lukas Rosenstock wrote:

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