IETF Logo Mail Archive

Re: [OAUTH-WG] Flowchart for legs of OAuth

Phil Hunt <phil.hunt@oracle.com> Thu, 31 March 2011 23:55 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 C5A9B3A69C7 for <oauth@core3.amsl.com>; Thu, 31 Mar 2011 16:55:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.559
X-Spam-Level:
X-Spam-Status: No, score=-6.559 tagged_above=-999 required=5 tests=[AWL=0.040, 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 BUqBhyn7JGZa for <oauth@core3.amsl.com>; Thu, 31 Mar 2011 16:55:11 -0700 (PDT)
Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id A61903A6949 for <oauth@ietf.org>; Thu, 31 Mar 2011 16:55:10 -0700 (PDT)
Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p2VNumYH019231 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 31 Mar 2011 23:56:49 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p2VNulDv013325 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 31 Mar 2011 23:56:47 GMT
Received: from abhmt007.oracle.com (abhmt007.oracle.com [141.146.116.16]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p2VNulkX018121; Thu, 31 Mar 2011 18:56:47 -0500
Received: from [192.168.1.8] (/24.85.235.164) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 31 Mar 2011 16:56:46 -0700
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Phil Hunt <phil.hunt@oracle.com>
In-Reply-To: <BANLkTiniuuRXtkzLubgOjVursVtOGjFe6A@mail.gmail.com>
Date: Thu, 31 Mar 2011 16:56:45 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <7616C235-2913-4EE0-A710-F47A4CC9E424@oracle.com>
References: <22FB565B-A701-4502-818F-15164D9E201A@oracle.com> <AANLkTimGjiCGk5dpA=YVzq5vDkLR2+caSz=pZ5WiZO9H@mail.gmail.com> <3C84AD7A-F00F-43EC-AAD3-AD2DCFB46B0E@oracle.com> <90C41DD21FB7C64BB94121FBBC2E7234464F432BB0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4D84F7E2.6090305@redhat.com> <16B9A882-6204-4CBD-B7E3-1D806AF5056C@oracle.com> <4D8A5054.4050006@lodderstedt.net> <BANLkTiniuuRXtkzLubgOjVursVtOGjFe6A@mail.gmail.com>
To: Marius Scurtescu <mscurtescu@google.com>
X-Mailer: Apple Mail (2.1084)
X-Source-IP: acsmt357.oracle.com [141.146.40.157]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090204.4D9514C0.007A:SCFSTAT5015188,ss=1,fgs=0
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth
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: Thu, 31 Mar 2011 23:55:13 -0000

Done. 

It isn't quite what the flow shows in the earlier diagram. I was originally avoiding client type and trying to focus on section 4 options.

But this should be a better diagram.

http://independentidentity.blogspot.com/2011/03/oauth-flows-extended.html

Phil
phil.hunt@oracle.com




On 2011-03-31, at 4:41 PM, Marius Scurtescu wrote:

> On Wed, Mar 23, 2011 at 12:56 PM, Torsten Lodderstedt
> <torsten@lodderstedt.net> wrote:
>> Hi Phil,
>> 
>> looks even better now :-)
>> 
>> As already pointed out
>> (http://www.ietf.org/mail-archive/web/oauth/current/msg05599.html), "Have
>> client credentials? No" does not automatically imply usage of implicit
>> grant. The client could also use the authorization code (for various
>> reasons).
> 
> +1, no client credentials does not necessarily imply the implicit grant.
> 
> Marius

v2.23.0 | Report a Bug | By Email