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 51AC83A6AFF for ; Mon, 27 Sep 2010 06:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.483 X-Spam-Level: X-Spam-Status: No, score=-2.483 tagged_above=-999 required=5 tests=[AWL=0.115, 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 cFrzOhnLPdLz for ; Mon, 27 Sep 2010 06:45:55 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 38CFF3A69AB for ; Mon, 27 Sep 2010 06:45:44 -0700 (PDT) Received: by pwi3 with SMTP id 3so750183pwi.31 for ; Mon, 27 Sep 2010 06:46:23 -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=ma6Oc3olNxOlTTZ3+AnxGO733LONvsoYqqsubmdAs28=; b=BBycMxh1mWeMnYaw7U2pG6DlhDBc59X9COgomVE8VF1KzbzTxTxJh+DhnBCV5Tyx7f 3P6X1jDNFZCMnHKn+AZJAbhZAoH1BPw2Emn1mR9OSjqrLbr9D1fn6Q0NT2f9bvtsJQVa D6eSj1lNxZxegZzmHFQ14kf/2mX90BhjBouxQ= 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=wOK82UgGAzY/Zp4BeOg7ffJPTcYYz3R3K2CzAG9yMKBKK81QSFCCClSTj/5Ek1ujCM jmXquPv4VLvZbwjbxQIbGf6Gfz9WnSBVngxny4xQFC8Si8J1lqoASzxx49yBy861BZLq wfMf/bJQzXUvJeWaK7ianyiAQY4Lf7xCkFTV4= Received: by 10.142.141.12 with SMTP id o12mr6429649wfd.280.1285595183150; Mon, 27 Sep 2010 06:46:23 -0700 (PDT) Received: from [192.168.1.5] ([24.130.32.55]) by mx.google.com with ESMTPS id v6sm7435200wfg.3.2010.09.27.06.46.20 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 27 Sep 2010 06:46:21 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/alternative; boundary=Apple-Mail-10-197817044 From: Dick Hardt In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343D45D80139@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Mon, 27 Sep 2010 06:46:18 -0700 Message-Id: <7BEE5493-C73B-4655-96F4-A3BB9ACC872B@gmail.com> References: <90C41DD21FB7C64BB94121FBBC2E72343D45D80139@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1081) Cc: "OAuth WG \(oauth@ietf.org\)" 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 13:46:07 -0000 --Apple-Mail-10-197817044 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 As others have stated and I agree with, you also need an extension = mechanism so that other signature algorithms can be used. If there is no = extension mechanism, then the spec is saying this is the only signature = mechanism possible. -- Dick On 2010-09-26, at 11:44 PM, Eran Hammer-Lahav wrote: > Building on John Panzer=92s proposal, I would like to ask if people = have strong objections to the following: > =20 > - Add the 1.0a RFC language for HMAC-SHA-1 signatures to the core = specification in -11 > - Discuss the signature language on the list and improve both prose = and signature base string construction > - Apply improvements to -12 > =20 > 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 on a new signature algorithm suitable for core = inclusion. > =20 > --- > =20 > I have seen nothing to suggest that this working group is going to = reach consensus on a single signature algorithm worthy of core = inclusion. I agree with John that at least the 1.0a algorithm is well = understood 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 over it. > =20 > By including the 1.0a text in -11, we will have a feature complete = specification that I hope many people here can live with if it doesn=92t = change (which looks more likely). > =20 > My question is, who here has strong objections to this, and cannot = live with the core specification including the 1.0a HMAC-SHA1 algorithm? > =20 > EHL > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-10-197817044 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 As others have stated and I agree with, you also = need an extension mechanism so that other signature algorithms can be = used. If there is no extension mechanism, then the spec is saying this = is the only signature mechanism possible.

-- = Dick

On 2010-09-26, at 11:44 PM, Eran = Hammer-Lahav wrote:

Building on John Panzer=92s = proposal, I would like to ask if people have strong objections to the = following:
 
- = Add the 1.0a RFC language for HMAC-SHA-1 signatures to the core = specification in -11
- Discuss the signature = language on the list and improve 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 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 = on a new signature algorithm suitable for core = inclusion.
 
 
I have seen nothing = to suggest that this working group is going to reach consensus on a = single signature algorithm worthy of core inclusion. I agree with John = that at least the 1.0a algorithm is well understood 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 over it.
By including the 1.0a text in -11, = we will have a feature complete specification that I hope many people = here can live with if it doesn=92t change (which looks more = likely).