Hey John, I think that the OAuth work under way will support your scenarios other than #3. Signing in with an arbitrary account is currently best solved via OpenID. OAuth powers Twitter's SSO but requires that each implementor know specifically that it will be a Twitter user logging in whereas OpenID has bootstrapping discovery built in.
I'm with you for #4; simplicity for developers is really important in this next generation of OAuth! --David On Fri, Jan 15, 2010 at 4:54 PM, Hurliman, John <[email protected]> wrote: > Hello OAuth lists! > > > > Let my briefly introduce myself. I’m John Hurliman, a software engineer on > Intel’s Virtual World Infrastructure team. Our team focuses on everything in > immersive connected experiences from performance and scalability to > federated identity and interoperability. My project over the last year has > been Cable Beach, a research project to investigate topics such as federated > identity, delegated service authorization, service discovery, etc. as they > apply to immersive connected experiences. I’ve also been working closely > with the VWRAP (Virtual World Region Access Protocol) IETF group and plan to > merge my Cable Beach work into VWRAP. I’ll be presenting at VWRAP IETF77 and > will hopefully be able to stop by the OAuth working group as well. > > > > I recently wrote a blog post detailing the history of VWRAP and Cable Beach, > and how OAuth WRAP is currently meeting our needs (and hopefully OAuth 2.0). > Hopefully this can serve as an example scenario for OAuth. > http://www.jhurliman.org/2010/01/merging-vwrap-and-cable-beach/ > > > > The important highlights are: 1) We need to support both web-initiated > logins and logins directly through a client where the user inputs a > username/password. The latter will also support automated clients where it’s > not feasible for a human to go through a web login process every time. 2) We > need to expose web APIs for the various virtual world services, preferably > using the same system that users login to the virtual world with. 3) We need > to be able to login to one virtual world using an account that exists on > another world (similar to an OpenID or Facebook Connect login). 4) The > easier to implement the better, since we will likely have implementations > popping up in at least C++, C#, Python, PHP, and Java. > > > > Best, > > John Hurliman > > Intel Corp. > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
