CableBeachProposal

From OpenSimulator

(Difference between revisions)
Jump to: navigation, search
Line 46: Line 46:
 
==Step 3: Client-Centric World==
 
==Step 3: Client-Centric World==
  
[[Image:CableBeach_Client_Centric_Login_2.png]]
+
[[Image:CableBeach_Client_Centric_Login_3.png]]
  
 
[TODO]
 
[TODO]

Revision as of 13:28, 7 April 2009


Contents

Cable Beach Proposal

Motivation

Many virtual worlds are being developed independently with a wide variety of different architectures and protocols. The current generation of virtual worlds are implemented as proprietary stacks of services, where each world is not only simulating virtual space but also providing identity services, content hosting, digital rights management, instant messaging, virtual economies, social networking elements such as groups, and many other services. We believe there are shortcomings with this approach. Specifically:

  1. The barrier to entry for creating and running a virtual world is too high. Even with popular platforms such as OpenSim, grid administrators are taking on a monumental task of overseeing many or all of the above services when only a simple world simulation is needed.
  2. The all-or-nothing approach of the current protocols prevents the development of a robust virtual world ecosystem, where many specialized services are provided. Today's large stakeholders in content hosting, content delivery acceleration, identity services, and social networking have no means of entry to the virtual worlds space.
  3. Due to the walled garden nature of current worlds, third party services such as search and digital content creation tools have been almost entirely locked out of virtual worlds.

Vision

We envision virtual world grids modeled after the current World Wide Web, with millions of independent administrative domains. Content will be spread across millions of small, independent domains as well as aggregated on large domains supporting millions of users. A rich community of value added services and the free and open exchange of content will weave the network together, much as the Web 2.0 movement is tying the web together today. Every organization can choose what services they will run themselves, what services will be provided by third parties, and which third parties will provide services. Additionally, the content rights decisions are placed in the hands of the content hosts. With the proper authentication users are free to move assets to wherever they roam.

Data services will become as important as data hosting itself. Just as search engines and content portals have changed how we use the web, services that can plug into a common interface in asset hosting will change how we use virtual worlds. Auditing services can provide an approach to rights management and traffic analytics. Existing caching techniques and services that have been built for today's web content can be leveraged for delivery of rich virtual world content.

Approach

A roadmap has been designed to provide a migration from the current OpenSim implementation of the Second Life® protocol to a decentralized service protocol. The first step will provide some of the services in a disaggregated grid and will improve the security of existing models such as OSGrid's decentralized hosting with centralized trust. The second step will remove any assumptions about tightly coupled services and present a true decentralized virtual world service platform. Step three will remove any leftover baggage by making service authentication and authorization client-centric, and potentially enable new use cases such as multiple inventory servers or content migration.

Step 1: Login With Existing LL Client

CableBeach LL Client Login 2.png

  1. This step is the familiar XML-RPC login initiated from the Linden Lab client, passing a first name, last name, and md5 hash of the password. What is new here is that the login is sent directly to the grid server for a grid, since identities are no longer tightly coupled to grids.
  2. The login is forwarded to a known identity server. Note that because the client is providing a grid server with sensitive information (md5 hash of the agent password), and it does not provide a URL for the identity server, this form of login requires the grid server and a known identity server to exist in the same trust domain.
  3. The identity server holds profile information for each identity, which includes a list of URLs for various services. For each service, a temporary access token is requested.
  4. Each service grants a temporary access token back to the identity server.
  5. The login request successfully returns back to the grid server with information about the agent, the list of services, and access tokens for each service.
  6. The grid server determines which simulator the client will start in. This may be the closest available location to a requested destination, the agent's home simulator in this grid, or the default starting location for the grid.
  7. The grid server contacts the starting simulator to prepare the login. Information about the agent, the list of services for the agent, and the access tokens for each service are given to the simulator. The grid server uses its certificate as a client certificate so the simulator can authenticate the request. The simulator checks the presented client certificate and confirms it as being signed by the grid server.
  8. The simulator contacts any services that need to be contacted before login completes. In this case, inventory information is requested from the inventory server.
  9. The inventory server checks the given access token and confirms that it is valid and not expired.
  10. The inventory server returns information about the agent's inventory.
  11. Information about the simulator (IP address, port, UDP circuit code) and the inventory information is sent back to the grid server along with a success response.
  12. Agent information, inventory information, and the simulator information are all returned to the client along with the success response.

Step 2: OpenID Login With web_login_key

CableBeach OpenID Client Login 2.png

This is the same login flow as the first diagram, but the client passes an OpenID identity URL to the grid server instead of login credentials. An OpenID login process is initiated with the identity server where the client supplies login credentials directly to the identity server. This removes the restriction that the grid server and identity server must be in the same trust domain. The list of services and tokens are carried in the OpenID response, defined as a new namespace of data.

Step 3: Client-Centric World

CableBeach Client Centric Login 3.png

[TODO]

Use Cases

Several common virtual world operations are presented below. Teleporting between two regions in the same trust domain or between domains that have shared trust, teleporting between two untrusted domains, content publishing from digital content creation tools, and content migration between untrusted domains. [TODO]

Trusted Teleport

CableBeach Hypergrid Trusted Teleport 1.png

Personal tools
General
About This Wiki