John Hurliman

A Brief History of VWRAP

Following the popularity of Linden Lab’s online virtual world Second Life™, open source movements began implementing the Second Life™ networking protocols to create automated avatars, lightweight viewers, and eventually a complete replacement for the virtual world servers called OpenSim. Around the same time OpenSim was reaching a stable release, Linden Lab began development of a “grid-in-a-box” product, a standalone version of the same software that powered the larger Second Life™ world. It became clear that the single-world, single-provider model Linden Lab created would soon give way to dozens, thousands, even millions of independently owned and operated virtual worlds.

It also became clear that the current protocols and client software would not provide an adequate user experience in this new paradigm. Imagine having to create a new account, customize an avatar, and upload any important virtual items to each world as you hop between worlds like you would open tabs in a web browser. Along with usability concerns, new use cases for operating a virtual world appeared. The classic model for building a virtual world consists of a set of world services: content hosting, user authentication and session tracking, inventory management, instant messaging, etc. and a pool of virtual world simulation nodes (commonly referred to as simulators) that make up the virtual space you build in and walk around. Both Linden Lab and participants in the OpenSimulator project looked to extend that model by allowing the virtual world services and the simulators to be owned and operated by separate organizations.

In the summer of 2008, a joint development effort between Linden Lab, IBM, and volunteer Second Life™ residents attempted to solve the latter problem of the trust domain split between world services and spatial simulation. This group produced the first working example of the Open Grid Protocol (OGP). OGP defines an Agent Domain (AD) that encompasses all of the previously mentioned services such as inventory¹, messaging, session tracking, and a Region Domain (RD) where the simulators live.

Momentum picked up around this new effort, and by spring of 2009 the Massive Multiplayer Online Interoperability (MMOX) IETF group was created and co-directed by Linden Lab and IBM. The scope of the group was criticized, as it was pointed out by participants that the goal was not global interoperability between all virtual worlds and MMOs, but basic interoperability between virtual world services that followed a similar model to Second Life™. In light of this, the new OGPX IETF group (named after the Open Grid Protocol work) was formed. The group name was later changed to Virtual World Region Agent Protocol (VWRAP) to reflect that it is a larger undertaking and more widely usable than the original OGP proposal. As of today, the existing OGP documentation is considered canon until new drafts are published under the VWRAP name.

A Brief History of Cable Beach

While OGP focused on the trust split problem between world services and world simulation, I led the Cable Beach research project in Intel’s Virtual World Infrastructure group to investigate the user experience problems of having millions of independent virtual worlds with fragmented content, identity, and accessibility. The research also looked at scalability problems in virtual worlds and looked to the web for solutions to content distribution, identity management, and delegated authorization. After reviewing and experimenting with various federated identity protocols, authorization delegation protocols, and seeing how these could work with scalable content delivery systems and the current virtual world protocols, OAuth WRAP was settled on. OAuth WRAP is a simplified version of the OAuth protocol that includes support for rich clients (such as the Linden Lab viewer) or Javascript-only clients, making API access and Facebook Connect style logins much easier to implement. In contrast to the complex OAuth 1.0a spec that’s implementation is best left to security experts and heavy peer review, WRAP leaves most of the security to the underlying transport protocols and can be implemented in an evening. The WRAP work is also feeding into the OAuth 2.0 spec that is being hashed out in an IETF working group alongside VWRAP.

Bringing it All Together

By the end of 2009, the OGP/VWRAP and Cable Beach projects reached a point where it became feasible to merge the two. The current OGP/VWRAP work does a great job of fleshing out the relation between virtual world services and virtual world simulators in separate trust domains, while Cable Beach adds trust establishment between separate Agent Domains. This paves the way for single sign-on identity, anonymous or semi-anonymous virtual world tourism, cross-world inventory access, and bridges the gap between virtual worlds and web apps through OAuth access to APIs. Draft implementations in C# and PHP are being developed to work with the OpenSim platform and Linden Lab viewer. These implementations will be available in the coming weeks, and will be running live on Intel’s ScienceSim grid for testing.

Protocol Details

If you are interested in joining the VWRAP efforts or just want a closer look at the technology under the hood, read this section. Otherwise, you can skip ahead to the conclusion.

LLSD, REST, and Capabilities

The core of OGP/VWRAP is a set of best practices that rely on existing work. Linden Lab Structured Data (LLSD) is a common type system that makes it easy to deal with data types common to virtual worlds in a standard way across languages and over the wire using JSON, XML, or binary serialization formats. LLSD is used as the wire format, while HTTP and REST semantics define the endpoints. A specific type of capability is defined: an opaque URL that contains a hard to guess sequence of digits. Capabilities are used to attach identity and authorization information to a request and to map the request to an internal protected resource. A common example of this is in Google Docs, where you can generate a URL that can be shared with friends and has certain access rights attached.

Agent Seed Capability

Another common pattern in OGP/VWRAP is the seed capability. When a user is successfully authorized to access one or more services, a single capability URL is generated that can be queried for more capabilities. This keeps a clean separation between the authorization service and the protocol negotiation that follows when a client chooses which capabilities to request and the server chooses which of the requested capabilities to grant. The successful result of logging in to an Agent Domain is an Agent Seed Capability, which in turn grants access to session information, virtual world services, and brokers the connection to a region domain and “rezzing” your avatar in a simulator.

Delegated Agent Seed Capabilities

The Cable Beach research adds the concept of a delegated seed capability, which has limited authorization and is handed to another Agent Domain instead of directly to a user. Through OAuth WRAP, a user authorizes an AD for access to one or more services offered on another AD the user has an account on. The result of the authorization is the delegated agent seed capability, meant to be delivered to the AD requesting service access. This allows the AD you are logging into to then make policy decisions about where to retrieve your identity information from, which inventory or messaging service you will use for access to a world, or even what services are required from a remote AD before login is allowed. It’s now possible to run an independent virtual world that does not allow any local account creation or inventory hosting; you must show up with an existing identity and inventory service to login.

Conclusion

While 2009 yielded a lot of interesting research and use cases for the next generation of virtual worlds, 2010 is going to see a flurry of code implementing these ideas and building bridges between various worlds and services. Also look out for lots of discussions on high level virtual world policy. Building a federation of worlds with adequate protection for content creators is a top goal for many, while drafting policies to maintain a safe and consistent virtual world across many different Region Domains will be a priority for OSGrid and other similar open worlds.

¹ In this example, I showed inventory as a service in the Agent Domain. However, inventory could be moved to the Region Domain or multiple inventory services could be served from both the AD and RD.

(This is a repost of my blog entry at http://software.intel.com/en-us/blogs/2009/02/18/approaching-virtual-world-interoperability/)

Several new developments are brewing in the metaverse. The Massive Multiplayer Online Experiences IETF group has started to form, co-chaired by Linden Lab and IBM. Linden Lab has started publishing standards drafts for virtual world interoperability. OpenSim has started exploring linking grids together with HyperGrid. The topic of virtual world interoperability is at the forefront of many people’s minds. Due in part to the success of the web model (everyone can run their own website), individuals and businesses are waiting for the opportunity to run their own virtual world simulation, content development or storage business, spatial search engines, or maybe a mashup service that twitters virtual world activity. But before this can happen, the barriers need to be broken down between the walled garden virtual worlds of today and allow virtual concepts (identity, persistence, content) to move between worlds. How we get there is the topic of a heated debate.

First, some definition of terms. When I talk about multiple virtual worlds or multiple grids, I’m referring to multiple (independent) administrative domains. Intel has a vast set of web services that they offer under a single administrative domain at intel.com. I have my own personal blog and an OpenID service at jhurliman.org, my own administrative domain. This blog links to both intel.com and jhurliman.org, creating a possible interaction for the reader with those domains. Virtual world interoperability is about exploring the possible interactions across virtual world administrative domains. Even the simple concept of linking raises questions about carrying avatar identity and appearance across domains, and the complex topic of content transfer touches on nearly every hot security issue from DRM to webs of trust.

It always helps to start with a use case to ground discussions in reality. In an interview with Reuters, David Levine from IBM coined a popular use case that has helped shaped the conversation around virtual world interoperability. “Success in this space means killing a dragon and taking its head to another grid, slapping it down in a nightclub and having a disco,” he said. To map this back to virtual world interoperability terms, the use case would be obtaining some content in one administrative domain and transferring it to another administrative domain. There is an implicit notion that you have to obtain the content in administrative domain A before “slapping it down in a nightclub” in administrative domain B. In other words, preserving the scarcity (and therefore preserving some value) of content across administrative domains.

Preserving scarcity of a virtual good across administrative domains brings up a number of issues. Why is that content scarce in domain A? Do the same reasons for scarcity exist in domain B? The content may be the result of a difficult quest in the fantasy world of A, but how do you preserve the meaning in domain B and make it more than just another disco decoration?

Solution #1: Let the courts decide

In this approach, we assume the dragon head is implicitly valuable. Possessing a dragon head has value both in world A and world B. No technical measures are used to attempt to preserve the scarcity of content. However, a set of permissions can be assigned to content, and content fingerprints and auditing trails can help track down unauthorized usage. This approach has some proven value as it’s the approach taken by Second Life, one of the most successful virtual economies, along with many web content businesses such as stock photo or 3D model vendors.

Solution #2: Move the content, reference the context

This solution assumes the content itself has no value, and all of the value exists in the contextual meaning of the content. The dragon head can be moved to a domain where it’s assumed everyone will make copies and those copies will proliferate to even more domains. However, those dragon heads can link back to something in domain A that proves a particular user completed a quest. An example of this solution is the Xbox Live Achievements. I can put a “gamer card” on any website that says what my current Xbox gamer score is, and I can copy that content and edit my gamer score to say whatever I want. However, the real value of the card is being able to follow a link from it to http://live.xbox.com/member/jhurliman, which exists inside the xbox.com domain and authoritatively confirms what my Xbox gamer score is (would be much better if it wasn’t for all this virtual world stuff).

Another version of this solution is to use cryptographic signatures to prove that domain A stated that some identity completed the dragon head quest. In the Xbox Live Achievements example, xbox.com could vouch that the jhurliman identity has a particular gamer score on a particular date. Although the implementation is different, it’s still the same solution category because it assumes the content itself has no value. Only the contextual meaning of the content is valuable. If the dragon head itself had value, there’s nothing stopping anyone from separating the content from the signature and copying it from one end of the metaverse to the other.

Solution #3: Digital Rights Management

In theory, DRM will allow content to carry an inseparable list of rights that governs usage. This is the content publisher’s utopia, as content can transfer between any administrative domains and be copied any number of times, but the original publisher has full control over when, where, and how content can be used. An example of this is Apple’s encrypted songs purchased from their iTunes store. It also means that no effort has to be spent developing virtual world interoperability standards that protect content, because the content can protect itself. The only problem is that it doesn’t work. However, a reasonable approach is to stay open to the possibility that some domains will want to implement DRM regardless of technical feasibility, or that the technology landscape may shift in the future to a scenario where it is possible.

Solution #4: Trust maps

This category of solutions supports situations where the content itself may or may not have value. The general idea is to setup virtual world grids that have trust agreements and create a list of policies for content transfer. Domain A can say “I trust that domain B will take reasonable measures (such as solutions #1 or #3) to prevent users from making unauthorized copies of the content, therefore I will allow the dragon head to transfer to domain B”. These policies are really just the technical implementation of a data sharing partnership. If Blizzard and Linden Lab want to allow content to transfer between the World of Warcraft and Second Life worlds, there is nothing standing in the way aside from a Simple Matter of Programming. Standards make the programming well defined, but selling this as virtual world interoperability is disingenuous. The other solutions attempt to solve the problem of content transfer between untrusted domains, while this solution dodges the question by growing administrative domains with explicit trust maps. Once you have have a million fantasy quest worlds and half a million casual social worlds all wanting to transfer content between each other, the N by N trust mapping fails to scale. Linden Lab’s Agent Domain and OpenSim’s current HyperGrid implementation fall into this same solution space on opposite sides of the spectrum (agent domain blacklists by default and hypergrid whitelists by default).

In Summary

None of these solutions preclude the others. In fact, solutions #1, #2, #3, and #4 can all be used in conjunction. Heated debate usually arises when one of these solutions is presented as “the” solution for virtual worlds, and a model for interoperability is presented that requires a particular solution or precludes other solutions. Whatever interoperability model finally emerges, it seems reasonable that it will support all of these possibilities and require none of them. That’s part of what makes the web so successful today.

(To try and consolidate conversation, please use the original Intel blog post to leave comments)