Subject: [mmox] The Story So Far...

From: Mark Lentczner <[email-masked]>
Date: Tue, 17 Feb 2009 14:37:10 -0800

MMOXen -

I thought that it would be good to give a recap of how we got to where  
we are...

By mid-2007 there were at least two independent development efforts  
that were trying to be interoperable with Second Life, despite there  
being no official way to do it: LibSL and OpenSim.  At Linden Lab, we  
saw that as healthy, and indication that there was clear interest in  
building toward interoperable virtual worlds. In September of 2007,  
Linden Lab called together a group of interested users, including the  
LibSL and OpenSim projects, and formed the Architecture Working Group  
(AWG) to help design an interoperable architecture and protocol.

In the Spring of 2008, the first drafts of the Open Grid Protocol  
(OGP) were published. Rather than simply writing down Second Life's  
existing protocol, these documents took new ideas, melded with what  
the community learned about interfacing with Second Life, and boot- 
strapped a wholly new protocol.  Working through the Spring and Summer  
of 2008, Linden Lab, first with IBM, and then later with a wider range  
of the community, demonstrated interoperability between Second Life  
and OpenSim, having avatars teleport back and forth between the  
worlds. At the same time, others created another implementation of the  
protocol, PyOGP, to be used for testing and for building other  
interoperable components.

By the end of 2008, since there were now several OGP documents  
written[1], and several implementations, it seemed to us that the time  
was ripe to bring this work to the IETF: Some of these protocols would  
need things like registered MIME types, and all would benefit from  
more input to the work. In that context, along with the fortuitous  
location and timing of IETF 74, Linden Lab and IBM requested creation  
of this mailing list, and a BoF session for IETF 74. While we realize  
that OGP has a long way to go, building a working group at a standards  
body also takes time, and felt that we should get started now.

During roughly the same span of time, two other consortia efforts got  
under way.  One is the MPEG-V group which is looking at information  
exchange formats and interfaces with the physical world.  Their last  
published documents are from May 2008 and are a set of project  
requirements[2]. The other group is the Virtual Worlds Roadmap SIG,  
started by Intel, Samsung, Electric Sheep and others to develop a  
broad case analysis, roadmap and timeline for adoption of virtual  
worlds and their applications[3]. These groups clearly have different  
objectives than the IETF's which is more focused on supporting  
protocol usage on the Internet.  We felt that the required work on OGP  
would be best served by the IETF, whereas more general discussion and  
evolution would be better served by the Virtual Worlds Roadmap SIG.

While there is plenty to do and discuss in order to develop OGP into a  
fully workable protocol, we think it represents an initial shared  
vision of an interoperable protocol and hope it can evolve and grow in  
the context of this group.

	- Mark Lentczner

[1] http://wiki.secondlife.com/wiki/Open_Grid_Protocol
[2] http://www.chiariglione.org/mpeg/working_documents.htm#MPEG-V
[3] http://www.virtualworldsroadmap.org/

Mark Lentczner
Sr. Systems Architect
Technology Integration
Linden Lab

[email-masked]

Zero Linden
[email-masked]

P.S.: I like "MMOXen".  Makes me think we are bearing the hard work to  
furrow the ground to plant the seeds for the growth of.... okay, okay,  
so perhaps I'm taking that too far.  But I still like "MMOXen".

---

From: "Hurliman, John" <[email-masked]>
Date: Tue, 17 Feb 2009 16:09:17 -0700

>fully workable protocol, we think it represents an initial shared vision
>of an interoperable protocol and hope it can evolve and grow in the
>context of this group.
>
>- Mark Lentczner
>

It's great to see the amount of work that is being brought to the table by Linden Lab and the Linden Lab Architecture Working Group (AWG) participants, and I hope as much of it as possible can be used to build an MMOX standard. I've been working on an LLIDL implementation among other things based on what Linden Lab has submitted as draft material. However, I have some concerns about the implicit merging of MMOX goals and what Linden Lab's AWG is proposing.

It's my understanding that Open Grid Protocol (OGP) is a Linden Lab project; part of the Linden Lab AWG which had no active contributors that were also active developers of libSecondLife/libOpenMetaverse or OpenSim during the time the OGP protocols were designed. The "agent domain" concept in OGP terminology brings in a host of assumptions that are diametrically opposed to the goals of libOpenMetaverse and OpenSim (supporting millions of independent administrative domains and service providers).

The current MMOX charter makes no reference to specific implementations such as Linden Lab's OGP, which I think is the correct approach.

John

---

From: "Meadhbh Hamrick (Infinity)" <[email-masked]>
Date: Tue, 17 Feb 2009 15:42:08 -0800

On Feb 17, 2009, at 3:09 PM, Hurliman, John wrote:

>> vision
> It's great to see the amount of work that is being brought to the  
> table by Linden Lab and the Linden Lab Architecture Working Group  
> (AWG) participants, and I hope as much of it as possible can be used  
> to build an MMOX standard. I've been working on an LLIDL  
> implementation among other things based on what Linden Lab has  
> submitted as draft material.

awesome!

> It's my understanding that Open Grid Protocol (OGP) is a Linden Lab  
> project; part of the Linden Lab AWG which had no active contributors  
> that were also active developers of libSecondLife/libOpenMetaverse  
> or OpenSim during the time the OGP protocols were designed. The  
> "agent domain" concept in OGP terminology brings in a host of  
> assumptions that are diametrically opposed to the goals of  
> libOpenMetaverse and OpenSim (supporting millions of independent  
> administrative domains and service providers).

huh? there were a number of non-lindens who participated in the  
development of OGP. the AWG does not, nor did it ever disallow  
participation by libSL or libOMV contributors / committers. last  
summer we demonstrated interoperability between Linden Lab's servers  
and an OpenSim instance. we hope that members of the libSL and libOMV  
teams will participate in MMOX.

the concept of an agent domain was defined explicitly to support many  
different independent administrative domains. that is... though the  
interoperability test last summer used the Linden agent domain, the  
specification does not mandate a single agent domain. in fact, i  
believe Christian Scholz (a non-linden) implemented his own Agent  
Domain based on code from the PyOGP project. There is also frequent  
mention in AWG meetings of an upcoming C# implementation of an Agent  
Domain, again by a non Linden-Lab employee.

---

From: Gareth Nelson <[email-masked]>
Date: Tue, 17 Feb 2009 23:47:46 +0000

> huh? there were a number of non-lindens who participated in the development
> of OGP. the AWG does not, nor did it ever disallow participation by libSL or
> libOMV contributors / committers. last summer we demonstrated
> interoperability between Linden Lab's servers and an OpenSim instance. we
> hope that members of the libSL and libOMV teams will participate in MMOX.
I believe that John was talking not so much about actual exclusion,
but more the fact that the AWG did not have a large % of active
opensim and libsl developers. Of course, quite a few opensim and libsl
developers ahve been involved and are often seen inworld at meetings.

> specification does not mandate a single agent domain. in fact, i believe
> Christian Scholz (a non-linden) implemented his own Agent Domain based on
> code from the PyOGP project. There is also frequent mention in AWG meetings
> of an upcoming C# implementation of an Agent Domain, again by a non
> Linden-Lab employee.

Could you tell us more about this C# implementation? I'm guessing it's
under the auspices of the opensim project based on that choice of
language.

---

From: "Hurliman, John" <[email-masked]>
Date: Tue, 17 Feb 2009 17:16:30 -0700

>-----Original Message-----
>From: Meadhbh Hamrick (Infinity) [mailto:[email-masked]]
>Sent: Tuesday, February 17, 2009 3:42 PM
>To: Hurliman, John
>Cc: [email-masked]
>Subject: Re: [mmox] The Story So Far...
>
>

I said "AWG had no active contributors that were also active developers of libSecondLife/libOpenMetaverse or OpenSim during the time the OGP protocols were designed". The participation by individuals that were not Linden Lab employees does not mean that OGP is a joint effort between Linden Lab and the libOpenMetaverse or OpenSim projects, or that the OGP as it is drafted has support from the libomv/OpenSim communities.

>Domain, again by a non Linden-Lab employee.

The agent domain concept takes several independent services (identity, presence, inventory) and lumps them together into a single trust domain. This inhibits the development of a widely distributed ecosystem like we find on the web today, and is really only convenient for large virtual world service providers that already have a vertical stack of services. It also drags in the assumption that there must be a backend communication layer between services such as inventory and simulation regions.

John

---

From: Charles Krinke <[email-masked]>
Date: Tue, 17 Feb 2009 16:23:49 -0800 (PST)

As I think about virtual worlds and interoperability, the metaphor of independent states or nations come to mind. So, I guess in thinking about interop between virtual worlds, we can either go down the secondlife/opensim type of path and try to fit all virtual worlds into that paradigm with agentdomains or UGAIM notions or we could step back a bit and consider interop between secondlife/opensim/Wow/croquet/wonderland and others.

Is is appropriate to start at a higher level and take a step back and consider the broader implications of virtual worlds beyond just our current paradigm such as WoW/croquet/wonderland and identify the minimum definition of network "plumbing" with that in mind?

Charles

________________________________
From: "Hurliman, John" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Sent: Tuesday, February 17, 2009 4:16:30 PM
Subject: Re: [mmox] The Story So Far...

John
_______________________________________________
mmox mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmox

---

From: Christian Scholz <[email-masked]>
Date: Wed, 18 Feb 2009 01:25:30 +0100

Hi!

> The agent domain concept takes several independent services (identity, presence, inventory) and lumps them together into a single trust domain. This inhibits the development of a widely distributed…

Speaking of the web: There are already a lot of social networks out 
there which are right now going to work on interoperability regarding 
profile data, activity streams, authentication and general authorization 
(based on efforts like OAuth (now also here at IETF), OpenID, 
OpenSocial, PortableContacts, XRDS-Simple etc.).

It would be great if these efforts can be integrated so that we don't 
have the problem in the end to bring web and virtual world together 
although both have basically the same idea of distributed services (and 
even partly the same services).

So let me ask in the question: Is this of general interest for this 
group to try to bridge that web/VW gap as well?

I think it would be of value because many of the protocols are already 
in use and thus are understood, have library support and so on.

That being said IMHO the Agent Domain really could be far more separated 
into separate services. All you maybe need is one starting point for 
your identity and some service catalogue which lists where all the other 
services are, either your individual ones (where is my profile, where 
are my group memberships) or service level ones (where is the region 
info, which login methods do you support).

-- Christian

-- 
Christian Scholz
Blog: http://mrtopf.de/blog
Company: http://comlounge.net
Podcasts: http://datawithoutborders.net, http://openweb-podcast.de

---

From: Gareth Nelson <[email-masked]>
Date: Wed, 18 Feb 2009 00:29:49 +0000

> Is is appropriate to start at a higher level and take a step back and
> consider the broader implications of virtual worlds beyond just our current
> paradigm such as WoW/croquet/wonderland and identify the minimum definition
> of network "plumbing" with that in mind?

Bingo!
Identify a solid core, then put extensions on that solid core

---

From: "Meadhbh Hamrick (Infinity)" <[email-masked]>
Date: Tue, 17 Feb 2009 16:59:24 -0800

since when?

the current implementation does, but the protocol definition is pretty  
explicit that you cannot assume that just because you authenticate to  
"host a" that the cap that will be granted to rez in world or to  
access inventory won't be on "host b" or "host c". I'm happy to start  
the discussion about whether identity should explicitly be divorced  
from authentication, so identification can be deferred to an even  
different host.

people have been talking about them being in the same administrative  
domain because we have no OAuth like mechanism defined to provide a  
non-forgeable authenticator that can be consumed by a third party.

that is to say... the spec does not mandate that identity, presence   
and inventory be managed by the same administrative domain, it's just  
that doing that seems to give peeps the security heebie-jeebies.

what you are asking appears to be the same as a Google service  
exposing a sensitive resource (maybe the right to read your gmail) to  
Yahoo! or Microsoft, but not REQUIRING that Yahoo! or Microsoft  
provide an authenticator indicating they have that right.

one of the reasons we're participating in the IETF is the wealth of  
experience this brings us in terms of people familiar with all sorts  
of enabling technologies (including things like TLS, HTTP, OAuth, etc.)

On Feb 17, 2009, at 4:16 PM, Hurliman, John wrote:

> The agent domain concept takes several independent services  
> (identity, presence, inventory) and lumps them together into a  
> single trust domain. This inhibits the development of a widely  
> distributed ecosystem like we find on the web today, and is really  
> only convenient for large virtual world service providers that  
> already have a vertical stack of services. It also drags in the  
> assumption that there must be a backend communication layer between  
> services such as inventory and simulation regions.

---

From: "Hurliman, John" <[email-masked]>
Date: Tue, 17 Feb 2009 18:02:04 -0700

The proposal for a virtual world identity service that I've been typing away at uses OpenID, OpenID Attribute Exchange, and OpenID Token Exchange to define a base set of interfaces and attributes for virtual world identity. In my opinion, there's a balancing act between asserting that virtual worlds add nothing new to the equation and nothing needs to be developed, and asserting that virtual worlds are an entirely new problem and throwing away the last decade or more of work.

John

>From: Christian Scholz [mailto:[email-masked]]
>Sent: Tuesday, February 17, 2009 4:25 PM
>To: Hurliman, John
>Cc: [email-masked]
>> The agent domain concept takes several independent services (identity,
>presence, inventory) and lumps them together into a single trust domain.
>This inhibits the development of a widely distributed ecosystem like we
>find on the web today, and is really only convenient for large virtual
>world service providers that already have a vertical stack of services.
>It also drags in the assumption that there must be a backend
>communication layer between services such as inventory and simulation
>regions.
>

---

From: "Meadhbh Hamrick (Infinity)" <[email-masked]>
Date: Tue, 17 Feb 2009 17:09:25 -0800

cool. the existing OGP protocol can be "retasked" to carry OpenID  
information, though it was neither designed for this nor was there any  
public discussion about doing it.

now that there's public discussion about doing it, lemme dig up my  
notes about some of the issues we thought we had with it and we can  
move forward with putting it into the protocol.

On Feb 17, 2009, at 5:02 PM, Hurliman, John wrote:

> The proposal for a virtual world identity service that I've been  
> typing away at uses OpenID, OpenID Attribute Exchange, and OpenID  
> Token Exchange to define a base set of interfaces and attributes for  
> virtual world identity. In my opinion, there's a balancing act  
> between asserting that virtual worlds add nothing new to the  
> equation and nothing needs to be developed, and asserting that  
> virtual worlds are an entirely new problem and throwing away the  
> last decade or more of work.
>
> John
>
>>> (identity,

---

From: Christian Scholz <[email-masked]>
Date: Wed, 18 Feb 2009 02:20:25 +0100

> The proposal for a virtual world identity service that I've been typing away at uses OpenID, OpenID Attribute Exchange, and OpenID Token Exchange to define a base set of interfaces and attributes f…

Sounds cool, looking forward to it.

As for the balancing act: Of course there is a lot new which virtual 
worlds bring but there is also a lot in common with social networks, 
such as identity, profiles, groups, IM, assets.
What's new is of course the actual 3D part of it. But you might see this 
"just" as an additional service to offer. Of course it's a rather big 
service and it might need additional ties into esp. the asset realm.

And on the web as on VWs people are thinking hard about how to enable 
identities across networks so my hope is that both solutions are 
somewhat compatible :-)  (as said, the keywords there are OpenID, OAuth 
and OpenSocial. Microformats are also used but of course those are 
eventually a bit out of scope for VW based systems which might not 
necessarily have web pages attached).

But in general I think it would be cool if I could login to some virtual 
world with my Yahoo OpenID and use my MySpace profile information plus 
find contacts from e.g. MySpace as well. This actually is not really far 
off as Yahoo supports OpenID and MySpace supports OAuth and OpenSocial. 
So some parts are already in place.

-- Christian

PS: When I say OpenSocial I mean the REST API which allows you to 
read/write profile information, contacts etc. Not the gadget stuff. The 
only problem with it might be that the profile schema has not all the 
fields needed for virtual worlds, like location has a completely 
different semantic here. But such things can be fixed I guess.

---

From: Christian Scholz <[email-masked]>
Date: Wed, 18 Feb 2009 02:26:17 +0100

Meadhbh Hamrick (Infinity) schrieb:
> now that there's public discussion about doing it, lemme dig up my notes 
> about some of the issues we thought we had with it and we can move 
> forward with putting it into the protocol.

That sounds great and I would be very interested in the issues (and 
maybe the openid mailing list as well). Would be great to actually also 
have that implemented in the client ;-) Another idea might here be 
though to use OAuth for the client as well. It would then basically work 
like the flickr uploadr works by opening a web site where you confirm 
access and by some token exchange in the background. This would 
eliminate the problem of needing a web browser for OpenID (but might 
have security implications as you give full access and are not asked for 
a password again for some amount of time).

But just brainstorming here.. definitely a problem which needs to get 
tackled regarding OpenID in general as more and more devices might not 
have a web browser or maybe are too annoying to use that way.

-- Christian

>> virtual world identity. In my opinion, there's a balancing act between 
>> asserting that virtual worlds add nothing new to the equation and 
>> nothing needs to be developed, and asserting that virtual worlds are 
>> an entirely new problem and throwing away the last decade or more of 
>> work.
>>
>> John
>>

---

From: Gareth Nelson <[email-masked]>
Date: Wed, 18 Feb 2009 01:52:48 +0000

> explicit that you cannot assume that just because you authenticate to "host
> a" that the cap that will be granted to rez in world or to access inventory
> won't be on "host b" or "host c". I'm happy to start the discussion about
> whether identity should explicitly be divorced from authentication, so
> identification can be deferred to an even different host.
I believe that it would be quite trivial to have separate identity
provider services which merely point at other services that are hosted
by the same provider or hosted somewhere else.
For example, I can picture something like this in the login response:
{'inventory':'https://providera.com/inv/<MyUUID>',
 'im':'https://providerb.com/im/<MyUUID>'}

> people have been talking about them being in the same administrative domain
> because we have no OAuth like mechanism defined to provide a non-forgeable
> authenticator that can be consumed by a third party.
Is it not that people have been lumping them into one domain because
for the most part we only have single domains right now?
When was the last time someone realistically had any means to "mount"
their inventory from say OSGrid and Second Life, with identity being
hosted somewhere else and then logging into some random region domain?

> what you are asking appears to be the same as a Google service exposing a
> sensitive resource (maybe the right to read your gmail) to Yahoo! or
> Microsoft, but not REQUIRING that Yahoo! or Microsoft provide an
> authenticator indicating they have that right.
The capability URL is the proof that they have the right :)
I'd go so far as to say that we need a proxy-type service for
generating new limited caps URLs that can be revoked by the user

---

From: Kajikawa Jeremy <[email-masked]>
Date: Wed, 18 Feb 2009 22:24:54 +0900

Then the Minimum "plumbing" would be
 "User Account" and "User Presence" along with some kind of 3dspace with
  "object"s present that are not a "User Presence"...

in SL terms this would be "grid"/"users" and "asset/inventory" functions
required,

in WoW terms,  a "User Account", the "Game Arena" server and then the
  Users "Item Storage" for Items picked up in the "Game Arena".

3 parts,
  1 "human" Presence and Identity,
  2 some kind of "mappable area" that is shared,
  3 interactable "objects" present in the "mappable area".

Any client functionality would be at bare minimum that and would need to
make a display
  representing the map and objects in it. would it not ?

the "AgentDomain" and "User" Services from SL would be merged for
Identity & Presence,
the "Grid" & "Region" services also appear to merge,
the "Assets" & "Inventory" services also appear to be merged,
as for messaging,  each platform has so far implimented this in some
fashion as an extended
  feature of presence,  I vote to keep this an open binding option
allowing choice of backend

does anyone see any problems with my simplification in the above 3 parts
listing?

On Tue, 2009-02-17 at 16:23 -0800, Charles Krinke wrote:
> As I think about virtual worlds and interoperability, the metaphor of
> independent states or nations come to mind. So, I guess in thinking
> about interop between virtual worlds, we can either go down the
> secondlife/opensim type of path and try to fit all virtual worlds into
> that paradigm with agentdomains or UGAIM notions or we could step back
> a bit and consider interop between
> secondlife/opensim/Wow/croquet/wonderland and others.
> 
> consider the broader implications of virtual worlds beyond just our
> current paradigm such as WoW/croquet/wonderland and identify the
> minimum definition of network "plumbing" with that in mind?
> 
> Charles
> 
> 
> 
> ______________________________________________________________________
> I said "AWG had no active contributors that were also active
> developers of libSecondLife/libOpenMetaverse or OpenSim during the
> time the OGP protocols were designed". The participation by
> individuals that were not Linden Lab employees does not mean that OGP
> is a joint effort between Linden Lab and the libOpenMetaverse or
> OpenSim projects, or that the OGP as it is drafted has support from
> the libomv/OpenSim communities.
> 
> presence, inventory) and lumps them together into a single trust
> domain. This inhibits the development of a widely distributed
> ecosystem like we find on the web today, and is really only convenient
> for large virtual world service providers that already have a vertical
> stack of services. It also drags in the assumption that there must be
> a backend communication layer between services such as inventory and
> simulation regions.
> 
> John

---

From: Charles Krinke <[email-masked]>
Date: Wed, 18 Feb 2009 07:06:12 -0800 (PST)

This seems a very reasonable direction and discussion. Let me toss in the current OpenSim direction as a reference. 

We tend to like five server processes currently and these are split into a UserServer, GridServer, AssetServer, InventoryServer and MessagingServer.

As the situation evolves, and we seek and find a consensus, I see one of the necessary steps to finding a consensus that everyone be willing to describe and negotiation a common ground. So, thinking about Wow, Croquet & Wonderland interop with SecondLife and OpenSim seems to me a good direction to focus as it will probably allow us to get to the "what" and "how" of the plumbing and past the "why" perhaps more quickly.

Charles

________________________________
From: Kajikawa Jeremy <[email-masked]>
To: "[email-masked]" <[email-masked]>
Sent: Wednesday, February 18, 2009 5:24:54 AM
Subject: Re: [mmox] The Story So Far...

3 parts,

---

From: Lawson English <[email-masked]>
Date: Wed, 18 Feb 2009 11:31:49 -0700

> The current MMOX charter makes no reference to specific implementations such as Linden Lab's OGP, which I think is the correct approach.

The Agent Domain vs HyperGrid models can be seen as somewhat extreme 
opposites in m dimensions of some n-dimensional space. There's plenty of 
room for cooperation/collaboration/assimilation/mishhashing in the middle.

And other models might address n+1 dimensions as well.

Lawson

---

From: "Hurliman, John" <[email-masked]>
Date: Wed, 18 Feb 2009 12:41:14 -0700

The HyperGrid implementation in OpenSim today establishes a full trust link between two separate service stacks (grids). It's a very clever way of combining grids, but doesn't address how untrusted administrative domains interact with each other at all. I don't understand why you keep comparing Agent Domain and HyperGrid.

My understanding of the Agent Domain model is that it maps every trust relationship between grids to a policy decision. This is important for the business case of company X and company Y creating a partnership that is explicitly configured, but glazes over the 99.999% use case of moving from untrusted grid A to untrusted grid B. I haven't seen any work from AWG addressing the possibility of eliminating all grid<->grid communication (google.com doesn't communicate with the links I click, the browser is perfectly capable of managing its own state).

John

>From: Lawson English [mailto:[email-masked]]
>Sent: Wednesday, February 18, 2009 10:32 AM
>To: Hurliman, John
>Cc: [email-masked]
>that were also active developers of libSecondLife/libOpenMetaverse or
>OpenSim during the time the OGP protocols were designed. The "agent
>domain" concept in OGP terminology brings in a host of assumptions that
>are diametrically opposed to the goals of libOpenMetaverse and OpenSim
>(supporting millions of independent administrative domains and service
>providers).
>>
>> The current MMOX charter makes no reference to specific
>implementations such as Linden Lab's OGP, which I think is the correct
>approach.
>>
>>
>

---

From: Lawson English <[email-masked]>
Date: Wed, 18 Feb 2009 14:14:48 -0700

> My understanding of the Agent Domain model is that it maps every trust relationship between grids to a policy decision. This is important for the business case of company X and company Y creating a…

As I understand it, Agent Domain and HyperGrid approach many of the same 
issues from two directions. That's the reason for mentioning them in the 
same sentence.

Lawson

---

From: Jon Watte <[email-masked]>
Date: Wed, 18 Feb 2009 13:33:59 -0800

> the context of this group.

In my opinion, OGP is too Second Life specific to serve as a useful 
basis for a vendor neutral interoperability standard. If that is the 
basis for this IETF working group, then there's no need for me, or any 
other virtual world vendors, to be here.

Standardizing Second Life protocols might be useful for the Second Life 
sub-universe of virtual worlds, but I think trying to call it "generally 
interoperable" would be stretching the truth past bursting. There's too 
much content and too many players in production today using vastly 
different technologies for that to work.

See a different message for what I think is a great use case/scenario 
for what "interoperability" actually looks like (which I think we need 
to agree on before lower-level details like what kinds of protocols 
we'll need can be defined).

Sincerely,

jw

---

From: Suzy Deffeyes <[email-masked]>
Date: Wed, 18 Feb 2009 15:56:29 -0600

On Wed, Feb 18, 2009 at 1:41 PM, Hurliman, John <[email-masked]>wrote:

> The HyperGrid implementation in OpenSim today establishes a full trust link
> between two separate service stacks (grids). It's a very clever way of
> combining grids, but doesn't address how untrusted administrative domains
> interact with each other at all. I don't understand why you keep comparing
> Agent Domain and HyperGrid.
>
> My understanding of the Agent Domain model is that it maps every trust
> relationship between grids to a policy decision. This is important for the
> business case of company X and company Y creating a partnership that is
> explicitly configured, but glazes over the 99.999% use case of moving from
> untrusted grid A to untrusted grid B. I haven't seen any work from AWG
> addressing the possibility of eliminating all grid<->grid communication (
> google.com doesn't communicate with the links I click, the browser is
> perfectly capable of managing its own state).

For the google 2d browsing analogy, I don't need to see a representation of
other people that also happen to be visiting that same link, and I also
don't have a name and 3D representation of myself that I want to remain
consistent on my screen as I go from link to link.

In our MMOX space, it can be desirable to have a consistent representation
of self that also appears the same to others in the same region. Not always,
but for a fair number of use cases that involve teleportation it does. I'm
not sure how that can happen if we eliminate all grid to grid communication.

Maybe Agent Domain type implementations 'squirt' too much state along with
an agent that is being transferred into a region. Maybe we need to tease
that apart.  I think the actual OGP implementation right now just squirts
your name, UUID, a few bits, and desired location into the region.

Suzy Deffeyes
IBM

---

From: Charles Krinke <[email-masked]>
Date: Wed, 18 Feb 2009 14:04:17 -0800 (PST)

Now, I need to ask a question, as I dont know how WoW, Croquet or Wonderland work. And perhaps this really indicates we need a representative from each of those. That is, if those are the other worlds to be considered. I dont really know what their future usage will be in a 3D internet as we go away from the "flat web".

In any case, "Can we define a message format for avatar presence that contains fields to allow 3D interactive browsing that is reasonable for the SecondLife and OpenSim teams and also flexible enough to be useful for other teams?"

Charles

________________________________
From: Suzy Deffeyes <[email-masked]>
To: "Hurliman, John" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Sent: Wednesday, February 18, 2009 1:56:29 PM
Subject: Re: [mmox] The Story So Far...

On Wed, Feb 18, 2009 at 1:41 PM, Hurliman, John <[email-masked]> wrote:

For the google 2d browsing analogy, I don't need to see a representation of other people that also happen to be visiting that same link, and I also don't have a name and 3D representation of myself that I want to remain consistent on my screen as I go from link to link. 

In our MMOX space, it can be desirable to have a consistent representation of self that also appears the same to others in the same region. Not always, but for a fair number of use cases that involve teleportation it does. I'm not sure how that can happen if we eliminate all grid to grid communication.

Maybe Agent Domain type implementations 'squirt' too much state along with an agent that is being transferred into a region. Maybe we need to tease that apart.  I think the actual OGP implementation right now just squirts your name, UUID, a few bits, and desired location into the region. 

Suzy Deffeyes
IBM

---

From: Jon Watte <[email-masked]>
Date: Wed, 18 Feb 2009 16:34:30 -0800

Charles Krinke wrote:
> In any case, "Can we define a message format for avatar presence that 
> contains fields to allow 3D interactive browsing that is reasonable 
> for the SecondLife and OpenSim teams and also flexible enough to be 
> useful for other teams?"

Re-phrase that as "that is reasonable for all likely adopters of the 
standard" -- why special case Second Life or Open Sim?

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

---

From: "Hurliman, John" <[email-masked]>
Date: Wed, 18 Feb 2009 19:34:19 -0700

>From: [email-masked] [mailto:[email-masked]] On Behalf Of Suzy
>Deffeyes
>Sent: Wednesday, February 18, 2009 1:56 PM
>To: Hurliman, John
>Cc: [email-masked]
>       The HyperGrid implementation in OpenSim today establishes a full
>trust link between two separate service stacks (grids). It's a very
>clever way of combining grids, but doesn't address how untrusted
>administrative domains interact with each other at all. I don't
>understand why you keep comparing Agent Domain and HyperGrid.
>
>       My understanding of the Agent Domain model is that it maps every
>trust relationship between grids to a policy decision. This is important
>for the business case of company X and company Y creating a partnership
>that is explicitly configured, but glazes over the 99.999% use case of
>moving from untrusted grid A to untrusted grid B. I haven't seen any
>work from AWG addressing the possibility of eliminating all grid<->grid
>communication (google.com doesn't communicate with the links I click,
>the browser is perfectly capable of managing its own state).
>
>
>For the google 2d browsing analogy, I don't need to see a representation
>of other people that also happen to be visiting that same link, and I
>also don't have a name and 3D representation of myself that I want to
>remain consistent on my screen as I go from link to link.
>
>In our MMOX space, it can be desirable to have a consistent
>representation of self that also appears the same to others in the same
>region. Not always, but for a fair number of use cases that involve
>teleportation it does. I'm not sure how that can happen if we eliminate
>all grid to grid communication.
>

"same region" and grid<->grid are separate concepts. The idea of sharing a scene graph across administrative domains is interesting, but the current agent domain work does not include anything like that. Instead, a teleport is done from grid A to grid B where identity and appearance are the only things that need to persist. I don't see why grid<->grid communication is fundamentally necessary to transfer identity and appearance.

>Maybe Agent Domain type implementations 'squirt' too much state along
>with an agent that is being transferred into a region. Maybe we need to
>tease that apart.  I think the actual OGP implementation right now just
>squirts your name, UUID, a few bits, and desired location into the
>region.
>
>Suzy Deffeyes
>IBM
>

---

From: Dan Olivares <[email-masked]>
Date: Wed, 18 Feb 2009 21:43:58 -0500

Chiming in here.    The use case you suggested is quite interesting
Jon.   I've thought about it myself from time to time.   The major
objection that I've heard so far is that it requires a lot more work
(service calls?) to develop a shared scene graph and requires a
significant more amount of trust then an A-->B teleport does.
Ultimately, however, I hope that we can create a solution to this
issue so that 3D spaces can be shared between various implementations.

Best Regards

Daniel Olivares

---

From: Jon Watte <[email-masked]>
Date: Wed, 18 Feb 2009 21:53:59 -0800

Hurliman, John wrote:
> include anything like that. Instead, a teleport is done from grid A to grid B where identity and appearance are the only things that need to persist. I don't see why grid<->grid communication is fundamentally necessary to transfer identity and appearance.
>   

At least three reasons:

1) When I am logged into a virtual world, it's usually for a reason. For 
me, it's work -- my virtual world allows me to cooperate with remote 
workers, visualize 3D data, and have meetings that are more effective 
and cheaper than conference calls. (Customers love "cheaper" :-) If I 
were to log off my "home" virtual world, then I would lose some or all 
of those capabilities while I "went elsewhere." For example, if my 
company has a policy of recording all interactions in the world, for 
regulatory compliance, if I suddenly disconnected and connected to 
another grid, that function would not be present.

2) Object behavior is not portable. One system may use SecondLife Script 
version 2.3 for its objects. Another may use Java Runtime 1.5.6. A third 
may use Visual C++ 9.0 linkable libraries.

3) If you "grid hop" to another location, you have to have a client that 
can connect to whatever server protocol that location is using. Writing 
a "universal client" has proven to be quite quixotic for two reasons: a) 
Any real system will have to have a "home protocol" anyway to provide 
functionality not provided for in the standard, and b) re-implementing 
virtual world presence for a client as a separate channel only to use 
for interoperability isn't a good idea.

If I "grid hop," I might as well just have two clients installed (one 
that uses ClosedGardenWorld protocol 1.3, and one which uses 
WalledSpacesWorld protocol 2.7), and launch the right client for where I 
want to go -- the "benefit" of interoperability would be quite marginal; 
basically just not having to fill out a registration form for each 
world. No business will do a lot of engineering work to enable a 
scenario like that, because it delivers very little added value.

Sincerely,

jw

---

From: Jon Watte <[email-masked]>
Date: Wed, 18 Feb 2009 21:55:17 -0800

> significant more amount of trust then an A-->B teleport does.

There is no shared scene graph. Each server simulates "its" objects, and 
translates from the "interop" protocol to its internal system at the 
gateway. Think of it like a more modern version of IEEE 1278 (which has 
been a great success as far as interoperable distributed simulation goes).

Sincerely,

jw

---

From: Dan Olivares <[email-masked]>
Date: Thu, 19 Feb 2009 01:09:15 -0500

>From the technical perspective, agreed.   From a user perspective,
it's all part of the same visible world.   It doesn't matter that the
user is actually connected to 5 different servers each with it's own
scene that it's simulating in it's delegated space in the contiguous
world.

Best Regards

Daniel Olivares

On Thu, Feb 19, 2009 at 12:55 AM, Jon Watte <[email-masked]> wrote:
> gateway. Think of it like a more modern version of IEEE 1278 (which has been
> a great success as far as interoperable distributed simulation goes).
>
> Sincerely,
>
> jw
>
>

---

From: Lawson English <[email-masked]>
Date: Thu, 19 Feb 2009 00:24:02 -0700

With OpenSim/Second Life, it could, in theory, be quite a few more 
neighboring sims if your draw distance is set high enough since a sim 
only covers 256 meters while draw distrance can be set as high as 512:

n = neighbor
p = "parent"

nnnnn
nnnnn
nnpnn
nnnnn
nnnnn

And this assumes a single sim-size for all sims, and only a Cartesian 2D 
coordinate system (hence "grid") with no fun stuff like space station 
simulators or ring worlds or Dyson spheres (or MC Escher-esque worlds 
for that matter).

---

From: Jesrad <[email-masked]>
Date: Thu, 19 Feb 2009 10:28:36 +0100

The approach used in IEEE 1278 seems to differ radically from the
function OGP is assumed to permit, from a glance: as you said it lets
otherwise incompatible domains of simulation (call them grids)
exchange just the amount and type of information needed to remain
consistent between themselves.

Transposed to a VW, this would mean you can use the SL client to
connect to an SL grid, then your current simulator connects you
through to other environments (WoW, Solipsis, etc.) and does the
"translation". If the "foreign" domain/grid does not support some
Agent Domain services or something else, then the "local" domain can
then provide its own as a substitute, while the client is tasked with
interpreting any native data that rides through (like 3D
representation and sound format).

Is it right ? Maybe detailing a specific example would help pointing
out what should be and shouldn't be in such a protocol. (We're trying
to minimize the amount or complexity of translation required both at
the gateway and the client, aren't we ?)

---

From: Kajikawa Jeremy <[email-masked]>
Date: Thu, 19 Feb 2009 21:32:08 +0900

Is this approach where each system can provide "own proxy" for
 the non-native clients that can enter ?

This would allow the commercial systems to remain closed while
  also supporting the "open" clients as well.

But then there is the whole "mind share war" between closed and
  open systems as it is,  and I think the open systems are going to
  breach and break the closed systems eventually.

but thats just my own reading of the following...

How accurate is my reading?

---

From: Jesrad <[email-masked]>
Date: Thu, 19 Feb 2009 14:19:33 +0100

Well, I can imagine a closed VW proxying alternate/degraded models in
lieu of the actual 3D models for its internally-hosted objects and
avatars, and distorting inworld sound/video streams, so as to prevent
copyright infringement in visiting non-trusted VWs, but then the
entire point of interoperability would be lost. I cannot find much
appeal in driving a gray sphere with an hovertext reading "This would
look like a sports car if you subscribed" in lieu of the actual car
model.

Ceci n'est pas une pipe.

---

From: "Hurliman, John" <[email-masked]>
Date: Thu, 19 Feb 2009 10:28:52 -0700

>From: Jon Watte [mailto:[email-masked]]
>Sent: Wednesday, February 18, 2009 9:54 PM
>To: Hurliman, John
>Cc: [email-masked]
>> include anything like that. Instead, a teleport is done from grid A to
>grid B where identity and appearance are the only things that need to
>persist. I don't see why grid<->grid communication is fundamentally
>necessary to transfer identity and appearance.
>>
>
>At least three reasons:
>

I visit my internal homepage at intel.com and browse several other parts of the web at the same time. It doesn't require any established trust between intel.com and the rest of the web.

>may use Visual C++ 9.0 linkable libraries.

Just as some websites are powered with PHP, some use Java backends, and some have bits written in C++?

>for interoperability isn't a good idea.

I agree that the universal client solution is not an answer to interoperability. However, this seems to just be pushing the problem back to the server. Instead of a universal client we'll have a universal server that can do universal protocol translation. What if this universal server was ran on localhost? Would it become a universal client?

>scenario like that, because it delivers very little added value.

I think it's arguable whether merging the view of two worlds together has higher value than teleporting presence and content between worlds.

John

---

From: Mark P. McCahill <[email-masked]>
Date: Thu, 19 Feb 2009 13:26:51 -0500

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 [email-masked] 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?
> 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.
>
> 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
>

---

From: "Hurliman, John" <[email-masked]>
Date: Thu, 19 Feb 2009 11:49:20 -0700

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

>From: [email-masked] [mailto:[email-masked]] On Behalf Of
>Mark P.McCahill
>Sent: Thursday, February 19, 2009 10:27 AM
>To: [email-masked]
>Subject: [mmox] where is identity @ in all this?
>

---

From: Charles Krinke <[email-masked]>
Date: Thu, 19 Feb 2009 10:52:46 -0800 (PST)

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 <[email-masked]>
To: [email-masked]
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 [email-masked] 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.

     name@identity_provider

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
>

---

From: "Hurliman, John" <[email-masked]>
Date: Thu, 19 Feb 2009 12:00:16 -0700

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

>Sent: Thursday, February 19, 2009 10:53 AM
>To: Mark P. McCahill; [email-masked]
>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.
>
>
>
>to keep telling people that Mark McCahill is named Mysterio Sinister in
>Second Life - I can't easily be [email-masked] 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.
>
>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.
>
>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.
>
>> 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?

---

From: Jon Watte <[email-masked]>
Date: Thu, 19 Feb 2009 13:17:41 -0800

I think here it's important, and it does matter. The user is only 
connected to the "home" server. The servers are connected, and exchange 
the data, but the client only gets data from the "home" server (which 
includes data about the interoperating entities). How else could the 
server side entities know about the other entities in the same space?

Also, if you want to connect one client to a number of different 
systems, what do you do about UI, and protocols? If I connect to another 
system, do I suddenly have to learn the UI of that system? How would you 
even merge the UI of two different systems? Would my server-side 
activity logging work for the remote connection in that case?

Having worked on interoperable virtual worlds since 2005, virtual worlds 
technology since 2001, and studying all the succeesses and failures 
since the 1980's (Cosmo player, anyone? :-), I've come to the conclusion 
that interoperating on the back end at the semantic layer is actually 
the simplest and most straightforward solution, while simultaneously 
enabling the most compelling interoperability scenarios.

Sincerely,

jw

---

From: Jon Watte <[email-masked]>
Date: Thu, 19 Feb 2009 13:45:35 -0800

> representation and sound format).

That's about right. I think the focus on Second-Life specific proposals 
like OGP will not have success in a broader virtual world sense. While 
interesting from a technical point of view, I think it would be a 
mistake to assume that a vendor-neutral, open virtual world 
interoperability protocol would look anything like OGP.

Sincerely,

jw

---

From: Jon Watte <[email-masked]>
Date: Thu, 19 Feb 2009 14:10:45 -0800

> I visit my internal homepage at intel.com and browse several other parts of the web at the same time. It doesn't require any established trust between intel.com and the rest of the web.

But the virtual world is not the web. The virtual world requires 
interaction. It requires simple things like microphone focus. It 
requires complex things like 3D graphics and physical simulation. And, 
most importantly, the data changes in real time.

I can see a distant future where you may be browsing multiple virtual 
worlds at a time, and all of those issues are solved through "infinite 
compute power" and smart user interfaces for things like focus. But 
consider the local services: What if you have a server-side 
record/playback function you use for archival purposes?

If you want to compare to the 2D web (which is a poor comparison in my 
experience): You can view the local server as a web cache, firewall and 
e-mail server, all rolled into one.

> Just as some websites are powered with PHP, some use Java backends, and some have bits written in C++?

But that's the whole point! In web 2.0, you have two different web sites 
talking to each other, rather than having the client do the work. My 
suggestion is analogous: When object X is implemented to run on 
technology Y, it is always run by a server using technology Y; it's not 
transferred to technology Z just because I happen to be browsing the 
main frame of my page on technology Z. Trying to translate the scripting 
between Y and Z, or enforcing that things are always implemented using 
Y, is a losing proposition.

> I agree that the universal client solution is not an answer to interoperability. However, this seems to just be pushing the problem back to the server. Instead of a universal client we'll have a un…

In effect, yes. When I keynoted the IEEE MMVR workshop last year, I 
actually showed a possible peer-to-peer topology, as sitting on top of 
such as standard. However, the point is that, for the cases where 
peer-to-peer is not desirable (which we can all agree are important, 
too), the server-translated system provides for capabilities that the 
client-translated system does not.

> I think it's arguable whether merging the view of two worlds together has higher value than teleporting presence and content between worlds.

Well, let's argue that, then. I know that offline translation of content 
is worth a lot for our customers, but we have basically solved that 
problem by using a COLLADA tool chain, and supporting most of the 
Autodesk and Multigen formats. However, trying to teleport an entire 
object (with behavior) in real time will never actually work across a 
larger, interoperable virtual world, for the same reason you pointed 
out: some are implemented in C#, others in Java, and yet others in some 
language you've never heard of.

If you're only interested in interoperating between worlds that support 
the Second Life scripting language, then I think the SL AWG is the place 
for that discussion.

My point is that solving the back-end problem is actually less work, and 
provides both a better user experience, and more end-user capabilities, 
than "teleporting" between worlds. Note that the base capability of 
visiting someone else in their environment is provided by both 
proposals. It's after that that the differences start to show.

Sincerely,

jw

---

From: Christian Scholz <[email-masked]>
Date: Fri, 20 Feb 2009 00:05:08 +0100

> * 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 Exchang…

Can you elaborate what the specific problem with OAuth is? Is it that 
you'd need to authorize each and every service as a user? (the same 
problem is coming up on the web as well though if you think about data 
in all sorts of places you might want to give somebody access to)

And what are you planning to use Attribute Exchange (AX) for? We 
discussed using this in the DataPortability Group a while back for 
storing the URL to your service catalogue that way but the problem was a 
bit lack of adoption. I also tried to do some tests with myopenid but it 
seemed that I couldn't store new fields.

If it's for profile retrieval the OpenSocial REST API is IMHO a better 
fit as it's a) easier to implement and b) more discussed and already 
adopted by e.g. myspace (and yahoo is talking about it).

-- Christian

---

From: Jesrad <[email-masked]>
Date: Fri, 20 Feb 2009 12:13:36 +0100

An example: the VW Solipsis ties its authentication service to
Facebook. That lets it integrate complex social services (groups,
friends, etc.) simply by adopting the Facebook Connect service. But
then Facebook very recently joined the OpenID Foundation Board, so it
seems they'll be taking care of that particular bit of
interoperability without additional effort from the Solipsis team (and
other projects that use the Connect service).

It seems the market already chose OpenID as an authentication
standard. The common VW operation at that level seems to be:
- keep an internal user base
- automatically create a new user from existing authentified IDs that
sign in if they don't exist
- manage a specific state for these new users from "outside" (the "no
payment info on file" from SL, the "unpaid account" state from
Vendetta-Online, etc.)
- may or may not allow the creation of purely internal (not exported
to the auth provider) IDs (this may lead to conflicting IDs ? should
the outside auth service take precedence ? Is this question out of
scope ?)

On Thu, Feb 19, 2009 at 7:52 PM, Charles Krinke <[email-masked]> wrote:
> 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.
>
> authentication methods so as not to paint ourselves into a corner down the
> road a bit.
>
> Charles Krinke
>
> 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.
>
> 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 [email-masked] 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.
>
>> 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.
>>
>> 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
>>

---

From: Christian Scholz <[email-masked]>
Date: Fri, 20 Feb 2009 12:55:28 +0100

> other projects that use the Connect service).

Well, first it has to be seen if FB really opens up to use standards
instead of running their own thing. But the move to join the OpenID
foundation if of course promising.
OpenID alone is not the answer though, you can do authentication with it
 but you only have a limited way to handle your profile data esp.
because it's then bound to your OpenID provider (e.g. using Attribute
Exchange).

What people discuss right now as the so called "Open Stack" is a mix of
OpenID for authentication, OAuth for authorization and OpenSocial REST
API for reading and writing (nobody implemented write yet though) your
profile data and friend connections. PortableContacts, an extension to
OpenSocial might also come into the mix. This let's you retrieve the
address book of some user so that you can then match up friends (instead
of asking for gmail/hotmail/... passwords).

So far MySpace has implemented OAuth and OpenSocial and called it
MySpaceID, see
http://developer.myspace.com/community/myspace/dataavailability.aspx

> the outside auth service take precedence ? Is this question out of

I would say that the web sort of has settled on OpenID. That does not
mean that this should be the only method to provide but certainly it
should be one of those you can use.
How the best practice is to store openids and how to attach them to your
users is still somewhat unclear but people are actively talking about
it, e.g. at the Facebook OpenID UX summit which happened 2 weeks ago or
so. One point of discussion was e.g. also if OpenID should be URLs or
email addresses, mostly because people are more familiar with the latter.

-- Christian

-- 
Christian Scholz                          Homepage: http://comlounge.net
COM.lounge                                   blog: http://mrtopf.de/blog
Luetticher Strasse 10                                    Skype: HerrTopf
52064 Aachen                             Video Blog: http://comlounge.tv
Tel: +49 241 400 730 0                           E-Mail [email-masked]
Fax: +49 241 979 00 850                               IRC: MrTopf, Tao_T

neuer Podcast: Der OpenWeb-Podcast (http://openweb-podcast.de)
new podcast: Data Without Borders (http://datawithoutborders.net)

---

From: Kajikawa Jeremy <[email-masked]>
Date: Fri, 20 Feb 2009 20:51:29 +0900

Didn't the Croquet people try to co-opt your time in getting you to
develop
 a module for them ? :)

Apart from the above,  I agree with regards the use of OpenID and I am
  trying to expand the AgentDomain I am building to include an
incorporated
  UserAccount service that is OpenSIM compatible and have setup an
  osgridsvc.appspot.com implimentation that I want to hand over to the
OpenSIM
  group,

  Im also going to be pushing the code upto the repository I setup on
the forge site.

  I hope when It is complete (usable on and off GAE using WSGI) that it
is useful.

Im also going to include a MySQL/SQLite to site transfer tool as well.

Belxjander (Jeremy / SecondLife+OSgrid=Freija.Yoshikawa)

---

From: "Hurliman, John" <[email-masked]>
Date: Fri, 20 Feb 2009 11:24:45 -0700

>Sent: Thursday, February 19, 2009 3:05 PM
>To: Hurliman, John
>Cc: [email-masked]
>> 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.
>

OAuth seems to be solving a different problem. OAuth is great for putting identity+authorization into a token, but in many cases (at least in the virtual world scenario) your identity provider and the authorization provider for a resource are two separate domains. What is needed is a way to pass around identity in a token, which is what the OpenID Token Exchange protocol does. The fact that every authorized token request in OAuth flows through the end user is great for authorization requests and the use cases it was designed for, but makes it a non starter for providing a temporary identity-only token between services.

The use case I've drawn up for virtual worlds involves a user, an identity provider, a content provider, and a world simulator (doesn't matter how many separate services this is, assume a single trust domain for now). The user tells the world simulator that it has an identity at http://identityprovider.com/user which initiates the OpenID authentication sequence. Logging into a world simulator is implicitly giving it access to a minimum set of your profile information on the identity provider and appearance data on the content provider. This is facilitated with an identity token request from the world simulator to the identity service, and that token is passed to the content service. The content service can then confirm the validity of the token and grant access to a minimum set of content.

OAuth definitely has wider adoption than OpenID Token Exchange, and if you see a way to make this scenario work with OAuth (without too many contortions) please let me know.

>adopted by e.g. myspace (and yahoo is talking about it).

I doubt any identity provider will let you start storing arbitrary data on their server. My understanding of AX is that identity providers can map their existing identity+profile information to well recognized AX fields and provide whatever information they have. Avatars will likely require unique fields, such as the URL of appearance data. If OpenSocial provides a better or better adopted way of doing that then it's worth investigation. It might also mean that it's premature to standardize on one or the other. That seems to leave the options: 1) leave attribute retrieval out of scope (doesn't do much to solve interoperability), 2) make up our own standard based on LLSD/LLIDL (makes the situation even worse, and goes against the proposed goals of the draft MMOX charter), or 3) support multiple implementations (increases the complexity of the spec, and creates excess cruft once one of the competing proposals dies out).

---

From: Gareth Nelson <[email-masked]>
Date: Sat, 21 Feb 2009 00:12:23 +0000

> for Mysterio Sinister before I got there.

Correct me if i'm wrong, but isn't this the problem the OGP agent
domain was designed to resolve?
I propose an agent domain which itself allows multiple methods of authentication

---

From: Lawson English <[email-masked]>
Date: Fri, 20 Feb 2009 17:38:25 -0700

> I propose an agent domain which itself allows multiple methods of authentication

Authentication itself was left pretty much under-defined to this point 
in that OGP, with the assumption that different agent domains might have 
different authentication schemes. Another thing to keep in mind is that, 
regarding IP issues, different girds/worlds might have different 
standards for what is an acceptable authentication scheme.

L

---

From: "Meadhbh Hamrick (Infinity)" <[email-masked]>
Date: Sat, 21 Feb 2009 00:02:16 -0800

mmm... the mechanism for authentication _is_ defined in OGP in an  
unambiguous way. the mechanism does not directly support OpenID,  
Kerberos, sxip, shibboleth, etc. (though it's possible to hijack the  
shared secret auth scheme to do OpenID.)

but yes. OGP/Auth as it is currently written defines MECHANISM, not  
POLICY. For instance, the OGP support in the beta grid does not  
support the PKCS12 auth scheme. This was a POLICY decision. If it did,  
it would support it in a way that was verifiably consistent with the  
OGP/Auth spec.

it might be useful to think of OGP as a "bag of tools" for doing  
things like authenticating yourself, placing yourself into a  
particular simulation context, moving around, sending group messages,  
establishing voice channels, etc. it does not stipulate that each  
compliant virtual world implement each and every technique. however..  
before you could hope to have interoperability, you would have to  
publish an "interoperability profile" which defines each of the  
features a particular world implements.

there are examples of such critters... X.509/PKIX, X11, RTP and even  
HTTP to a limited degree. as to the benefit of a protocol that  
provides mechanism and not policy? defining the wire protocol allows  
us to ask our friendly neighborhood open source development team to  
build a "toolbox" for virtual world interactivity. this would allow  
people building virtual worlds to confine their work to the higher- 
margin creative work that tends to "sell" such environments.

-cheers
-meadhbh

On Feb 20, 2009, at 4:38 PM, Lawson English wrote:

> Authentication itself was left pretty much under-defined to this  
> point in that OGP, with the assumption that different agent domains  
> might have different authentication schemes. Another thing to keep  
> in mind is that, regarding IP issues, different girds/worlds might  
> have different standards for what is an acceptable authentication  
> scheme.
>
>
> L

---

From: Christian Scholz <[email-masked]>
Date: Sat, 21 Feb 2009 18:00:43 +0100

Hurliman, John wrote:
>> -----Original Message----- From: Christian Scholz
>> [mailto:[email-masked]] Sent: Thursday, February 19, 2009 3:05 PM
>>  To: Hurliman, John Cc: [email-masked] Subject: Re: [mmox] where is
>> identity @ in all this?
>> 
>> Hurliman, John schrieb:
>> voice, etc. it no longer becomes feasible. OpenID Token Exchange
>> solves this problem nicely though.
>> 
>> Can you elaborate what the specific problem with OAuth is? Is it
>> that you'd need to authorize each and every service as a user? (the
>> same problem is coming up on the web as well though if you think
>> about data in all sorts of places you might want to give somebody
>> access to)
>> 
> 
> OAuth seems to be solving a different problem. OAuth is great for
> putting identity+authorization into a token, but in many cases (at
> least in the virtual world scenario) your identity provider and the
> authorization provider for a resource are two separate domains. What
> is needed is a way to pass around identity in a token, which is what
> the OpenID Token Exchange protocol does. The fact that every
> authorized token request in OAuth flows through the end user is great
> for authorization requests and the use cases it was designed for, but
> makes it a non starter for providing a temporary identity-only token
> between services.

In my understanding OAuth[1] is actually meant to just do authorization,
not authentication and is invented for the case that your identity
provider and authorization provider is in fact not the same service.
It basically lets service A access resources of service B on behalf of
the user without requiring a password.

And looking now at the OpenID Token exchange[2] isn't this actually
binding the token to the OpenID provider? I wonder what happens if that
provider does not support this extension (and my guess is that only few do)?

I agree that OAuth has it's issues in that it requires user interaction
to authorize each access. But this also seems to come up now in the
discussion about the twitter API now being changed to do OAuth only[3]
and maybe this can be brought up in the OAuth list as well. Maybe this
can also be some sort of extension to OAuth. If available the auth step
can be automatic, if not the client needs to open up some web browser.

Whatever we use in the end though I think it's important to keep
whatever provides tokens separate from the OpenID provider (actually I'd
suggest to keep everything except the authentication step away from it).

> The use case I've drawn up for virtual worlds involves a user, an
> identity provider, a content provider, and a world simulator (doesn't
> matter how many separate services this is, assume a single trust
> domain for now). The user tells the world simulator that it has an
> identity at http://identityprovider.com/user which initiates the
> OpenID authentication sequence. Logging into a world simulator is
> implicitly giving it access to a minimum set of your profile
> information on the identity provider and appearance data on the
> content provider. This is facilitated with an identity token request
> from the world simulator to the identity service, and that token is
> passed to the content service. The content service can then confirm
> the validity of the token and grant access to a minimum set of
> content.

Ok, I see the point here in that it would be possible then to at least
cerate whitelist or blacklists instead of making this public in the
first place.
The main problem is again though to be able to automatically grant
access to certain resources. This means that there maybe needs to be a
way to identify resources (like "a limited set of my profile") and some
way to exchange tokens. Maybe also 2-legged OAuth can help here (see [4]
and [5]). With 2-legged OAuth you don't need to ask the user for
permission. All what is done is that the pre-shared API key is checked.
This way you might be able to do whitelisting/blacklisting as well.

That being said, I haven't though in detail about all this as time was a
bit limited recently. I hope to spend some time soon thinking and
implementing examples though (and discussing it of course).

> OAuth definitely has wider adoption than OpenID Token Exchange, and
> if you see a way to make this scenario work with OAuth (without too
> many contortions) please let me know.

I will and maybe we can also find some solution together. I would
suggest though that if we cannot find a way to make this work with OAuth
we better use some extra service to check the token (if that's possible)
in order to not rely on features not deployed widely.

>> storing the URL to your service catalogue that way but the problem
>> was a bit lack of adoption. I also tried to do some tests with
>> myopenid but it seemed that I couldn't store new fields.
>> 
>> If it's for profile retrieval the OpenSocial REST API is IMHO a
>> better fit as it's a) easier to implement and b) more discussed and
>> already adopted by e.g. myspace (and yahoo is talking about it).
>> 
> 
> I doubt any identity provider will let you start storing arbitrary
> data on their server. My understanding of AX is that identity
> providers can map their existing identity+profile information to well
> recognized AX fields and provide whatever information they have.
> Avatars will likely require unique fields, such as the URL of
> appearance data. If OpenSocial provides a better or better adopted
> way of doing that then it's worth investigation. It might also mean
> that it's premature to standardize on one or the other. That seems to
> leave the options: 1) leave attribute retrieval out of scope (doesn't
> do much to solve interoperability), 2) make up our own standard based
> on LLSD/LLIDL (makes the situation even worse, and goes against the
> proposed goals of the draft MMOX charter), or 3) support multiple
> implementations (increases the complexity of the spec, and creates
> excess cruft once one of the competing proposals dies out). 

I doubt the same ;-)
But note that your OpenID provider does not necessarily be your primary
source for profile information. But I agree that OpenSocial does not
have all necessary data available and in fact it should be more
extensible in it's nature. Right now it really seems like the sum of all
possible fields of all the social network providers involved in the effort.

As for AX IMHO it's bound again a bit too much to the OpenID provider
and maybe also means that cannot support other means of authentication.

I also actually think that e.g. the appearance URL should not be coming
from your profile but a separate service catalogue (e.g. based on XRDS)
which lists things like your profile URL, your special VW related
services and all other possible services. Using such a catalogue would
also enable us to be flexible in what services to support for various
tasks. You could even list multiple services with priorities and the
client can check what is supported for each VW.

That all being said it's probably all too early to discuss in all that
detail as we first need to have that charter. But the topic definitely
is a hot one not only in the MMOX context but also the web context in
general.

[1] http://oauth.net
[2] http://dev.aol.com/OpenidTokenExchange
[3] https://twitter.pbwiki.com/oauth-desktop-discussion
[4] http://sites.google.com/site/oauthgoog/2leggedoauth/2opensocialrestapi
[5]
http://groups.google.com/group/oauth-extensions/browse_thread/thread/d46f4775d25e0c9d