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 6D7313A67A5 for ; Mon, 27 Sep 2010 21:47:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.264 X-Spam-Level: X-Spam-Status: No, score=-10.264 tagged_above=-999 required=5 tests=[AWL=0.334, 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 QmAKaB9a6NrR for ; Mon, 27 Sep 2010 21:47:43 -0700 (PDT) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 0F0033A6C1F for ; Mon, 27 Sep 2010 21:47:43 -0700 (PDT) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 27 Sep 2010 21:48:23 -0700 Received: from TK5EX14MBXC101.redmond.corp.microsoft.com ([169.254.1.145]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.01.0218.012; Mon, 27 Sep 2010 21:48:23 -0700 From: Anthony Nadalin To: Eran Hammer-Lahav , "OAuth WG (oauth@ietf.org)" Thread-Topic: Proposal: OAuth 1.0 signature in core with revision Thread-Index: ActeDoaUK2WoVUKmSgyhimH2rZiaMgAfVOewAA758JAAABvDEA== Date: Tue, 28 Sep 2010 04:48:22 +0000 Message-ID: <1990A18DEA6E97429CFD1B4D2C5DA7E70D103A@TK5EX14MBXC101.redmond.corp.microsoft.com> References: <90C41DD21FB7C64BB94121FBBC2E72343D45D80139@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1990A18DEA6E97429CFD1B4D2C5DA7E70CEB7D@TK5EX14MBXC101.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E72343D460DB5B5@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343D460DB5B5@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_1990A18DEA6E97429CFD1B4D2C5DA7E70D103ATK5EX14MBXC101red_" 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: Tue, 28 Sep 2010 04:47:49 -0000 --_000_1990A18DEA6E97429CFD1B4D2C5DA7E70D103ATK5EX14MBXC101red_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Still no real answers ... From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] Sent: Monday, September 27, 2010 9:46 PM To: Anthony Nadalin; OAuth WG (oauth@ietf.org) Subject: RE: Proposal: OAuth 1.0 signature in core with revision You must be joking about 1.0a signature deployment. It's also nice that hal= f a day is your measurement for obtaining consensus. EHL From: Anthony Nadalin [mailto:tonynad@microsoft.com] Sent: Monday, September 27, 2010 2:38 PM To: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org) Subject: RE: Proposal: OAuth 1.0 signature in core with revision Not seeing an overwhelming support for doing this, how many interoperable d= eployments of 1.0a signature are there? 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_1990A18DEA6E97429CFD1B4D2C5DA7E70D103ATK5EX14MBXC101red_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Still no real answers = …

 

From: Eran Ham= mer-Lahav [mailto:eran@hueniverse.com]
Sent: Monday, September 27, 2010 9:46 PM
To: Anthony Nadalin; OAuth WG (oauth@ietf.org)
Subject: RE: Proposal: OAuth 1.0 signature in core with revision

 

You must be joking abo= ut 1.0a signature deployment. It’s also nice that half a day is your = measurement for obtaining consensus.

 

EHL<= /p>

 

 

From: Anthony = Nadalin [mailto:tonynad@microsoft.com]
Sent: Monday, September 27, 2010 2:38 PM
To: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org)
Subject: RE: Proposal: OAuth 1.0 signature in core with revision

 

Not seeing an overwhel= ming support for doing this, how many interoperable deployments of 1.0a sig= nature are there?

 

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_1990A18DEA6E97429CFD1B4D2C5DA7E70D103ATK5EX14MBXC101red_--