Return-Path: 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 C4B1B3A6B6C for ; Mon, 27 Sep 2010 09:36:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.25 X-Spam-Level: X-Spam-Status: No, score=-10.25 tagged_above=-999 required=5 tests=[AWL=0.348, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 P4JUH2Bd1v3c for ; Mon, 27 Sep 2010 09:36:05 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id AD4BB3A6B5A for ; Mon, 27 Sep 2010 09:36:04 -0700 (PDT) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 27 Sep 2010 09:36:44 -0700 Received: from TK5EX14MBXC207.redmond.corp.microsoft.com ([169.254.7.160]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.01.0218.012; Mon, 27 Sep 2010 09:36:43 -0700 From: Mike Jones To: Eran Hammer-Lahav , "OAuth WG (oauth@ietf.org)" Thread-Topic: Proposal: OAuth 1.0 signature in core with revision Thread-Index: ActeDoaUK2WoVUKmSgyhimH2rZiaMgAU1jaQ Date: Mon, 27 Sep 2010 16:36:42 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394314AA07A6@TK5EX14MBXC207.redmond.corp.microsoft.com> References: <90C41DD21FB7C64BB94121FBBC2E72343D45D80139@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343D45D80139@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394314AA07A6TK5EX14MBXC207r_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Proposal: OAuth 1.0 signature in core with revision X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Sep 2010 16:36:10 -0000 --_000_4E1F6AAD24975D4BA5B168042967394314AA07A6TK5EX14MBXC207r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Since you were asking for votes earlier, I'll add a -1. I believe the indu= stry would be better served by approving a draft soon without signatures, a= nd then working on signatures separately. -- Mike From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of E= ran Hammer-Lahav Sent: Sunday, September 26, 2010 11:44 PM To: OAuth WG (oauth@ietf.org) Subject: [OAUTH-WG] Proposal: OAuth 1.0 signature in core with revision Building on John Panzer's proposal, I would like to ask if people have stro= ng objections to the following: - Add the 1.0a RFC language for HMAC-SHA-1 signatures to the core specifica= tion in -11 - Discuss the signature language on the list and improve both prose and sig= nature base string construction - Apply improvements to -12 Keeping the 1.0a signature in the core specification makes sense and builds= on existing experience and deployment. If we can reach quick consensus on = some improvements, great. If not, we satisfy the need of many here to offer= a simple alternative to bearer tokens, without having to reach consensus o= n a new signature algorithm suitable for core inclusion. --- I have seen nothing to suggest that this working group is going to reach co= nsensus on a single signature algorithm worthy of core inclusion. I agree w= ith John that at least the 1.0a algorithm is well understood and already de= ployed. I can live with it used without changes, which will also allow reus= ing existing code with 2.0. I think we can improve it by making small chang= es, but have better things to do with my time than spend the next few month= s arguing over it. By including the 1.0a text in -11, we will have a feature complete specific= ation that I hope many people here can live with if it doesn't change (whic= h looks more likely). My question is, who here has strong objections to this, and cannot live wit= h the core specification including the 1.0a HMAC-SHA1 algorithm? EHL --_000_4E1F6AAD24975D4BA5B168042967394314AA07A6TK5EX14MBXC207r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Since you were asking = for votes earlier, I’ll add a -1.  I believe the industry would = be better served by approving a draft soon without signatures, and then wor= king on signatures separately.

 

   &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;      -- Mike

 

From: oauth-bo= unces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Eran Hammer-Lahav
Sent: Sunday, September 26, 2010 11:44 PM
To: OAuth WG (oauth@ietf.org)
Subject: [OAUTH-WG] Proposal: OAuth 1.0 signature in core with revis= ion

 

Building on John Panzer’s proposal, I would li= ke to ask if people have strong objections to the following:

 

- Add the 1.0a RFC language for HMAC-SHA-1 signature= s to the core specification in -11

- Discuss the signature language on the list and imp= rove both prose and signature base string construction

- Apply improvements to -12

 

Keeping the 1.0a signature in the core specification= makes sense and builds on existing experience and deployment. If we can re= ach quick consensus on some improvements, great. If not, we satisfy the nee= d of many here to offer a simple alternative to bearer tokens, without having to reach consensus on a new signature alg= orithm suitable for core inclusion.

 

---

 

I have seen nothing to suggest that this working gro= up is going to reach consensus on a single signature algorithm worthy of co= re inclusion. I agree with John that at least the 1.0a algorithm is well un= derstood and already deployed. I can live with it used without changes, which will also allow reusing existing = code with 2.0. I think we can improve it by making small changes, but have = better things to do with my time than spend the next few months arguing ove= r it.

 

By including the 1.0a text in -11, we will have a fe= ature complete specification that I hope many people here can live with if = it doesn’t change (which looks more likely).

 

My question is, who here has strong objections to th= is, and cannot live with the core specification including the 1.0a HMAC-SHA= 1 algorithm?

 

EHL

--_000_4E1F6AAD24975D4BA5B168042967394314AA07A6TK5EX14MBXC207r_--