Absolutely, however, I believe the atomic units that make up the OAuth profile spectrum have not properly taken into account the tidal wave of DiSo interactions that are forth coming. Subsequently you can force them into place and say "they work" but IMO will have a hard time achieving adoption due to the impact they have on the UX.
Also, seeing as you have James are having your own discussion on this topic, if you haven't already, you may want to read through this thread which is taking place concurrently. http://groups.google.com/group/federated-social-web/browse_thread/thread/842aa86bce762942 Darren On Tue, Aug 3, 2010 at 7:45 AM, Torsten Lodderstedt <tors...@lodderstedt.net> wrote: > Darren, >> >> As an OAuth 2 provider and consumer as well as someone who's preparing >> to build the DiSo interactions my proposal was based on, I would >> prefer a single flow that addresses what I feel will be a increasingly >> common set of requirements rather than combining two flows designed >> for two distinct purposes. >> >> > > I would rather put this the other way around. Your particular use case can > be implemented by utilizing the building blocks already built into the > specification. Great! That's what I expect from a _standard_. It provides > people with atomic building blocks, they can create their solutions from. I > don't think we should add every possible flow to the standard. > > Even regarding your proposal, much more is possible. You suggest to use the > web server flow for end-user authorization if the assertion flow failed. Why > not using the user agent or the username/password flow instead? Or any other > way of authenticating and authorizing an end-user? That way, clients can > choose the option matching their requirements and capabilities the most. > > Please also note your proposal has an significant impact on access token > lifecycle. In step 1 you propose to issue a none-authorized access token. > This means an authz server must be able to authorize access tokens after > issuance, which is not required currently. Additionally, resource servers > must be able to recognize none-authorized (invalid) access tokens and refuse > any attempt to access resources with an access token in that state. In my > opinion, this makes the tokens lifecycle much more complex and will not work > in all possible setups, especially if the authorization server issues > self-contained tokens. In such a setup, no direct communication takes place > during request processing on the resource server. > > regards, > Torsten. > > -- darren bounds dar...@cliqset.com _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
