Re: [OAUTH-WG] draft-ietf-oauth-v2

Dick Hardt <dick.hardt@gmail.com> Tue, 17 July 2012 22:08 UTC

Return-Path: <dick.hardt@gmail.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E21E21F851B for <oauth@ietfa.amsl.com>; Tue, 17 Jul 2012 15:08:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.552
X-Spam-Level:
X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X3d02RX5OYLS for <oauth@ietfa.amsl.com>; Tue, 17 Jul 2012 15:08:30 -0700 (PDT)
Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7203F21F851A for <oauth@ietf.org>; Tue, 17 Jul 2012 15:08:30 -0700 (PDT)
Received: by pbcwy7 with SMTP id wy7so1504203pbc.31 for <oauth@ietf.org>; Tue, 17 Jul 2012 15:09:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=kXxA/ZFD5HR0O9g9TsQXV9vgD6kbHlgwZ+wxHTtWZ8s=; b=wZEfigxlfo10vb+DzfKAcv4n25lcxLhz/M4aWYvRREHhAq2yo1XxTtW+Lxb2/mxuf8 qnIpYW4agPN5ZHruNpwuOKCWBD5ApP+R8CKzW3iRD7OuOYDHFWBkSY+UaK7MrW4b9D5P AU0376OSDlkM6VIrrTQMDCWpBQMe3h3AqG9fc3P/O5iLiGDBPX8yqizLa6roNZEmVjhI 2mKxrahbs1Mz3kapeLyh7dB7RVzOASEghRzugNmThdLOJi65fhVSRDpl0QnHA+yWtIi5 WNsmHZAvrvKYgW10NYPMHbNHXVqtA7LjPp6F4rJ9ebRzNg1/r2Scwh+FYyQDXjhYBqQT nt6Q==
Received: by 10.68.134.201 with SMTP id pm9mr2164735pbb.49.1342562959022; Tue, 17 Jul 2012 15:09:19 -0700 (PDT)
Received: from [10.0.0.4] (c-24-5-69-173.hsd1.ca.comcast.net. [24.5.69.173]) by mx.google.com with ESMTPS id ku7sm14793917pbc.31.2012.07.17.15.09.15 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 17 Jul 2012 15:09:16 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1278)
Content-Type: text/plain; charset="iso-8859-1"
From: Dick Hardt <dick.hardt@gmail.com>
In-Reply-To: <CA+NzUBvPO4jVLqdzNXF8MQXZew262G3Ashs-vvqF2pAbh8bukg@mail.gmail.com>
Date: Tue, 17 Jul 2012 15:09:14 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <6C34F5DD-9CA7-40B0-B2DE-FB5E0A0D94D4@gmail.com>
References: <CA+NzUBvPO4jVLqdzNXF8MQXZew262G3Ashs-vvqF2pAbh8bukg@mail.gmail.com>
To: Michael Scalia <michael.scalia@gmail.com>
X-Mailer: Apple Mail (2.1278)
Cc: "oauth@ietf.org WG" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Tue, 17 Jul 2012 22:08:31 -0000

Thanks for the feedback Michael.

4.1.2 is where the authorization code is first talked about, and it makes sense to discuss how it is generated and used at that point. I can see how it might also be useful to put it in 4.1.3. Note that this is this is RECOMMENDED as opposed to MUST so it does not flow into "The authorization server MUST" list of points.

Personally, I don't see a need to change. Anyone else have an opinion on this?

-- Dick

On Jul 17, 2012, at 2:22 PM, Michael Scalia wrote:

> Dear OAuth Authors,
> 
> I'm not sure if this is the right way to suggest an edit to the current OAuth draft.  Please let me know if I should use a different route.
> 
> Section 4.1.2 Authorization Response includes the text, "If an authorization code is used more than once, the authorization server MUST deny the request and SHOULD revoke (when possible) all tokens previously issued based on that authorization code.  The authorization code is bound to the client identifier and redirection URI."
> 
> I believe this text is in the wrong place.  A client does not supply the authorization code to the authorization endpoint.  It supplies it to the token endpoint.  This should move to 4.1.3. Access Token Request, in the list of bulleted items under "The authorization server MUST".
> 
> Thanks for all your work on this protocol.
> 
> Regards,
> Michael Scalia