I would go even further and say authentication methods should be completely out of scope for VW interop. Authentication methods are out of scope for OpenID as well. OpenID provides bits and pieces to make federated identity work, and I would argue that supporting multiple federated identity solutions drastically increases the complexity of the system with no return. But there's no reason you can't have OpenID+LDAP, OpenID+username/password, OpenID+XML-RPC token exchange, etc.

John

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

>