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

Anil Saldhana <Anil.Saldhana@redhat.com> Sat, 19 March 2011 18:35 UTC

Return-Path: <Anil.Saldhana@redhat.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 8B7D83A694E for <oauth@core3.amsl.com>; Sat, 19 Mar 2011 11:35:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level:
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 wXU8ZQnEvh5r for <oauth@core3.amsl.com>; Sat, 19 Mar 2011 11:35:52 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by core3.amsl.com (Postfix) with ESMTP id 662FD3A6920 for <oauth@ietf.org>; Sat, 19 Mar 2011 11:35:52 -0700 (PDT)
Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p2JIbNcs008533 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <oauth@ietf.org>; Sat, 19 Mar 2011 14:37:23 -0400
Received: from localhost.sadbhav (vpn-229-47.phx2.redhat.com [10.3.229.47]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p2JIbM3a002417 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for <oauth@ietf.org>; Sat, 19 Mar 2011 14:37:23 -0400
Message-ID: <4D84F7E2.6090305@redhat.com>
Date: Sat, 19 Mar 2011 13:37:22 -0500
From: Anil Saldhana <Anil.Saldhana@redhat.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.15) Gecko/20110307 Fedora/3.1.9-0.39.b3pre.fc14 Thunderbird/3.1.9
MIME-Version: 1.0
To: oauth@ietf.org
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>
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234464F432BB0@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
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: Sat, 19 Mar 2011 18:35:53 -0000

I agree.  "2 party oauth", "3 party oauth"  tells  what it is, rather than
"3 legged oauth".

On 03/18/2011 07:20 PM, Eran Hammer-Lahav wrote:
> The legs terminology is just plain awful. I prefer parties, roles, anything else.
>
> EHL
>
>> -----Original Message-----
>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
>> Of Phillip Hunt
>> Sent: Friday, March 18, 2011 5:07 PM
>> To: David Primmer
>> Cc: OAuth WG
>> Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth
>>
>> I agree with what you are saying. We were having trouble understanding legs
>> too, so I came up with the diagram. The diagram does show the parties
>> aspect. But I remain uncomfortable about the terminology.
>>
>> Phil
>>
>> Sent from my phone.
>>
>> On 2011-03-18, at 15:55, David Primmer<primmer@google.com>  wrote:
>>
>>> Hi Phil,
>>>
>>> I actually think this rephrasing of the rule of thumb is not really
>>> helpful based on how the word "legs" has been used in my experience of
>>> discussing and teaching OAuth. I actually tried to be pretty explicit
>>> about this topic in a talk I did at Google I/O last year because we
>>> have lots of questions about 2 versus 3 legged OAuth since the launch
>>> of the Google Apps Marketplace.
>>> http://www.youtube.com/watch?v=0L_dEOjhADQ. I speak about 17mins
>> in.
>>> We have traditionally used the terms two legged OAuth and three legged
>>> OAuth to describe the trust relationships involved in the grant. I
>>> think your interpretation is very different and not a common way to
>>> use the terms 'legs' in relation to OAuth and will simply confuse
>>> people. 2LO involves a client authenticating itself to a server. 3LO
>>> involves those two previous actors, plus a user/resource owner who
>>> delegates permissions to the client. In everyday use, 2LO is 'server
>>> to server' auth with out of band permissions and user identity and 3LO
>>> involves an individual grant where the user's grant is identified by a
>>> token given to the client and passed to the server on access. Another
>>> way to look at it is 2LO is just HTTP request signing.
>>>
>>> davep
>>>
>>> On Mon, Feb 21, 2011 at 4:45 PM, Phil Hunt<phil.hunt@oracle.com>  wrote:
>>>> FYI. I published a blog post with a flow-chart explaining the legs of OAuth.
>>>> http://independentidentity.blogspot.com/2011/02/does-oauth-have-
>> legs.
>>>> html
>>>>
>>>> Please let me know if any corrections should be made, or for that matter,
>> any improvements!
>>>> Phil
>>>> phil.hunt@oracle.com
>>>>