FYI. I have posted a new version of the flows on my blog showing the new terminology as discussed here. Feedback appreciated. http://independentidentity.blogspot.com/2011/03/oauth-flows-extended.html
Phil phil.h...@oracle.com On 2011-03-19, at 11:37 AM, Anil Saldhana wrote: > 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-boun...@ietf.org [mailto:oauth-boun...@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<prim...@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.h...@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.h...@oracle.com >>>>> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
