Re: [OAUTH-WG] Preliminary OAuth Core draft -29

Dick Hardt <dick.hardt@gmail.com> Mon, 09 July 2012 20:30 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 3474C11E81C2 for <oauth@ietfa.amsl.com>; Mon, 9 Jul 2012 13:30:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.583
X-Spam-Level:
X-Spam-Status: No, score=-3.583 tagged_above=-999 required=5 tests=[AWL=0.016, 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 Et1ouCyMqLkt for <oauth@ietfa.amsl.com>; Mon, 9 Jul 2012 13:30:41 -0700 (PDT)
Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id A4D1511E8171 for <oauth@ietf.org>; Mon, 9 Jul 2012 13:30:41 -0700 (PDT)
Received: by ggnc4 with SMTP id c4so11553897ggn.31 for <oauth@ietf.org>; Mon, 09 Jul 2012 13:31:07 -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=8D9swjzKIiOBFsJY0FGleb1OM6Gv3a8mv4LmrKVYtrI=; b=CgBLmvBygDkYulDNs6Lgrr7+DVNULJiICy6mixnxkmkaZcgBMIp+117rJikB7H6Alu 3imCp8V5HajmHWYnZFAc/KJPhs1D1b7Gxb3qhGMvwS4lbrlEC/sRyp/sbe4ZMqdbtUx+ TSA+tQ9XXOfFKRPuKT5os6A1bQWf7OrY/GI0kpH3o868y4W8fPiOvP15SG6gFNJpY8h0 EjmNXUxy6t7yNtplVTXe85F9v0GIF8Z86m14k/7bS5IAqMrBHrSjCXS4KgCbXg6nvhi4 5rv60t2hgYNreMmV/33dyvQFg2V52U4MfzhWYUVVprT/w771YIzENMl4HP9+wm3R1Pg4 bQDA==
Received: by 10.66.75.162 with SMTP id d2mr68201369paw.59.1341865866656; Mon, 09 Jul 2012 13:31:06 -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 gk2sm16923386pbc.8.2012.07.09.13.31.03 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 09 Jul 2012 13:31:04 -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: <4FFB3D35.3080306@mitre.org>
Date: Mon, 09 Jul 2012 13:31:02 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <0FAF862E-3CB4-4A2E-B2FA-9C72159BCD68@gmail.com>
References: <4E1F6AAD24975D4BA5B16804296739436657C93A@TK5EX14MBXC283.redmond.corp.microsoft.com> <6AD425FB-9453-489D-9282-6EC125D535D5@gmail.com> <4FFB3D35.3080306@mitre.org>
To: Justin Richer <jricher@mitre.org>
X-Mailer: Apple Mail (2.1278)
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Preliminary OAuth Core draft -29
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: Mon, 09 Jul 2012 20:30:42 -0000

On Jul 9, 2012, at 1:21 PM, Justin Richer wrote:

> Implicit grant makes perfect sense when the user agent and client are collapsed into a single entity. In other words, if your client is inside the user agent then doing a code flow doesn't actually buy you any extra security.

It protects the client from an attacker replacing the access token.

> This is the driving design decision behind having it in there, and from my perspective that's clear from the current text.

I think the reasons for implicit flow are captured in 1.3.2, and it would be useful to point to them in 4.2 

> 
> In a similar manner, the client credentials flow came about from collapsing the client with the resource owner, effectively putting the resource owner inside the client.

It can be thought of like that, but that is not where it came from.

> In this case the authorization step doesn't make any sense and doing a code flow doesn't buy you any greater security, either.


One can think of the client credential flow as the client already having the code and that the authorization happened out of band. No need to change any copy.

On 07/09/2012 01:31 PM, Dick Hardt wrote:
> Hi Mike
> 
> Reading over the spec, I think some more color in 4.2 on the risks of the Implicit Grant and where it makes sense and where it does not is in order. 
> Also, this should be in Section 9.
> 
> Thoughts?
> 
> -- Dick