[mmox] where is identity @ in all this?

Mark P. McCahill <mccahill@duke.edu> Thu, 19 February 2009 18:26 UTC

Return-Path: <mccahill@duke.edu>
X-Original-To: mmox@core3.amsl.com
Delivered-To: mmox@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E135C3A6AFF for <mmox@core3.amsl.com>; Thu, 19 Feb 2009 10:26:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6nG0aa-f7062 for <mmox@core3.amsl.com>; Thu, 19 Feb 2009 10:26:40 -0800 (PST)
Received: from smtp.duke.edu (smtp-02.oit.duke.edu [152.3.174.84]) by core3.amsl.com (Postfix) with ESMTP id 86E003A6915 for <mmox@ietf.org>; Thu, 19 Feb 2009 10:26:40 -0800 (PST)
Received: from smtp.duke.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 4647451121A for <mmox@ietf.org>; Thu, 19 Feb 2009 13:26:53 -0500 (EST)
Received: from dyn-152-3-124-53.oit.duke.edu (dyn-152-3-124-53.oit.duke.edu [152.3.124.53]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.duke.edu (Postfix) with ESMTP id 063465109EB for <mmox@ietf.org>; Thu, 19 Feb 2009 13:26:53 -0500 (EST)
Message-Id: <488F29D4-F071-4725-B1B6-FFC17C220F8D@duke.edu>
From: "Mark P. McCahill" <mccahill@duke.edu>
To: mmox@ietf.org
In-Reply-To: <499CA916.1090008@gmail.com>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Date: Thu, 19 Feb 2009 13:26:51 -0500
References: <1E40CE05-15D1-4970-9B0F-CD4AD11A074A@lindenlab.com> <62BFE5680C037E4DA0B0A08946C0933D501FDC38@rrsmsx506.amr.corp.intel.com> <499C5415.7060400@cox.net> <62BFE5680C037E4DA0B0A08946C0933D501FE124@rrsmsx506.amr.corp.intel.com> <2bd5b7f10902181356l64dd8366n2b5e57ef4242ae0f@mail.gmail.com> <676211.48955.qm@web82608.mail.mud.yahoo.com> <499CA916.1090008@gmail.com>
X-Mailer: Apple Mail (2.930.3)
X-PMX-Version: 5.4.2.338381, Antispam-Engine: 2.6.0.325393, Antispam-Data: 2009.2.19.181319
Subject: [mmox] where is identity @ in all this?
X-BeenThere: mmox@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Massively Multi-participant Online Games and Applications <mmox.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mmox>, <mailto:mmox-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmox>
List-Post: <mailto:mmox@ietf.org>
List-Help: <mailto:mmox-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmox>, <mailto:mmox-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Feb 2009 18:26:42 -0000

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