IETF Logo Mail Archive

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

Eran Hammer-Lahav <eran@hueniverse.com> Wed, 29 September 2010 15:36 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 9E6463A6D16 for <oauth@core3.amsl.com>; Wed, 29 Sep 2010 08:36:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.499
X-Spam-Level:
X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 BlTs+6us8kr2 for <oauth@core3.amsl.com>; Wed, 29 Sep 2010 08:36:49 -0700 (PDT)
Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 2CA0B3A6D00 for <oauth@ietf.org>; Wed, 29 Sep 2010 08:36:49 -0700 (PDT)
Received: (qmail 4337 invoked from network); 29 Sep 2010 15:37:32 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 29 Sep 2010 15:37:32 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Wed, 29 Sep 2010 08:37:30 -0700
From: Eran Hammer-Lahav <eran@hueniverse.com>
To: Mark Mcgloin <mark.mcgloin@ie.ibm.com>
Date: Wed, 29 Sep 2010 08:37:17 -0700
Thread-Topic: [OAUTH-WG] Looking for a compromise on signatures and other open issues
Thread-Index: Actf6xAX2KvfjTfnS+ev1OlFEd/d9gAABgJg
Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343D460DB978@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> <90C41DD21FB7C64BB94121FBBC2E72343D460DB941@P3PW5EX1MB01.EX1.SECURESERVER.NET> <OF142A94C3.963BF481-ON802577AD.0052B3D8-802577AD.005502A3@ie.ibm.com>
In-Reply-To: <OF142A94C3.963BF481-ON802577AD.0052B3D8-802577AD.005502A3@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>
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 15:36:54 -0000

Thanks Mark.

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

> I think acquiring and using a token can be considered core as you always
> need both. I don't have valid security consideration linkage between
> acquiring and using the token to back up my assertion that it may confuse
> developers if we separate them (yet)

Just to be clear, the 'core' designation is completely virtual. No specification will say 'core' in it or position itself as more authoritative than others. OAuth is already a modular protocol with its different profiles and use cases. We have been using this term to talk about the primary document, but with this proposal it is no longer a useful term.

I think that positioning the OAuth name as the 'protocol for exchanging one set of credentials for an access token via HTTP' is useful. What happens next is not always strictly OAuth. This is especially true when the token is used with new or existing schemes that are outside the scope of this working group.

EHL

v2.23.0 | Report a Bug | By Email