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

That is the identity proposal I'm working on. OpenID + OpenID Token Exchange* + OpenID Attribute Exchange == VW Identity Service.

* OAuth was specifically designed for a three legged scenario, and when you start adding in more services such as content, messaging, voice, etc. it no longer becomes feasible. OpenID Token Exchange solves this problem nicely though.

John

>-----Original Message-----
>From: mmox-bounces@ietf.org [mailto:mmox-bounces@ietf.org] On Behalf Of
>Mark P.McCahill
>Sent: Thursday, February 19, 2009 10:27 AM
>To: mmox@ietf.org
>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
> 