IETF Logo Mail Archive

Re: [OAUTH-WG] Draft -12 feedback deadline

Phil Hunt <phil.hunt@oracle.com> Mon, 28 February 2011 23:18 UTC

Return-Path: <phil.hunt@oracle.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 6FBAB3A6A4C for <oauth@core3.amsl.com>; Mon, 28 Feb 2011 15:18:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.482
X-Spam-Level:
X-Spam-Status: No, score=-6.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 RPEvMW1pY6d6 for <oauth@core3.amsl.com>; Mon, 28 Feb 2011 15:18:26 -0800 (PST)
Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 9A1663A6836 for <oauth@ietf.org>; Mon, 28 Feb 2011 15:18:26 -0800 (PST)
Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p1SNJLRt003890 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 28 Feb 2011 23:19:24 GMT
Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p1SNJJUF004724; Mon, 28 Feb 2011 23:19:20 GMT
Received: from abhmt016.oracle.com by acsmt353.oracle.com with ESMTP id 1094729781298935094; Mon, 28 Feb 2011 15:18:14 -0800
Received: from [192.168.1.8] (/24.85.235.164) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 28 Feb 2011 15:18:13 -0800
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset="us-ascii"
From: Phil Hunt <phil.hunt@oracle.com>
In-Reply-To: <AANLkTi=GK2Lrb_snOenhiCPxdqL85VHqLyp4Y1_aCCdp@mail.gmail.com>
Date: Mon, 28 Feb 2011 15:18:12 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <C5A22573-AB0B-4368-9265-62B8083E9E65@oracle.com>
References: <90C41DD21FB7C64BB94121FBBC2E723445A8D6254D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTinMjQW26mLkoN7oMdLWLGAHp0_O9LbVi13RpMJB@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E723445A91D3EE9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTimjWkO8o+z+P=AKpyYkSjTh6oS7uM9N0JwR_vR6@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E723445A91D3F44@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTi=tvwsR=_EhPRkYEwC+ERwRCNN2aAWDqRDvwx8B@mail.gmail.com> <FFDFD7371D517847AD71FBB08F9A315638493F514F@SP2-EX07VS06.ds.corp.yahoo.com> <AANLkTimxhoK1vt8HwSF9dvu4Z5xjqrLLb2SULj9pp=9b@mail.gmail.com> <AANLkTi=DtgpWNyEKBg=0GhOWuqSvzF5q0SJQgfZNRm8M@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E723445A91D3F9A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTindJ3oGpggvZ7jRJ4TRhTRomyZG+DwLOfbHD2kq@mail.gmail.com> <OFEFAF96E1.1837BBD4-ON8025783B.0040108E-8025783B.0040FF69@ie.ibm.com> <AANLkTi=PnOmyaMnNrGgPnOO_wtF8b_=v99wiR5ospHLH@mail.gmail.com> <4D68F471.3090204@lodderstedt.net> <4D6C0289.3030300@alcatel-lucent.com> ! <AANLkTi=GK2Lrb_snOenhiCPxdqL85VHqLyp4Y1_aCCdp@mail.gmail.com>
To: Marius Scurtescu <mscurtescu@google.com>
X-Mailer: Apple Mail (2.1082)
X-Source-IP: acsmt355.oracle.com [141.146.40.155]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090201.4D6C2D79.006E:SCFMA4539814,ss=1,fgs=0
Cc: OAuth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Draft -12 feedback deadline
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: Mon, 28 Feb 2011 23:18:27 -0000

Given these questions, I am wondering, why does the Implicit Grant flow NOT have an authorization code step?  Having one, would keep architecture of AS and TS clearly separate.

One down side is that issuing of access/refresh token would now have to be opened to SHOULD authenticate the client from MUST.

What was the original case for this flow?  That should point us as to why the separate flow and whether refresh makes sense given the higher risks of the implicit flow.

Phil
phil.hunt@oracle.com




On 2011-02-28, at 2:58 PM, Marius Scurtescu wrote:

> On Mon, Feb 28, 2011 at 12:16 PM, Igor Faynberg
> <igor.faynberg@alcatel-lucent.com> wrote:
>> +1
>> 
>> Igor
>> 
>> Torsten Lodderstedt wrote:
>>> 
>>> ...
>>> 
>>> I'm in favour to add the refresh token parameter to the implicit grant
>>> flow as it would make it more useable for native apps.
> 
> I think it is much safer to go with refresh tokens only sent
> indirectly through an authorization code swap.
> 
> Implicit grant with refresh token also has no client secret swap and
> makes things worse by passing the refresh token through the browser.
> 
> Marius
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

v2.23.0 | Report a Bug | By Email