NG Design Document/World Federation

From Rex community wiki

Introduction

A single World Simulator is capable of streaming a real-time 3D virtual environment to a user-agent without much difficulty. However if we intend to arrange simulators in complex distributed deployments spread across the Internet, scalable to millions of users, we will need more infrastructure.

World Federation means organizing sets of simulators into manageable groups, so they are secure, scalable, and easy to administer. For this task we have selected Cable Beach Project from Intel Research.

Cable Beach is implemented in C#, and is already integrated deeply with OpenSimulator. However in the coming months we see expect it will continue to see integration with other virtual world servers.

Cable Beach is a burgeoning standard in making Virtual Worlds come together, and makes it all happen with very little work from realXtend. What modifications we do need in order to make it fit our purpose, can be implemented as simple modular extensions to the core framework.

Identity and Authentication

A trusted system for identity management is the central building block of authentication and authorization systems, and thus system security.

Yet in a truly distributed environment, where virtual worlds may be operated and managed by several distinct entities who may or may not have preexisting trust relationships, there is no central authority who can verify a given identity. How then could a user migrate from one separately administered world to another, bringing his resources (such as his Avatar) with him, in a safe and secure manner?

Thankfully there is already an existing standard for distributed identity, used extensively on the web already, called OpenID.

OpenID specification:

• http://openid.net/specs/openid-authentication-2_0.html
• http://openid.net/specs/openid-simple-registration-extension-1_0.html

It should be clearly noted that OpenID says nothing about cryptographic security or creating trust domains. It speaks only of distributed identity management, it's up to the implementer to fill in the details necessary to make it secure.

Overview

A complete picture of how OpenID works is beyond the scope of this document. However we can try to give a brief sketch.

OpenID defines three parties to a transaction: the user-agent, who wishes to assert his identity; the service provider, who requires an identity to render a service; and the identity provider, who verifies the asserted identity on behalf of the user-agent.

OpenID is implemented over HTTP.

1. user-agent sends his identity as a parameter to a request to the service provider
2. service provider retrieves a document associated with the identity that contains the URL of the identity provider
3. user-agent is redirected to the identity provider, where he performs some action in order to prove his identity to the provider
4. user-agent is redirected to the service provider, where he delivers the credentials given by the identity provider upon successful authentication
5. service provider verifies those credentials directly with the identity provider

Authentication

Currently the end-user verifies his identity with the service provider by means of a simple shared secret, such as a password.

In the future this will be replaced by something cryptographically secure, such as using public-key infrastructure.

Trust

Since it's easy for anyone to establish their own identity provider (by design), it would be meaningless to accept just any authentication over OpenID. An administrator must have tools to define a trust network, such as white or black lists for identity providers.

Usability

Many implementations of OpenID pose usability problems. End-users find a protocol labor intense and are confused by all the redirection. However it need not be necessarily so.

The client viewer will implement a key ring for holding identities and associated credentials, which will enable automation of a large part of the protocol.

Implementation

realXtend Server Platform will ship with its own C# implementation of OpenID. The purpose is to ensure that all of the above extensions are integrated in one solution, for easy deployment and management.

Content Distribution and Management

The volume of digital content in a modern virtual world system demands two competing priorities:

1. scalable high-volume content distribution, optimized the computer friendly
2. simple and intuitive content management, optimized to be user-friendly

Asset Distribution

An asset is defined to be a static binary blob of data that makes up a discrete piece of a work of digital content. The job of our asset distribution service is to efficiently get assets from their storage location to the end user as quickly as possible.

Current thoughts on a design for an asset service can be found in the Asset Service Working Group.

Inventory Management

Inventory is defined as a collection of assets that belong to a defined owner. Inventory has the semantics of a filesystem, and is the principal unit of organization from the end-user perspective.

Current thoughts on a design for an inventory service can be found in the Asset Service Working Group.

Grid Federation and Management

Historically, a grid has been defined as a self-contained, centrally administered, collection of virtual world services; assumed to define a unitary trust domain that generally not be crossed.

To support a large distributed grid deployment, where users and their resources may move freely among worlds or grids, we must clearly demark trust boundaries and the semantics of crossing them.

While we generally consider the most complex case, where services are distributed and untrusted, simpler cases can be derived by assuming an existing trust relationship.

Trust Domain

A trust domain is defined and administered by a World Server. The World Server defines the semantics of entering the trust domain for both user agents and world simulators.

World Simulator Federation

A world simulator enters the trust domain administered by a world server by registering for a X.509 certificate for which the world server is the Certificate Authority. User-agents logging into a world would be able to check the validity of a simulator certificate, to verify whether the simulator is trusted.

User-Agent Login

A user-agent enters the trust domain administered by a world server by initiating a login procedure with the world server. The user-agent asserts an identity, and if the identity server is trusted by the world server, and the user-agent successfully authenticates with the identity server, then the user-agent is trusted by the world server.

Service Discovery

To enable in-world resources associated with an identity to travel with the user as he moves world to world, we must have a means for the new world to discover the user's existing resources. In specific, the new world must be able to find a description of the avatar and the location of its inventory.

After the user-agent successfully logs in, the World Server initiate service discovery with regard to the user's identity. Stored within an XML file posted by the identity server, are URLs pointing to the avatar and inventory storage. Also, any capabilities that the simulator will need to take certain actions on the user's behalf, will be stored within a map on the world server, which can be queried by the simulator that the user has logged in to.