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).
regards,
Torsten.
Am 23.03.2011 19:11, schrieb Phil Hunt:
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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
