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

Eran Hammer-Lahav <eran@hueniverse.com> Wed, 29 September 2010 14:50 UTC

Return-Path: <eran@hueniverse.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 098A23A6B5E for <oauth@core3.amsl.com>; Wed, 29 Sep 2010 07:50:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.498
X-Spam-Level:
X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599]
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 JymXaA+K5SDC for <oauth@core3.amsl.com>; Wed, 29 Sep 2010 07:50:06 -0700 (PDT)
Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 8AD8C3A6DB4 for <oauth@ietf.org>; Wed, 29 Sep 2010 07:50:06 -0700 (PDT)
Received: (qmail 23235 invoked from network); 29 Sep 2010 14:50:49 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 29 Sep 2010 14:50:49 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 29 Sep 2010 07:50:46 -0700
From: Eran Hammer-Lahav <eran@hueniverse.com>
To: Mark Mcgloin <mark.mcgloin@ie.ibm.com>, Dick Hardt <dick.hardt@gmail.com>
Date: Wed, 29 Sep 2010 07:50:33 -0700
Thread-Topic: [OAUTH-WG] Looking for a compromise on signatures and other open issues
Thread-Index: Actfq8T8wbWYAxGUSmyg3mad0moIeAAN0taQ
Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343D460DB941@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <90C41DD21FB7C64BB94121FBBC2E72343D460DB5BE@P3PW5EX1MB01.EX1.SECURESERVER.NET> <BE4113B3-D849-4BA1-B8FC-975C636D1303@gmail.com> <OF4576070A.5F974BC0-ON802577AD.002AB50B-802577AD.002B9415@ie.ibm.com>
In-Reply-To: <OF4576070A.5F974BC0-ON802577AD.002AB50B-802577AD.002B9415@ie.ibm.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
Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org>, "oauth-bounces@ietf.org" <oauth-bounces@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: Wed, 29 Sep 2010 14:50:18 -0000

> -----Original Message-----
> From: Mark Mcgloin [mailto:mark.mcgloin@ie.ibm.com]
> Sent: Wednesday, September 29, 2010 12:55 AM

> I echo Dick's sentiment, mildly
> 
> -1 to splitting acquiring and using a token. It may not confuse people actively
> engaged in the WG but what about everyone else?

We are already splitting it, by putting signatures elsewhere. Just because you might think bearer tokens are the 'obvious choice' and signatures are the 'optional more advance choice', you are still splitting the protocol over multiple parts. It is just that your preferred way of splitting it is optimized to what you care most about. I have made the same argument about the readability of the specification without signatures in core and was shut down because it will delay the work too much and other reasons.

> Also, as Torsten and I look at security considerations, I wonder if there are
> some examples that link the threat model for acquiring a token and using a
> token.  So:
> 
> 1) Will the decisions a service provider make when granting a token depend
> on, or affect, the use case for using that token?
> 2) Will the use case, grant type or other flow parameters a client selects for
> acquiring a token, depend on how they will use that token?
> 
> I don't have concrete examples to back this up but possibilities include:
> automatic granting of access token, refresh tokens, non-secure channels, ??

This is possible, but there is absolutely no benefit from the way the draft is structured today. If you strive to offer a complete and comprehensive solution and security review, you clearly have to include signatures in the same document. How would you discuss these examples and dependencies without the full picture? IOW, how is including bearer token but not other alternatives make answering these questions in the core specification any easier? Why is it any less useful to discuss these questions in each of the token authentication schemes? After all, it is the nature of the scheme that dictates everything else.

This argument is valid but has nothing to do with moving section 5 out.

This leaves readability as the only potential argument against splitting. Why not try it out? What's the worse that will happen? We have to put it back in and look for a different compromise?

And last, if you are going to opposed this proposal, then the burden is on you to offer an alternative that is going to address the concerns and parameters presented in my original post. By definition, a compromise means you don't get everything you want, so what are you willing to give up to help resolve these otherwise blocking issues? I am not trying to tease anyone, but asking an sincere question. Every other proposal has been rejected with sufficient resistance to suggest it will not last through the multiple review stages.

EHL