Re: [OAUTH-WG] draft-15 editorials
Paul Madsen <paul.madsen@gmail.com> Wed, 06 April 2011 15:13 UTC
Return-Path: <paul.madsen@gmail.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 206E828C122 for <oauth@core3.amsl.com>; Wed, 6 Apr 2011 08:13:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.198
X-Spam-Level:
X-Spam-Status: No, score=-3.198 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_LOW=-1]
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 Y2vBxWYQWfxa for <oauth@core3.amsl.com>; Wed, 6 Apr 2011 08:13:13 -0700 (PDT)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id AE54228C0DB for <oauth@ietf.org>; Wed, 6 Apr 2011 08:13:12 -0700 (PDT)
Received: by yxk30 with SMTP id 30so724631yxk.31 for <oauth@ietf.org>; Wed, 06 Apr 2011 08:14:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=oNCJ602ngx955X1/SzOm9zfNfawK6l48nQO/GyWwapY=; b=bQav8z5VmGfmvildp4c541qPm0rMywIVQSl7OiE8xQ/dNZroRANDDa1hg/GKDfAbKj EVYv1sThlxXRO/9zU0KijH48fQ0boTkAcoGe0+zrpxSX+vgnCpqJnr2HZO+54ms8DiPw ppDcTRhgxJ+2KmAotkgrE/4wxRv2/3rggup10=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; b=Uo2aiwxf6lV2pI67f/bp0Swn2tVgCqy5PaSZjE6acjC6xAJuIvjo5OcWussdR4sMky pyKM26bBa/R9Zjqoc8BiRlwYAianEk59mzeAVLtAYXYMKIZr4f422TpPj+dCFj7/rGTu oG30d1xWmhIcNv33h4EPfWsguXW8yjHq6ZS9s=
Received: by 10.91.102.5 with SMTP id e5mr1993198agm.157.1302102896219; Wed, 06 Apr 2011 08:14:56 -0700 (PDT)
Received: from pmadsen-mbp.local (CPE0022b0cb82b4-CM0012256eb4b4.cpe.net.cable.rogers.com [99.224.152.177]) by mx.google.com with ESMTPS id 23sm766209ano.7.2011.04.06.08.14.53 (version=SSLv3 cipher=OTHER); Wed, 06 Apr 2011 08:14:54 -0700 (PDT)
Message-ID: <4D9C836C.9080704@gmail.com>
Date: Wed, 06 Apr 2011 11:14:52 -0400
From: Paul Madsen <paul.madsen@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9
MIME-Version: 1.0
To: Eran Hammer-Lahav <eran@hueniverse.com>
References: <255B9BB34FB7D647A506DC292726F6E11281BA9188@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B1680429673943252CE4F8@TK5EX14MBXC203.redmond.corp.microsoft.com> <4D9C47A8.30605@gmail.com> <90C41DD21FB7C64BB94121FBBC2E7234465664DF8F@P3PW5EX1MB01.EX1.SECURESERVER.NET>
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234465664DF8F@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Content-Type: multipart/alternative; boundary="------------030706080602090104010304"
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] draft-15 editorials
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, 06 Apr 2011 15:13:22 -0000
Proposed text The OAuth 2.0 authorization protocol enables a third-party applicationto obtain limited access to an HTTP service, either on behalf of an end-user by orchestrating an approval interaction between the end-user and the HTTP service, or by allowing the third-party application to directly 'negotiate', on its own behalf,such access with the HTTP service. And I acknowledge the concerns that 'negotiate' might create, thus the air quotes .... paul On 4/6/11 10:36 AM, Eran Hammer-Lahav wrote: > > Can you propose text? > > EHL > > *From:*oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On > Behalf Of *Paul Madsen > *Sent:* Wednesday, April 06, 2011 4:00 AM > *To:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] draft-15 editorials > > Can we not acknowledge in the abstract that there are other > applications for OAuth beyond the delegated authz scenario? > > I tell people that OAuth 2 is more a framework than a specific > protocol, but the current abstract belies this claim. > > paul > > On 4/5/11 8:57 PM, Mike Jones wrote: > > Also, change "which in turns directs" to "which in turn directs". > > -- Mike > > *From:*oauth-bounces@ietf.org <mailto:oauth-bounces@ietf.org> > [mailto:oauth-bounces@ietf.org] *On Behalf Of *Manger, James H > *Sent:* Tuesday, April 05, 2011 5:51 PM > *To:* oauth@ietf.org <mailto:oauth@ietf.org> > *Subject:* [OAUTH-WG] draft-15 editorials > > A few, mainly editorial, points on the latest OAuth 2.0 core draft > [draft-ietf-oauth-v2-15]: > > *Abstract*: Currently it is: > > The OAuth 2.0 authorization protocol enables granting third-party > > applications limited access to HTTP service on behalf of an end-user > > by orchestrating an approval interaction between the end-user and the > > HTTP service. > > This sentence is confusing as to whom is doing the orchestrating. It > is an important OAuth feature that the 3rd-party app does this. Also > add "an" before "HTTP service". > > The OAuth 2.0 authorization protocol enables a third-party application > > to obtain limited access to an HTTP service on behalf of an end-user > > by orchestrating an approval interaction between the end-user and the > > HTTP service. > > *2.1 Authorization Endpoints* > > ...when sending requests to the token endpoints > > should be > > ...when sending requests to the authorization endpoint > > *7.1 Access Token Types* > > I suggest adding the following sentence to the end of the 1^st > paragraph, just to be sure a security value is not used in the wrong > protocol. > > A client MUST NOT use an access token if it does not understand the > token type. > > *7.1 Access Token Types* > > Use a different access token for the Bearer and MAC examples to avoid > any implication that a given token can be used with either method at > the client's discretion. Perhaps make the example Bearer token a bit > longer. The current example value has at most 72 bits of entropy that > doesn't match the 128-bits required in > draft-lodderstedt-oauth-security-01#section-5.1.4.2.2. > > Authorization: Bearer 7Fjfp0ZBr1KtDRbnfVdmIw > > *7.1 Access Token Types* > > The timestamp value in the MAC example corresponds to a date in 1974! > > -- > > James Manger > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth
- [OAUTH-WG] draft-15 editorials Manger, James H
- Re: [OAUTH-WG] draft-15 editorials Mike Jones
- Re: [OAUTH-WG] draft-15 editorials Paul Madsen
- Re: [OAUTH-WG] draft-15 editorials Eran Hammer-Lahav
- Re: [OAUTH-WG] draft-15 editorials Eran Hammer-Lahav
- Re: [OAUTH-WG] draft-15 editorials Paul Madsen
- Re: [OAUTH-WG] draft-15 editorials Manger, James H
- Re: [OAUTH-WG] draft-15 editorials Paul Madsen