Re: [mmox] where is identity @ in all this?

Dear Mark:

Yes, that is a place where we can make progress. I am in fact "Charles Krinke" on OSGrid, but I needed to be "Charlesk Bing" on SecondLife due to the  rules of that particular grid. 

I have a gmail account, as many other folks to and thus I believe I already have an OpenID, so using OpenID is not unreasonable.

I would personally suggest that we recommend at least two different authentication methods so as not to paint ourselves into a corner down the road a bit.

Charles Krinke

p.s. I would love to hear more about Croquet and how we can find ways to interop and teleport between SecondLife, OpenSim and Croquet.

________________________________
From: Mark P. McCahill <mccahill@duke.edu>
To: mmox@ietf.org
Sent: Thursday, February 19, 2009 10:26:51 AM
Subject: [mmox] where is identity @ in all this?

These worlds are fundamentally social environments. I would suggest starting with interoperability for federated identity and presence.

At a minimum I want to know which worlds my buddies are currently playing in, and be able to chat with them, and be able to chat with people outside the virtual worlds. If there are any ambitions toward integrating presence in virtual worlds with more traditional audio, video, and text communications, then SIP and XMPP-based presence would be worth considering rather than re-inventing these functions.

Most virtual worlds act as both metaverse service providers (MSP) and identity providers. This is a mistake.

Tightly coupling the MSP and identity provider functions is why I have to keep telling people that Mark McCahill is named Mysterio Sinister in Second Life - I can't easily be mccahill@duke.edu because Second Life doesn't use external federated identity providers. Then when I go to one of the OpenSim worlds, I need to create another account, and hope that nobody has signed up for Mysterio Sinister before I got there.

Requiring avatars to create a new account/password at each of the different metaverse service providers is not a very appealing prospect. Why aren't we addressing the federated identity/presence issue now? There are a number of existing approaches that could be relatively easily adopted across different technologies and set the stage for deeper interoperability down the road.

To make any real progress, we need agreement about standards for accepting identities provided by other virtual worlds. Even better, how about something that is not a virtual world (OAuth, OpenID, Shibboleth all come to mind) an option as an identity provider? Solving this problem is a prerequisite for making any real progress toward allowing free movement across worlds.

Why aren't we talking about standards for

     name@identity_provider

authentication which could be used across worlds?

Mark McCahill
OpenCroquet/Cobalt

On Feb 18, 2009, at 7:34 PM, Jon Watte wrote:
> 
> So, what is an avatar anyway? I think it has one or more meshes (that are not standard), draped over a skeleton (that is not standard), with one or more textures applied (that are not standard). Avatars also represent users, which have identity. Avatars can move (physically, with collision detection), animate (interactions, emotes), voice communicate and text chat.
> 
> If you can send that information ([identity, mesh, texture, skeleton] as set-up, and [movement, animation, interactions, voice and text chat] at runtime) then do you have an interoperable avatar?
> And, if so, what separates an avatar from another animated, movable object? Could the same way that avatars are interoperating be used to interoperate other simulated objects? From a remote systems' point of view, there's not that much difference between a human-driven avatar, and a tumbling rock -- the remote system can't be expected to run the simulation for either one, so it needs to have that stream of behavior to represent it.
> 
> As far as I know Wonderland, Qwaq, Multiverse and other possible adopters, the above representations maps fairly straightforward to their systems, although any system will have to expect to write adaption code to accept "arbitrary" external meshes as avatars.
> 
> Sincerely,
> 
> jw
> 
> _______________________________________________
> mmox mailing list
> mmox@ietf.org
> https://www.ietf.org/mailman/listinfo/mmox

_______________________________________________
mmox mailing list
mmox@ietf.org
https://www.ietf.org/mailman/listinfo/mmox