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

From: "Hurliman, John" <[email-masked]>
Date: Fri, 15 Jan 2010 17:54:46 -0700

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.

---

From: David Recordon <[email-masked]>
Date: Fri, 15 Jan 2010 20:12:49 -0800

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-masked]> 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-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>