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

Dick Hardt <dick.hardt@gmail.com> Tue, 17 July 2012 22:55 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 A351211E80D9 for <oauth@ietfa.amsl.com>; Tue, 17 Jul 2012 15:55:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.554
X-Spam-Level:
X-Spam-Status: No, score=-3.554 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 vzHQie0E53b8 for <oauth@ietfa.amsl.com>; Tue, 17 Jul 2012 15:55:39 -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 E1D0711E80CC for <oauth@ietf.org>; Tue, 17 Jul 2012 15:55:38 -0700 (PDT)
Received: by pbcwy7 with SMTP id wy7so1559671pbc.31 for <oauth@ietf.org>; Tue, 17 Jul 2012 15:56:27 -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 :message-id:references:to:x-mailer; bh=ahh/D1UmE1Q+0CEVaEcA2sTn67rmgQE3gHQ2qzDKwNo=; b=DLAEChDz+emfhn9JrCs9br2WytUxDeiZpZEzuGTuD4ZWLddqm5UMKhbnPNeCnzMn/K 0a4/JrKJbksdy+d2BYIId150T7Jms6gJobqZYUiIc6KQlrAqk8rzni5Q/2XxALZvHhUV Ctx7GBGtVelhn0jC4fN2wG2x4CDKuq1wB2rPd+riEeT70WXPGcsZNcyQfJGU3Y/PQ+Gl ucj6xQgbw/b23byt5vgtuqS2dTu+VAP0YhC64BwQzCUG42eP9xb1SE2ZU9GprB42/nCK TGNKG3CueDg8s/+k4ZaTU2QRm0J7t2SnR1YQ/kxEbjutU7R8j8cswXXbHO0uJIWOW2VC CjTA==
Received: by 10.66.81.202 with SMTP id c10mr163709pay.20.1342565787541; Tue, 17 Jul 2012 15:56:27 -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 gl1sm14857340pbc.71.2012.07.17.15.56.25 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 17 Jul 2012 15:56:26 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1278)
Content-Type: multipart/alternative; boundary="Apple-Mail=_3FE7E759-232C-41FB-85F2-ECD3600203F1"
From: Dick Hardt <dick.hardt@gmail.com>
In-Reply-To: <CA+NzUBuBo5shGWV+Ca=uEztV69c3EhyY2QpFVny=_tvJjdDNog@mail.gmail.com>
Date: Tue, 17 Jul 2012 15:56:24 -0700
Message-Id: <FE714B15-40C0-45C4-883A-C19179872C7B@gmail.com>
References: <CA+NzUBvPO4jVLqdzNXF8MQXZew262G3Ashs-vvqF2pAbh8bukg@mail.gmail.com> <6C34F5DD-9CA7-40B0-B2DE-FB5E0A0D94D4@gmail.com> <CA+NzUBuBo5shGWV+Ca=uEztV69c3EhyY2QpFVny=_tvJjdDNog@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:55:39 -0000

Thanks for the implementation feedback Michael.

-- Dick

On Jul 17, 2012, at 3:46 PM, Michael Scalia wrote:

> Thanks for your response, Dick, and for pointing out that this is RECOMMENDED.  I'll just say one more thing about this.  While implementing the token endpoint of an authorization server, I naturally looked for the things I needed to account for in the request under 4.1.3  Access Token Request.  I missed this because it wasn't with the other information about access token requests.  Others may miss it as well, for the same reason.  Just happened to notice this today under 4.1.2 while re-reading the spec.
> 
> Regards,
> Michael
> 
> On Tue, Jul 17, 2012 at 6:09 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
> 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
> 
>