VWRAP Deployment and trust patterns
draft-levine-vwrap-deploy-00

Abstract

Architectural layering, patterns and trust points for VWRAP

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on August 10, 2010.

Copyright Notice

Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License.

Table of Contents

1.  Requirements Language
2.  Introduction
3.  Mechanisms, Services, Domains, Policy
4.  Servers, Services and Named entities
5.  Deployment patterns
    5.1.  Second Life Agent Domain / Region Domain Split
    5.2.  Standalone OpenSim Region model
    5.3.  OpenSim VWRAP + Asset reflector + Agent Service
    5.4.  OpenSim UGAIM grid model
    5.5.  Hypergrid
    5.6.  Hypergrid and Cable Beach
    5.7.  Multi-hosted asset deployment
    5.8.  Factored Service Models
6.  Possible Domain definitions
7.  Trust and policy issues
    7.1.  Policy Requirements
    7.2.  Grid Access authentication
    7.3.  Content Management
        7.3.1.  content flows through VWs
            7.3.1.1.  Content delivery models
            7.3.1.2.  multiple representations
    7.4.  Content Metadata
8.  IANA Considerations
9.  Security Considerations
10.  References
    10.1.  Normative References
    10.2.  Informative References
Appendix A.  Additional Stuff
§  Author's Address

1.  Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119].

2.  Introduction

This draft is an extension and follow on draft to OGPX layering and architectural patterns, draft-levine-ogp-layering-00

This note focuses on design patterns and architectural choices which will permit the VWRAP specifications to adapt to a wide range of deployment patterns, within the basic VWRAP remit, and support the use of policy to permit the architecture to enable virtual spaces with very different policies toward security, intellectual property, identity, and economics to share common infrastructure and to interoperate in a principled fashion.

This draft includes patterns for assembling VWRAP services into usable systems and patterns for alternative implmentations of various VWRAP services to allow varying approaches to service and content delivery. This draft is intended to focus attention on the service design choices which will allow a single specification to support a range of deployed services.

3.  Mechanisms, Services, Domains, Policy

When completed, the VWRAP specifications will define:

• a set of underlying service delivery mechanisms
• a set of services delivered over these mechanisms
• clusters of related services, called domains
• mechanisms to apply policy to specific services

The model of "domain" is not fully defined in the current specifications.Several possible approaches to defining "domains" or "clusters" are described here, in hope of stimulating agreement on a concise definition.

The most commonly mentioned partition of services into domains is the split between "agent" and "region" domains proposed by Linden Lab. This partition separates services associated with the user's identity and information, the "agent domain," from services associated with virtual space, the "region domain"

In order to discuss patterns of clustering and service delivery, it is necessary to discuss what is mean by "domain" and also look more deeply into both the notions of a cluster of services, and also discuss possible deployment patterns

4.  Servers, Services and Named entities

In order to avoid confusion, in this note, we will define a number of terms very precisely:

• Service: a named set of REST style resources which accepts a series of messages to perform a task. We explicitly do not mean a deployed service such as the Second Life(tm) service.
• Server: A computer offering up one or more named services
• Region: A named portion of virtual space. A Region is the addressable focus
• Agent: The state and services representing a user within the virtual world
• Policy: A described behavior of a service within the VWRAP specications.
• Avatar: A visual representation of an Agent within the virtual world.
• Asset: A set of digitial content with a visual and logical component which can be added to a region (and implicitly its simulatoin creating a simulated artifact. Assets include textures, Primtive objects, landscapes and related artifacts.
• Primitive Objects: A data structure describing a visual component in a simulatoin. Historically these have been constructive geometric objects in Second Life like worlds, but the VWRAP specifications assume that the set of defined primtive objects will grow to include meshes and other forms of geometric markup.
• Simulation: The process of modeling the elements of a virtual region. The computatinal processing which creates a series of sucessive scenes containing the Avatars, and Assets within a region.

5.  Deployment patterns

To motivate the discussion, we will describe several deployment patterns for VWRAP based systems. Each of these deployment patterns should be viewed as a use case for the VWRAP specifications. The specifications should provide sufficient expresivity of service endpoints, and trust boundaries to support all of the described patterns.

5.1.  Second Life Agent Domain / Region Domain Split

This deployment pattern represents the pattern Linden Lab proposed in its initial discussions on second generation architecture in 2007. It offloads any services which are not germane to managing a virtual space to an "agent" domain, focused, on the services which are specific, not to the virtual space, but the user's agent.

In this pattern, the viewer is typically connected to one or more regions, and one agent domain. The agent domain acts as a unitary focus for all services associated with the agent. When accessing other services hosted by a deployer other than the hoster of the agent domain, the agent domain acts as the trust source, managing the agent (and user's) access to other regions.

In this deployment pattern, back end services, such as assets and inventory are accessed via the agent domain, do not, inhenrently have thier own event queue or trust domain.

5.2.  Standalone OpenSim Region model

In the Standalone OpenSim deployment model, all of the services comprising a Region, an Agent Domain, and the supporting services used by these services are hosted on a single server. A single event queue may manage connectivity to the services, or several event queues, with the services being hosted as seperate processes within the server.

Historically, a standalone OpenSim represents a single fully trusted domain, where there are no seperate trust components or policies.

5.3.  OpenSim VWRAP + Asset reflector + Agent Service

In this deployment pattern, one or more OpenSim regions are hosted, each as a seperate server. An seperate agent domain acts as the trust authority, and login component for the deployment. Inventory and Asset requests are reflected from individual regions to asset and inventory services, hosted either in a standalone fashion, or as part of an OpenSim region.

5.4.  OpenSim UGAIM grid model

This is the current (Soon to be deprecated) OpenSim Grid model. In this model, a seperate login service (not an agent domain) is hosted on one server ans a collection of backend services are shared by one or more Region Simulators. The entire grid forms a single trust model.

5.5.  Hypergrid

In this model, each Region is hosted in either Standalone, or UGAIM style Grid mode. Specific links between regions are created, which define a two way mapping, permitting users to move thier avatars between the regions. Service requests related to the back end servcies for these avatars are directed back to the originating service. Trust, if any is established in the process of creating the explicit link between the regions.

5.6.  Hypergrid and Cable Beach

Hypergrid can be combined with cable beach, so that assets are fetched directly from a shared asset server, and trust between the asset server, and between the regions and the user is managed by the client directly.

5.7.  Multi-hosted asset deployment

This is a case in which there are multiple back ends supporting multiple sets of assets. Trust is established either per the Agent Domain model, between services, and the agent's agent domain, or between regions, in hpyergrid fashion, or directly between the client and the asset services, per the cable beach model.

5.8.  Factored Service Models

There is nothing inherent in the requirements of a virtual world deployment that specific back end services be clustered into two domains, nor that a single server or logical endpoint host all of the services which comprise a deployment. Cloud deployed servics may be used to host part or all of a VWRAP deployment. In such a deployment model, services deployed within a cloud may deploy one or more event queue endpoints or service and trust endopints to connect to clients.

Factoring of services is not exclusive to back end services, the agent domain, or regions. Deployment models in which regions share services, or in which the services comprising a region are deployed on a distributed computuing fabric should be supported.

6.  Possible Domain definitions

Given the above set of deployment patterns several possible ways of usefully defining "domain" seem possible.

One could conclude that the specification should ignore domain as a structuring concept and instead focus on descbing the services needed to deliver the desired results, and allow domain patterns to be entirely deployment artifacts.

One could focus on shared infrastructural elements. In such a model domains might be defined by sharing a common set of seed caps, or a common event queue.

Security and adminsitration form another possible way of deliniating domains. It is ucnlear if this differs in a meaningful way from the first choice, as adminsitrative domains tend to be purely artifacts of deployers.

7.  Trust and policy issues

7.1.  Policy Requirements

Policy decisions may be made by services on the basis of:

• End user identity token
• Requesting Service identity token
• Service specific token (Proof of license, proof of TOS signature, etc.)

In order to permit policy decisions to be made by services, a number of token may presented to the service. These tokens will likely be supported as optional additions to the protocols, inserted in slots in the protocol messages defined by the services. This permits services to optionally require additional inputs in order to satisfy thier policy requirments in a predictcable and princpled fashion.

7.2.  Grid Access authentication

One policy choice grid deployers may make, is to require a login or authentications to be made to the grid's authentication service or agent domain. Several emerging internet approaches, such as openId or OAuth are possible mechanisms which may be used to satisfy this need.

7.3.  Content Management

One of the challanges facing a virtual worlds envrionment is determiing how digital content should be shared. The VWRAP specifications split this problem into mechansisms and policies. The following sections focus on describing several approachs and the places they impinge on the mechanisms being defined in VWRAP.

Content Management includes, but is not limited to:

• Labeling content with meta data to facilitate its management
• Identifying policy enforcement points for content management
• other XXX

7.3.1.  content flows through VWs

        +-------+              +----------+                    +-------+
Insertion->| Asset Store |--"rez" --->|  Region  |--Present--->| client|
        --------+              +----------+                    +-------+

This diagram describes some of the key moments as a dgital item flows through a virtual world. The item is inserted into and stored within the virtual world's services. It is then added to a virtual world's region (rezzed), which makes it available for simulation and, finally presented to client(s) for viewing.

Notice that this is notional. How the various services are deployed and where trust boundaries might be placed is not described. Temporally the insertion, "rez" and presentation are seperable by arbitrary amounts of time (including none). Insertion may be from an external library, a tool chain, or other services. It is the moment when the content in question enters into the purview of the virtual world.

The process of adding an item to a virtual region, copies some or all of its content. This may be as little as a reference to the actual item and an extremly simplified representatoin for physical simulation, or it may be a complete copy of the item in all of its particulars. The most common implementatoin has the entire item copied to the regoin for simulation, and delivery to the client.

7.3.1.1.  Content delivery models

A range of possible represenations can be passed to a regoin for simulation. Full content can be passed to regions, or a subset of content, or only references to most content. The VWRAP specifications should permit as broad a range of content delivery models as possible.

One end of the spectrum involved passing the full content, including the full geometric description, and all the information necessary for a client to render the content, the information necessary to simulate the object at a physical level, and any scripted attachments which automate the behavior of the item.

The other end of the delivery spectrum involves passing only a URI or capability used to access the rendering information and a collision mesh,and related data for physical simulation. In such a model, the client is responsible for fetching the additional informatoin needed to render the item's visual presence from a seperate service. This fetch can be done under the credentials of the end user viewing the material, and divorces the simulation from the trust chain needed to manage content. Any automation is done on a seperate host which the content creator or owner trusts, interacting with the object through remoted interfaces.

7.3.1.2.  multiple representations

A second mechanism for managing content delivery is to provide multiple versions of an item, and pass different versions, depending on the trust level which exists between two services. Such a model can be applied at all the steps in the VWRAP protocols. An asset server may host multiple versions of an object and pass appropriate versions to requestors. A regoin coudl be sent multiple representations of an item, and pass the appropriate one down to clients based on the relationship between the client and the region. Alternative content can be used to account for degrees of trust as well as richness of a given client. Multiple representations can be combined with redirection to permit a low fidelity version to be distributed widely, with a reference to a higher quality version which can be fetched directly should the end user be authorized.

7.4.  Content Metadata

Content meta data for content management allows the content creator

8.  IANA Considerations

This memo includes no request to IANA.

9.  Security Considerations

This draft primarily defines requirements and use cases, as well as a description of policy management approaches. Policy management includes control of choices which affect security. To the extent that requirements and use cases permit poor security choices to be made when deploying services security of a deployed system could be compromised by those considerations.

10.  References

10.1. Normative References

10.2. Informative References

Appendix A.  Additional Stuff

This becomes an Appendix.

Author's Address