Re: [OAUTH-WG] Virtual world use case for OAuth

1 view
Skip to first unread message

David Recordon

unread,
Jan 15, 2010, 11:12:49 PM1/15/10
to Hurliman, John, OAuth WG, oauth-...@googlegroups.com
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 <john.h...@intel.com> 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
> OA...@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>

Hurliman, John

unread,
Jan 15, 2010, 7:54:46 PM1/15/10
to OAuth WG, oauth-...@googlegroups.com
Reply all
Reply to author
Forward
0 new messages