Virtual World Region Agent M. Hamrick
Protocol Linden Research, Inc.
Internet-Draft February 12, 2010
Intended status: Informational
Expires: August 16, 2010
VWRAP: Introduction and Goals
draft-hamrick-vwrap-intro-00
Abstract
The Virtual World Region Agent Protocol (VWRAP) defines interactions
between hosts collaborating to create an shared, internet scale
virtual world experience. This document introduces the protocol, its
objectives and requirements it imposes on hosts and users utilizing
the protocol. This document also describes the model assumed by the
protocol (to the extent it affects protocol interactions.)
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 16, 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
Hamrick Expires August 16, 2010 [Page 1]
Internet-Draft VWRAP: Introduction and Goals February 2010
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. Introduction and Motivation . . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 7
2. Virtual World Region Agent Protocol Architecture . . . . . . . 7
2.1. Protocol Objectives . . . . . . . . . . . . . . . . . . . 7
2.2. Structural Architecture and the Role of Domains . . . . . 9
2.2.1. The Client Application . . . . . . . . . . . . . . . . 11
2.2.2. The Agent Domain . . . . . . . . . . . . . . . . . . . 11
2.2.3. The Region Domain . . . . . . . . . . . . . . . . . . 13
2.2.3.1. Protocol Flows . . . . . . . . . . . . . . . . . . 14
2.3. Architectural Elements . . . . . . . . . . . . . . . . . . 15
2.3.1. Communicating Application State Using REST-Like
Resource Accesses . . . . . . . . . . . . . . . . . . 15
2.3.2. Bi-Directional Messaging with the VWRAP Event Queue . 17
2.3.3. Using Capabilities to Simplify Inter-Domain Access
Control . . . . . . . . . . . . . . . . . . . . . . . 17
2.3.4. Using LLSD to Avoid Version Skew . . . . . . . . . . . 18
3. Services Defined by the Virtual World Region Agent Protocol . 19
3.1. User Authentication . . . . . . . . . . . . . . . . . . . 19
3.2. Presence in the Virtual World . . . . . . . . . . . . . . 21
3.2.1. Establishing Presence with the Region Domain . . . . . 21
3.2.2. Moving Presence . . . . . . . . . . . . . . . . . . . 23
3.3. User and Group Messaging . . . . . . . . . . . . . . . . . 23
3.3.1. Spatial Messaging . . . . . . . . . . . . . . . . . . 23
3.3.2. User to User and User to Group Messaging . . . . . . . 24
3.4. Digital Asset Access and Manipulation . . . . . . . . . . 25
3.4.1. Manipulating Digital Assets . . . . . . . . . . . . . 25
3.4.2. Establishing Presence for Digital Assets . . . . . . . 26
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
5. Security Considerations . . . . . . . . . . . . . . . . . . . 27
5.1. Capabilities . . . . . . . . . . . . . . . . . . . . . . . 28
5.2. User Authentication . . . . . . . . . . . . . . . . . . . 28
5.3. Agent Domain to Region Domain Authentication . . . . . . . 28
5.4. Access Control for Digital Assets . . . . . . . . . . . . 29
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
6.1. Normative References . . . . . . . . . . . . . . . . . . . 29
6.2. Informative References . . . . . . . . . . . . . . . . . . 29
Hamrick Expires August 16, 2010 [Page 2]
Internet-Draft VWRAP: Introduction and Goals February 2010
Appendix A. Definitions of Important Terms . . . . . . . . . . . 30
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 31
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 31
Hamrick Expires August 16, 2010 [Page 3]
Internet-Draft VWRAP: Introduction and Goals February 2010
1. Introduction and Motivation
Virtual Worlds are of increasing interest to the internet community.
Innumerable examples of virtual world implementations exist; most
using proprietary protocols. With roots in games and social
interaction, virtual worlds are now finding use in business,
education and information exchange. This document introduces the
Virtual World Region Agent Protocol (VWRAP) suite. This suite of
protocols is intended to carry information about the virtual world:
its shape, its residents and objects existing within it. VWRAP's
goal is to define an extensible set of messages for carrying state
and state change information between hosts participating in the
simulation of the virtual world.
At its most basic level, the virtual world mirrors the reified world.
It is inhabited by people and contains objects. Objects and people
have a distinct place in the world and respond to forces external to
them. The social construction of the virtual world is also similar
to the reified world. People may meet and interact with other
people, either to complete work tasks or for simple enjoyment.
People converse, share media, and even sing to each other. A virtual
world may allow commerce or enable building of virtual assets.
Nearly the complete range of human interaction can be replicated in
the virtual world. Properly rendered, an experience in a virtual
world can carry the same impact as one in consensus reality.
To be relevant to the participant's experience, virtual worlds must
retain some characteristics of the "real world." Objects represented
in the virtual world must be rendered so they are easily processed by
the human visual cortex. At the same time they must carry sufficient
information to be consumed by participants with visual impairments.
Though virtual, objects are familiar shapes and textures. Though the
virtual world's state is maintained by abstract collections of data,
it is rendered as recognizable (though occasionally fantastical)
physical objects.
But virtual worlds are not complete mirrors for the world our
physical bodies inhabit. Virtual worlds are not limited by distance.
Given appropriate network connectivity, two virtual world
participants can interact even if they are on opposite sides of the
earth. Virtual worlds also allow participants to "play" with
physical constraints. They provide the subjective experience of
things not possible in consensus reality: participants can fly, the
effects of "death" are temporary, users may call items into
existence, examine the International Space Station, examine DNA codon
by codon, or interact with a massive works of art. And they do these
things with co-workers and friends.
Hamrick Expires August 16, 2010 [Page 4]
Internet-Draft VWRAP: Introduction and Goals February 2010
The VWRAP suite assumes hosts, potentially operated by many
organizations will collaborate to simulate the virtual world. It
also assumes that services originally defined for other environments
(like the world wide web) will enhance the experience of the virtual
world. The virtual world is expected to be simulated using software
from multiple sources; the definition of how these systems will
interoperate is essential for delivering a robust collection of co-
operating hosts and a compelling user experience. VWRAP describes
this definition. It may be used to describe the interactions between
large collections of systems simulating large virtual worlds, or
small worlds operated for the benefit of one or a few persons. It
defines a trust model to allow hosts from multiple organizations to
be used to simulate the same apparent virtual world.
VWRAP presupposes a virtual world with the following characteristics:
The Virtual World exists independent of the participating clients.
This is in contrast to some systems which "call virtual worlds
into being" as needed as a backdrop for social or task-oriented
simulation. VWRAP assumes the state virtual world is "always on"
and does not require a specific protocol to establish new virtual
worlds.
Avatars have a single, unique presence in the virtual world.
The avatar, or the digital representation of an end user in the
virtual world, has an existence that mirrors the common physical
world; avatars (like people) do not exist in two places at once.
Further, the avatar has a single, persistent identity that may be
used to render a user-specific avatar shape or as the basis for
access control.
The virtual world contains persistent objects.
Objects in the virtual world are governed by a "rational" life-
cycle. They are created, persist and are (optionally) destroyed.
The VWRAP suite assumes that multiple hosts will participate in
simulating the virtual world. Related to this assumption:
The virtual world may be partitioned.
The virtual world is envisioned as being large; so large that it
is impractical for a single system or cluster of systems to
manage avatar presence, object persistence and physics
simulation. The virtual world MAY therefore be partitioned to
move services offered by different administrative domains onto
Hamrick Expires August 16, 2010 [Page 5]
Internet-Draft VWRAP: Introduction and Goals February 2010
distinct hosts. Virtual space may also be partitioned so that
different "regions" of the virtual world are simulated by
distinct hosts.
Presence, state and simulation happens on authoritative servers.
The presence, location and physical behavior of virtual objects
and avatars are maintained and simulated by a host authoritative
for a portion of the virtual world. This is in contrast to the
"co-simulation" technique where each client maintains this
information and communicates changes to each of its peers.
Version skew between simulation hosts MUST be tolerable.
The virtual world created by VWRAP is intended to be hosted on
systems from several different administrative domains. It is
unrealistic to assume that each administrative domain will run
precisely the same version of the protocol. To protect against
"brittleness" from version skew, the Virtual World Region Agent
Protocol uses a flexible object representation system known as
LLSD. Used correctly, semantics of remote resource access may be
maintained even when the participants in the protocol do not
adhere to exactly the same revision of the protocol.
VWRAP uses Representational State Transfer (REST) style interaction
over HTTP.
Much of the protocol interaction between systems participating in
the virtual world simulation uses a request / response
interaction style. Rather than creating a new messaging
framework, VWRAP layers much of it's protocol atop HTTP.
Further, VWRAP uses Representational State Transfer (REST) like
semantics when exposing a protocol interface.
A persistent, ubiquitous identity accompanies requests between hosts
involved in the virtual world simulation.
As in the consensus physical reality, each item is assumed to
have a (largely) non-mutable identity. Unless acted upon by an
external force, objects tend to retain their identifying
characteristics (bricks remain bricks unless pulverized, etc.)
Avatars too maintain an identity that allows the virtual world to
properly render them.
Hamrick Expires August 16, 2010 [Page 6]
Internet-Draft VWRAP: Introduction and Goals February 2010
1.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 [RFC2119].
2. Virtual World Region Agent Protocol Architecture
2.1. Protocol Objectives
The primary objective of the Virtual World Region Agent Protocol is
to provide a stable, extensible, secure system for virtual world
information interchange with the following characteristics:
Identity is universal
Many network services are provided anonymously; the nature of the
service does not require identity authentication prior to it's
use. But with the increasing deployment of customizable services
delivered on the internet, identity is increasingly important.
Even services that contain information that might not be
considered "sensitive" require a representation of digital
identity if for no other reason than to match service requests
with user preferences. For example, a web page presenting
current weather information may be enhanced by remembering
locations of interest to each user. Recent work with "web mash
ups," where multiple personalized or sensitive resources are used
in concert with one another points to the utility of a
"universal" identity. The representation of this universal
identity enables independent services to cooperate to present the
facade of a unified application to the service consumer. This
allows service aggregators to more easily integrate "best of
breed" services into a consistent solution.
Universal identity is critical to the virtual world. To achieve
an internet scale virtual world, user services must be
distributed amongst multiple hosts. To achieve a compelling
experience, it must be easy for service providers to deliver
their services in the virtual world. To facilitate a compelling
social experience in the virtual world, all users must have the
ability evaluate identity information of other users. Domains
responsible for virtual world simulation MUST use a consistent
representation of identity across all their hosts; simulation
would otherwise be uncoordinated. Service providers who deliver
content into the virtual world MUST use a consistent
representation of identity to maintain the persistence of the
virtual manifestation of their service; virtual objects used in
Hamrick Expires August 16, 2010 [Page 7]
Internet-Draft VWRAP: Introduction and Goals February 2010
conjunction with these services might otherwise appear to change
state without apparent cause. Users depend on the persistent,
universal identity of other users; if an avatar's identity
changed unexpectedly, the result would be a suboptimal virtual
world experience.
Flexible presentation of protocol data
While the primary purpose of the virtual world is to simulate a
physical or social space, the tools used to access objects in the
virtual world may be varied. Using a "3d viewer" is the primary
mode of interaction with the virtual world, but other tools may
be better suited for some tasks. For instance, it may be easier
for a user to use a web browser to review avatar profile
information, or to change details of virtual objects. Further,
virtual world "mash ups" may prove to be important to some
communities. To support the web (where XML and JSON are the
lingua franca of information exchange) while also supporting
tools where binary encodings are more appropriate, VWRAP was
designed to be "presentation neutral."
VWRAP protocol exchanges are described in terms of an abstract
type system using an interface description language.
Implementations may choose to instantiate actual protocol data
units using the most appropriate presentation format. Web-based
applications may choose to use JSON or XML. Server-to-server
interactions may use the VWRAP specific binary serialization
scheme if implementers and deployers view binary encoding to be
advantageous. The decision of which serialization scheme to use
is ultimately that of the system implementer. VWRAP has been
designed to provide this flexibility to system implementers and
those tasked with deploying VWRAP compatible systems.
Flexible decomposition of concerns and ease of extension
VWRAP has been designed to allow meaningful separation of
concerns. In other words, changes in one part of the protocol
should not appreciably affect other parts.
For example, the authentication portion of the protocol is
independent of the part of the protocol that deals with instant
messaging or instantiating objects in the virtual world. In
addition to defining messages for communicating application
state, the specification also defines pre- and post-conditions.
Should one particular authentication scheme be found to be
lacking, it can be modified or replaced without affecting other
systems.
Hamrick Expires August 16, 2010 [Page 8]
Internet-Draft VWRAP: Introduction and Goals February 2010
This type of separation of concerns in the protocol specification
also makes it easy to deploy "related solutions." While VWRAP
was designed primarily to communicate the state of the virtual
world between servers and client applications, a number of
related applications also exist. E-Commerce web sites related to
the virtual world and mobile chat clients allowing instant
messaging between mobile networks and virtual world participants
are just two examples of such applications. Proper separation of
concerns allows new services to be specified and deployed without
the need to redefine existing protocol.
Resilience in the face of version skew
Core to the VWRAP protocol is the idea that different components
and services may be operated by different administrative
entities; identity management services might be operated one
business while simulation services are operated by another. In
environments where many different organizations participate,
version skew can be an important concern. VWRAP was designed to
"degrade gracefully" when two systems running different versions
of the protocol attempt to communicate.
VWRAP uses the LLSD abstract type system and the LLIDL interface
description language to describe the structure and type semantics
of elements in messages sent between systems. Because LLSD makes
extensive use of variable width, clearly delineated data fields,
services which consume protocol messages may identify and extract
only those message elements they know how to handle. While this
is not a guarantee that message semantics may be preserved in all
version skew situations, it does eliminate one important cause of
interoperability failures.
2.2. Structural Architecture and the Role of Domains
The Virtual World Region Agent Protocol assumes a division between
systems offering user / avatar oriented services and systems offering
virtual world simulation services. VWRAP is intended to be used in
an environment where services may be delivered by hosts in different
administrative domains. A VWRAP "domain" is a collection of network
hosts with the same administrative authority. "Services" are offered
by domains and are comprised of collections of related RESTful
resources. Two special classes of domains are defined. A domain
that exposes a user authentication service is an "agent domain" while
a domain exposing an object presence service is termed a "region
domain." The protocol allows, but does not require, the agent domain
and region domain to be distinct; in other words, a user's identity
may be managed by one organization while the virtual world they
inhabit may be simulated by hosts owned by a completely different
Hamrick Expires August 16, 2010 [Page 9]
Internet-Draft VWRAP: Introduction and Goals February 2010
organization.
The motivation for this split is two-fold: First, it allows systems
to scale along the two most independent axes (agent count and virtual
world size.) Second, it moves identity management out of the domain
of virtual world simulation, allowing the same avatar to be easily
used in virtual world simulations managed by different administrative
domains.
Each domain offers services to authenticated peers: user
authentication, avatar and object presence, physics simulation,
digital asset hosting, group messaging, etc. User authentication and
avatar presence define the agent domain; they are it's raison d'etre.
Physics simulation and object presence define the region domain.
Other services are assigned to the agent or region domain according
to the expected scaling behavior, though their presence in a
particular domain does not imply a hard and fast rule they may only
exist in that domain. Digital assets, for instance, are expected to
generally be under the administrative control of an agent domain.
The digital asset service is thought to be an "agent domain service."
However, some deployers may find it convenient to define assets
belonging to a specific region as being a "region domain service."
It should also be noted that a client may consume services from
multiple agent and region domains. The agent domain responsible for
a user's profile and presence information may delegate responsibility
for digital asset services, group messaging or user to user voice
communication to a third party domain. It is expected that different
parts of the same virtual world may be simulated on hosts from
distinct region domains.
Hamrick Expires August 16, 2010 [Page 10]
Internet-Draft VWRAP: Introduction and Goals February 2010
+--------------------------+
| agent domain |
| |
| +----------------+ |
+------->| agent host |-+ |
| | +----------------+ |-+ |
| | +----------- ^ --+ | |
+-------------+ | | +--------- | ----+ |
| |<----+ +---------------- | -------+
| client | |
| application | |
| |<----+ +---------------- | --------+
+-------------+ | | region domain | |
| | v |
| | +-----------------+ |
+------->| region host |-+ |
| +-----------------+ |-+ |
| +-----------------+ | |
| +-----------------+ |
+---------------------------+
Figure 1: Protocol Flows in VWRAP
2.2.1. The Client Application
VWRAP presumes the virtual world is simulated for the benefit of
human users. Whether that human is operating a "viewer" application
to render the virtual world, or using a web interface to perform
routine maintenance tasks, the user is expected to be operating
software outside the administrative control of either the agent or
region domain. VWRAP makes no assumptions about client software save
it adheres to the described protocol.
2.2.2. The Agent Domain
The Agent Domain is the administrative entity that operates systems
managing information about agents (i.e. - people) and related
concepts. The agent domain is responsible for the following data and
tasks:
o User and Avatar Profile and Identity Information
Virtual worlds are social spaces, used to interact with people.
Information like the avatar's name, online friends and co-workers,
group membership, personal and public notes and a user's list of
"interesting places" in the virtual world are examples of the
types of avatar profile information.
Hamrick Expires August 16, 2010 [Page 11]
Internet-Draft VWRAP: Introduction and Goals February 2010
The agent domain may also wish to store information about the
user: account name, contact information, billing information, etc.
o User Authentication
The first step in interacting with the virtual world is to
authenticate the user's credentials (thus proving the user's right
to control the avatar.)
Some system developers are interested in supporting completely
anonymous avatars in the virtual world. Support for this feature
is an option left to individual agent domains, but it should be
mentioned that even if an agent domain wishes to support
anonymity, the "authentication" step is required. In addition to
demonstrating the user's right to control an avatar, the
authentication step reserves server resources for use by the
avatar. (see the discussion about seed capabilities later in this
document.) Even if an agent domain wishes to support anonymous
avatars, there is still a need to provide session specific shared
secrets to ensure that anonymous avatars may not be "hijacked" by
malicious virtual world participants.
o Avatar Appearance Information
Avatars in the virtual world are generally three dimensional
figures represented using constructive geometry or polygon meshes.
This information is of critical importance to client applications;
without it, it cannot render the avatar.
o User Groups
Because virtual worlds are (often) social spaces, many systems
support user groups to facilitate messaging and permissions
amongst avatars who share similar interests.
o Individual or Group Text and Voice Chat
In keeping with the theme of virtual worlds being social spaces,
agent domains may wish to support text, voice or even video chat
between two users or amongst a group of users.
o Digital Assets at Rest
The virtual world is filled with virtual objects: conference
tables, houses, airships, dragons, etc. These objects may or may
not be instantiated in the virtual world. When objects are "at
rest" or not being simulated in the virtual world, objects that
are owned by a particular user are stored in an asset server
Hamrick Expires August 16, 2010 [Page 12]
Internet-Draft VWRAP: Introduction and Goals February 2010
associated with the agent domain.
o Avatar Presence
When a user authenticates themselves and wishes to interact with
the virtual world, the user's avatar presence must be established.
Simulating a user's avatar is a task shared by the agent domain,
the region domain and the client application. The agent domain is
responsible for establishing the user's presence in the virtual
world simulated by the region domain, and to provide information
about the avatar so it may be properly rendered.
2.2.3. The Region Domain
The Region Domain is the administrative entity that operates systems
managing information about virtual land and related concepts. The
region domain is responsible for the following data and tasks:
o Object Presence
The state of objects in the virtual world (landscapes, avatars,
virtual "things") must be communicated to all participants. It is
the responsibility of the region domain to keep track of each
object's state. The landscape can change; clouds in the virtual
sky may move and change shape; virtual people may move around and
virtual "things" can undergo any number of state changes. The
region domain is responsible for receiving input from virtual
world inhabitants, evaluating how that input changes the state of
objects in the virtual world, and then communicating those state
changes to other observers.
o Physics Simulation
Simulating the physical behavior of objects in the virtual world
is a core feature of any virtual world. Regions may choose "earth
like" conditions, or may modify gravity and atmospheric settings
to create the experience of being on a different planet. Still
other options include simulating quantum effects seen at very
small scales or the large scale relativistic effects seen on
galactic scales. Whatever the "physics" involved, it is the
individual hosts in the region domain tasked with the simulation.
o Effects of Programmatic Changes
(aka "scripting.") Some virtual worlds allow users to modify the
state of objects using simple programming languages. The region
domain is generally responsible for managing and executing scripts
that modify the state of objects.
Hamrick Expires August 16, 2010 [Page 13]
Internet-Draft VWRAP: Introduction and Goals February 2010
o Region Specific Asset Storage
Though most "assets at rest" are associated with an avatar, it is
conceptually appropriate for some items to be associated with a
region; textures associated with landscapes, for instance. Or in
some situations, the operator of a region may wish to bind
"sensitive" resources to the location to ensure they do not follow
region visitors to regions outside the originating region's
administrative authority.
2.2.3.1. Protocol Flows
VWRAP defines protocol between the three architectural components
above: the client application, the agent domain and the region
domain.
User authentication
Before the agent or region domain expose service endpoints
providing access to sensitive resources, the user operating the
client application must be authenticated. The VWRAP Trust Model
and User Authentication [I-D.hamrick-vwrap-authentication]
specification describes the process of authentication between the
client application and the agent domain.
Digital Asset Access
Responsibility for digital assets is shared between the agent and
region domains. Digital assets "at rest" may be stored in an
asset server associated with an agent domain. The agent domain
exposes an interface allowing an asset's owner to manipulate some
of that asset's metadata. The region host (or simulator) uses
the same interface to retrieve the digital representation of the
asset so it may be scheduled for simulation. Though the
interface is the same, the asset server may trust the region host
with sensitive data that may not be exposed to the client
interface. After the asset is "rezzed" in world, the region host
exposes an interface client applications use to receive a
description of the asset and updates to its state.
Avatar Placement and Movement
After a user is authenticated, their avatar may be placed into
the virtual world (a process described as "rezzing".) After the
avatar is "rezzed in-world", responsibility for its simulation
may move from one region host to another. Initial placement and
movement in the virtual world is an intricate interaction between
hosts in the agent domain (which maintain information about the
Hamrick Expires August 16, 2010 [Page 14]
Internet-Draft VWRAP: Introduction and Goals February 2010
avatar's presence) and hosts in the region domain (which simulate
the avatar and communicate its actions to client applications.)
Initial placement is initiated by the client application,
communicated to the agent domain which then communicates the
request to the region domain on the client's behalf. Movement is
usually initiated by the client and communicated to the region
domain. If an avatar moves out of the virtual world region
managed by a particular simulator and into a new simulator, the
client must initiate the transit to the new simulator. The agent
domain then contacts the new region, moves the avatar's presence
there and removes it from the initial simulator.
Object Update
When an avatar initially enters a region, the agent domain
provides it with an interface it may query on the region host to
begin to construct the scene graph maintained by that simulator.
Object state changes (movement, rotation, texture change, etc.)
are communicated to the client application from the region host
using a related interface.
2.3. Architectural Elements
VWRAP utilizes a number of "architectural motifs" or recurring design
patterns. Most notably they include:
o exposing application state via RESTful resources
o using URIs to represent the address of application resources
o using HTTP to "carry" message oriented protocol data
o defining application state transitions and accesses with an
interface description language (called LLIDL)
o using an abstract type system (called LLSD) to define access
semantics of fields in protocol messages
o using multiple "serializations" of the abstract type system to
support different categories of consumers; defined serializations
include XML, JSON and Binary.
2.3.1. Communicating Application State Using REST-Like Resource
Accesses
Contrary to popular opinion, not ALL virtual world interactions must
be real-time exchanges. Many common activities like user
authentication and texture and object transfer do not require "real
Hamrick Expires August 16, 2010 [Page 15]
Internet-Draft VWRAP: Introduction and Goals February 2010
time" semantics in the same way that applications like video-
conferencing and Voice Over IP (VOIP) do. While it is generally a
better experience if textures download quickly, if they are delayed,
it does not have the same ramifications as if a voice packet in a
VOIP system were delayed. Additionally, some interactions with the
virtual world are strongly reminiscent of the request / response
semantics used by popular protocols (like HTTP, POP3, etc.)
Because many protocol exchanges in the virtual world may be
represented as non-real-time request / response interactions, VWRAP
"reuses" the messaging semantics of HTTP. The justification for this
is simple. Were VWRAP to not use HTTP, many of the features of HTTP
would need to be re-invented or at least re-specified. Features like
the use of mime types to identify payload structure; the use of
message headers to modify the request or response and the use of URIs
to address and identify resources. HTTP also has the benefit of
being well supported by tools vendors and well understood by
manufacturers of networking equipment.
Protocol exchanges in VWRAP that utilize request / response semantics
are described using the LLSD / LLIDL abstract type system
[I-D.hamrick-vwrap-type-system]. LLSD defines type semantics for
elements in a protocol data unit as well as rules for converting the
data into a serialized form suitable for transmission across the
network. VWRAP defines HTTP (and HTTPS) as the transports for
serialized messages.
Addressable protocol endpoints in VWRAP are represented as URIs
[RFC3986]. Protocol endpoints generally address RESTful resources.
The VWRAP protocol uses HTTP verbs to provide read and write access
to resources which represent the application state of the remote
peer.
To recap, the objective of VWRAP is to communicate application state
about the virtual world to all participants. VWRAP messages that
communicate request / response style messages flow between clients
and servers, using HTTP(S) as a message transport. Application
objects representing the application state expose a RESTful interface
and are addressed unambiguously using URIs. The VWRAP message
formats are described using LLIDL, the interface description language
defined as part of the LLSD abstract type system. LLIDL defines
RESTful resource accesses in terms of the LLSD abstract type system,
which may be serialized using one of three well defined serialization
mechanisms: XML, JSON and Binary. Protocol participants decide
before interacting which serialization mechanism is most appropriate
or use the content negotiation mechanisms defined in HTTP.
Hamrick Expires August 16, 2010 [Page 16]
Internet-Draft VWRAP: Introduction and Goals February 2010
2.3.2. Bi-Directional Messaging with the VWRAP Event Queue
Not all protocol interactions are easily represented by HTTP's
request / response semantics. When the server has a message for the
client, there is no widely deployed technique for the server to
initiate a HTTP request to the client. It is interesting to note
that this is the same problem developers of "rich web applications"
see when deploying their applications. Though VWRAP is not targeted
for implementation exclusively in web browsers, we can utilize some
of the techniques common in COMET applications.
Work is ongoing to define a general solution for "reverse HTTP," but
many of these solutions require the definition of new protocol and
deploying new code to web servers. The current best practice for
COMET-style interaction is the use of the "long poll."
To avoid "technology lock in," VWRAP defines an Event Queue
abstraction that represents the flow of messages from the server to
the client. The Event Queue is expected to be implemented using the
long poll technique. When additional options such as Reverse HTTP or
web sockets are specified and in general deployment, the Event Queue
may be re-implemented using these techniques. However, the interface
defined by the Event Queue in the VWRAP Foundation document
[I-D.lentczner-vwrap-foundation] should not change.
2.3.3. Using Capabilities to Simplify Inter-Domain Access Control
Simulated objects and services delivered by VWRAP compliant systems
will require some level of access control. Unfortunately,
distributed access control is a notoriously difficult problem. VWRAP
seeks to minimize the drawbacks of distributed access control by use
of capabilities. In this context, a capability is an opaque URL,
some portion of which contains a securely generated,
cryptographically unguessable sequence of digits. Capabilities are
used to define service endpoints and are intended to only be in the
possession of trusted parties.
For example, a system may export the capability:
http://www.example.org/s/B2A2A445-D234-463A-BE6D-6C54E5854FE4/
This URL defines the protocol endpoint used to communicate
application state changes (or query application state) for a specific
application object by a specific user (or delegate.)
Capabilities are required to be effectively unguessable as they
represent the right to perform a set of operations on a particular
resource. Additionally, they must be kept "secret." While the task
Hamrick Expires August 16, 2010 [Page 17]
Internet-Draft VWRAP: Introduction and Goals February 2010
of maintaining the confidentiality of a number of web resource
addresses may be a burden, it does have the advantage of simplifying
access delegation. If a subject wishes to delegate access to a third
party, they simply communicate the capability.
To reduce the likelihood of successful guessing attacks, inadvertent
disclosure of a capability and "time of check, time of use" attacks,
capabilities in VWRAP have a fixed lifetime, after which they expire.
Systems SHOULD pick capability lifetimes commensurate with their
security requirements and MUST NOT respond to protocol requests
directed at a capability's URL after it has expired. Additionally,
VWRAP capabilities may be "single use" or "one shot," meaning that
they may only be used once before expiring.
Because capabilities are randomly generated with a short lifetime,
VWRAP defines a mechanism for securely communicating capabilities and
re-requesting expired capabilities.
It is important to note that capabilities do not completely replace
traditional access control models. Systems may still use traditional
Subject-Permission-Object schemes to represent access control for
objects under their control. Capabilities provide a mechanism for
communicating access control decisions among loosely coupled trusted
systems.
2.3.4. Using LLSD to Avoid Version Skew
It is a common practice in large, complicated software systems to
divide the system into smaller, more manageable pieces. The precise
nature of this partitioning is beyond the scope of this protocol.
However, practical experience has demonstrated that services
distributed across multiple co-operating hosts MUST contend with the
issue of version skew. Simply stated, version skew is the condition
where multiple versions of a service are interoperating
simultaneously.
There are many reasons why version skew may be introduced. In VWRAP,
agent domain hosts and region domain hosts may be operated by
different organizations with different deployment schedules. Or
perhaps a domain operator is required to support an obsolete version
of a particular service endpoint for a small number of customers.
Whatever the cause of version skew, it has, in the past introduced
difficulties in deploying distributed services.
VWRAP does not seek to eliminate version skew, but it does attempt to
reduce it's impact. VWRAP services are defined in using the LLIDL
interface description language. LLIDL defines the type semantics of
fields inside a protocol message using the LLSD abstract type system.
Hamrick Expires August 16, 2010 [Page 18]
Internet-Draft VWRAP: Introduction and Goals February 2010
Each of the abstract types defined in LLSD has a default value, and
common conversions between conformable types are defined. LLSD
specifies three standard techniques for serializing a protocol
message prior to transmission across the network. Each of the three
serialization techniques renders protocol messages into a collection
of variable length fields. Protocol content is identified by JSON
syntax, binary tags or XML element semantics, not by it's position in
the message. LLIDL does not support the concept of a "required
field." If a field defined in a protocol interaction is not present
in the serialized message, it is semantically equivalent to the field
being present and containing the default value for the field's type.
Careful construction of service endpoints allows them to consume
messages described using LLIDL without fear that version skew induced
format differences may cause the semantics of the message to be
unclear. If a message arrives at a service endpoint with extra
fields (fields defined in a later revision of the protocol exchange),
the consumer can still extract those fields it understands. If a
message arrives lacking a field described in the protocol exchange,
the service endpoint SHOULD interpret it as if the field was present
and contained the default value for it's type. This implies the
message consumer cannot depend on the format of the message to
determine validity, but must examine the contents of the message,
converting missing fields to present fields with default values, and
then determine if sufficient information is present to imply
semantics about the protocol exchange.
This technique will not eliminate all ramifications of version skew,
but carefully constructed service descriptions should be able to
avoid the most common problems found when services interoperate with
minor revision differences. While the Virtual World Region Agent
Protocol itself does not mandate this style of message
interpretation, it does require that messages be constructed so that
service endpoints may do so.
3. Services Defined by the Virtual World Region Agent Protocol
3.1. User Authentication
User Authentication in the Virtual World Region Agent Protocol is
intended to verify the user's authorization to control their avatar
in the virtual world and associated services. VWRAP currently
defines three methods for authenticating a user, as well as
recommendations for integrating some third party authentication
schemes. The inputs to authentication are an avatar or account
identifier and a related authentication token. Assuming the token is
successfully authenticated, the output of authentication is a seed
Hamrick Expires August 16, 2010 [Page 19]
Internet-Draft VWRAP: Introduction and Goals February 2010
capability or "seed cap."
Like most VWRAP protocol exchanges, authentication protocol data is
represented as LLSD serialized data carried over a secure HTTPS
transport. The use of TLS with VWRAP authentication is recommended
for all deployers who do not employ some other network security
scheme (IPSec, link encryption, etc.) Implementers are advised that
in addition to user's password (or other credential,) the seed
capability returned after successful authentication is also
considered "sensitive" and should be protected with appropriate
network security measures.
The three authentication schemes defined in the VWRAP Trust Model and
User Authentication [I-D.hamrick-vwrap-authentication] specification
use a cryptographic hashes to demonstrate the user is in possession
of the shared secret associated with their account. Recommendations
also exist for using transport authentication mechanisms (such as TLS
client certificates) in place of shared secrets. Also, work is
currently underway to define protocol messages for use with Secure
Remote Password (SRP).
The authentication mechanisms described above are believed to be
sufficient at the time of this writing. It is an unfortunate truth,
however, that cryptographic primitives are occasionally shown to be
less secure than originally believed. For this reason, VWRAP
Authentication was designed to be extensible; allowing future users
to define new authentication schemes without invalidating other
authentication components. A further benefit of flexibility is the
ability to integrate other authentication schemes into an VWRAP
context. OpenID and SAML, for instance, are popular identity and
user authentication technologies that are defined outside the IETF.
VWRAP's flexible authentication system allows organizations
responsible for these standards to define their use with VWRAP
without having to change the text of the VWRAP Authentication
standard.
A typical flow of events for user authentication follows. This is a
simplified version; readers with an interest in authentication are
referred to the VWRAP Trust Model and User Authentication
[I-D.hamrick-vwrap-authentication] specification.
1. The end user presents their account identifier (either avatar
name or account name) and an authenticator to the authentication
services of the agent domain. Endpoints for user authentication
protocol messages are typically well defined, public URLs.
2. The authentication service authenticates the authenticator. If
the credentials cannot be authenticated, an error condition is
Hamrick Expires August 16, 2010 [Page 20]
Internet-Draft VWRAP: Introduction and Goals February 2010
returned.
3. The authentication service generates a seed capability and
returns it to the user.
4. The user queries the "seed cap," requesting capabilities for
other services the user is authorized to use.
It is important to note that in the last step listed above, the
client is free to request a subset of services offered by the agent
domain. This allows the same authentication service to be used by
restricted clients (for instance, a group-chat only client) as well
as traditional 3d viewers.
3.2. Presence in the Virtual World
"Presence" in VWRAP refers to at least two related concepts: account
presence and avatar presence. "Account Presence" describes the
readiness for interaction between a user and an agent domain. A
client applications signals the user's readiness for interaction with
an agent domain's services by initiating (and completing) user
authentication. Once authenticated, the user is "present." But an
agent domain may export more services than interacting with the
virtual world. It is conceivable a user may simply wish to
manipulate their profile data, reorganize their digital assets, or
make use of messaging services exported by the agent domain.
Interacting with these services requires only "account presence."
This type of presence implies only a client application presented
legitimate credentials to the agent domain's authentication service.
When a user wishes to interact with the virtual world, their avatar
must be placed or "rezzed" there. Placing an avatar requires the
cooperation between the agent domain and the region domain
controlling the system with authority for the target virtual
location. The quality of the system describing this interaction is
"avatar presence."
3.2.1. Establishing Presence with the Region Domain
Once authenticated with the agent domain, the client application has
established "account presence." Once in possession of a valid seed
capability, the client application may request a set of capabilities
representing services offered by the agent domain: digital asset
management, instant message and voice chat support as well as placing
the user's avatar into the virtual world.
Placing an avatar in the virtual world begins with the client
exercising the "place my avatar in a region" capability. As part of
Hamrick Expires August 16, 2010 [Page 21]
Internet-Draft VWRAP: Introduction and Goals February 2010
this transaction, the client provides the URI representing a region.
Upon receipt of this request, the agent domain determines the
validity of the URL provided, and if the URL resolves to a trusted
region domain begins the protocol between the agent domain and the
region domain to place the user's avatar in the region.
The precise exchange of messages between each party is beyond the
scope of this document, but is described in the VWRAP Teleport
specification But a few important points should be noted:
o The protocol endpoint at the agent domain the client application
uses to place the user's avatar in a region is provided to the
client as a capability following successful authentication. It is
not a publicly defined, fixed URL.
o The region the client wishes the agent domain to place their
avatar in is represented as a URI. This URI may be a URN, in
which case the agent domain SHOULD have the ability to convert the
URN into a URL. If the target region is identified by a URL, it
MUST use the HTTP [RFC2616] or HTTPS [RFC2817] URI schemes.
o The agent domain MAY apply a local policy to the URI and reject
the request before attempting to connect with the region domain.
(a "behind the firewall" agent domain may limit clients connecting
to it to systems known to be inside the local intranet, for
instance.)
o The agent domain MAY apply a local policy and reject the request
after it makes an initial communication request with the remote
region. (for example, if the region domain is operating servers
with expired TLS certificates, or if those certificates are issued
by a certifying authority the agent domain does not trust, it may
reject the request.)
o The process of placing the avatar in the region results in
capabilities from the region being communicated back to the agent
domain for controlling the avatar. The agent domain SHOULD
forward these capabilities to the client application.
o The process also results in the agent domain issuing capabilities
to the region domain, allowing it limited access to information
about the avatar such as the avatar's shape and appearance.
After an avatar is "placed" in a region, the agent domain is
responsible for maintaining it's presence. That is to say, after the
avatar has been successfully been placed in the region, the agent
domain MUST refuse to allow a second region to "take" the avatar's
presence without removing the avatar from its current region.
Hamrick Expires August 16, 2010 [Page 22]
Internet-Draft VWRAP: Introduction and Goals February 2010
3.2.2. Moving Presence
When an avatar moves between regions, special care must be taken that
the agent domain and both the source and destination regions end the
process with the same understanding as to the avatar's location.
Moving between regions is typically initiated by the client. The
process is largely the same as the initial avatar placement, but with
the important added step of removing the avatar from it's source
location before rezzing it in it's destination. (In fact, the
initial placement of an avatar can be thought of as a transfer from
"nowhere.")
The process of moving between regions is described in the VWRAP
Teleport specification, thought implementers should keep the
following important considerations in mind:
o The client signals to the agent domain it's desire to move from
one region to another by accessing the same capability as is used
for initial placement of the avatar.
o The agent domain must again check that local policy allows
movement to the new destination, and MUST receive a capability for
placing the client into the new region before it removes the
avatar from it's current location.
o The agent domain MUST also remove the avatar from it's current
location before placing the avatar in the destination location.
Capabilities granted to the current region MUST be revoked as part
of this process.
o The location of the avatar MUST be unambiguous and the agent
domain MUST NOT represent the avatars location as being in two
places at once. If required, for the short period between
removing the avatar from one region and placing it in another, the
avatar's location may be "in transit."
3.3. User and Group Messaging
3.3.1. Spatial Messaging
Besides the presence of a fully articulated 3-dimensional
representation of the user, the most important feature of the virtual
world is interaction. The virtual world is a social space;
communication with other users is important. Because the virtual
world simulates features of consensus reality, "proximity chat" or
"spatial messaging" is an important function. This mode of
interaction allows users to "hear" text messages that are spatially
Hamrick Expires August 16, 2010 [Page 23]
Internet-Draft VWRAP: Introduction and Goals February 2010
proximal to the user's avatar, while ignoring other messages. The
assumption being that avatar's whose users share a common interest
will congregate in specific locations in the virtual world. Or they
may find their avatars in the company of other users' avatars who are
engaging in interesting conversation. Either use case is possible;
emulating the consensus reality feature that people can hear
conversations close to them, but not hear more distant conversations
is an important feature of the virtual world.
Spatial messaging is managed by the region domain, and may be
initiated by users' client applications or by the region itself. It
is associated with an object in the virtual world (either an avatar
or a "plain" object) and occurs at a particular location. The host
in the region domain responsible for managing spatial chat applies a
proximity algorithm to the chat to determine which avatars or objects
are close enough to hear it. Those objects are all sent messages
with the contents of the message.
Client initiated chat begins when the client application posts a
message to the capability created by the region for an avatar's
outgoing chat messages. This capability is given to the client after
successfully establishing presence in the region. Incoming spatial
chat messages are posted to the event queue established between the
client and the region.
Complicating matters somewhat, spatial chat may occur near region
boundaries. When this occurs, the host managing a region's messaging
must have a mechanism to communicate chat messages to it's peers.
Hosts responsible for spatial chat in a region must establish event
queues with their peers in order to receive chat messages that
originated near the region's borders.
3.3.2. User to User and User to Group Messaging
Instead of speaking on the "public" spatial chat channel (remember,
each avatar within a defined range will be able to hear these chat
messages,) users may send private user to user messages. These
messages are managed by the user's agent domain. After
authentication, a client may request a capability for establishing a
instant messaging sessions. The client then accesses this
capability, providing a unique identifier for the target user. If
the agent domain is able to successfully establish a session with the
target user, the message originator is provided a capability to which
outgoing messages are posted.
User to Group messaging is similar, but groups are used as the target
for a message.
Hamrick Expires August 16, 2010 [Page 24]
Internet-Draft VWRAP: Introduction and Goals February 2010
Incoming user to user or user to group messages will arrive in the
event queue shared by the client application and the agent domain.
3.4. Digital Asset Access and Manipulation
The virtual world contains multiple digital objects; they have a
position and an orientation as well as a shape and potentially a
texture and other features applied to them. VWRAP defines formats
for describing objects and avatar shapes, but more importantly it
describes the mechanism by which those digital asset descriptions are
transferred between client applications, agent domains and region
domains. VWRAP also defines a trust model and a basic permissions
system, describing which users or groups have the ability to make
changes to any given object.
Digital assets may be "at rest" or "in world." Objects "at rest"
exist only as a description of the object, maintained by a network
addressable server and accessible via a unique URL. When an object
is "rezzed in world," its representation is transferred to a
simulation host in a region domain and it becomes viewable by avatars
and other objects in that region.
Several classes of digital assets are defined: primitive shapes,
textures, sound and animations for example. In addition to the data
describing the asset, metadata my be applied to objects. Unique
identifiers for creators, owners and affiliated groups may be
maintained by an object. Permission metadata may be added to an
object to limit it's distribution to remote systems or to define the
allowable operations by given users or classes of users. Object
name, description and tag values may be applied and should help with
indexing and searching for objects. Creation and modification dates
may be applied to assist systems that cache assets. Recent
discussions regarding open content licenses implies an interest in
license metadata. Such metadata could be of use to consumers of
digital assets; allowing them to more clearly interpret the creators
intent with respect to sharing.
3.4.1. Manipulating Digital Assets
A number of useful manipulations of digital assets "at rest" are
defined by VWRAP. Where appropriate, asset metadata may be altered
by directly communicating with the network host with authority for
that asset. This host may be part of the user's agent domain, or in
the case of region-specific assets, it could be associated with a
region domain. It is important to note, however, that not all
metadata is modifiable by all users, even the asset's owner.
Specifically, the semantics of the creator metadata do not allow the
owner to change the creator's identity. Group membership may carry
Hamrick Expires August 16, 2010 [Page 25]
Internet-Draft VWRAP: Introduction and Goals February 2010
some rights like the ability to manipulate the size, shape and
texture of an asset, but not an asset's owner.
The ability to access or manipulate digital assets is based on the
accessor's identity. Accessing and manipulating digital assets is
performed via capabilities which expose the state of the asset to an
authorized client. This requires positive identification of the
accessor prior to access. In the case where an asset server is owned
by the same authority as the agent domain, this access may be as
simple as providing the proper capability after user authentication.
In cases where the asset server is owned by a different authority,
systems for deferred authentication may be necessary. Work is
currently underway to integrate OAuth and SAML into VWRAP for this
purpose.
At a gross level, the types of resources exposed by a digital asset
server would include:
o a resource for searching an agent's inventory
o a resource for iterating across an agent's inventory
o a resource for accessing or manipulating a digital asset's
metadata
o a resource for uploading new digital assets, or changes to an
existing asset.
o a resource for removing a digital asset from the authority of the
asset server's domain
o a resource for transferring the asset or a copy of the asset to a
remote asset server
o a resource for instantiating an object "in world"
3.4.2. Establishing Presence for Digital Assets
Digital assets are intended to be used "in world," meaning there must
be a way for a user to direct a simulation host to take an asset from
an asset store and imbue it with presence in the virtual world. The
separation between agent based services and region based services is
fundamental to VWRAP and implies the authority for the system
maintaining the asset "at rest" may be distinct from that which
simulates the asset "in world." In practical terms, a region
simulator may need to communicate with an asset server owned by a
different person or company. In situations like this, trust is
paramount. Because an asset's metadata may limit the owner's right
Hamrick Expires August 16, 2010 [Page 26]
Internet-Draft VWRAP: Introduction and Goals February 2010
to make copies of an asset, the agent domain MUST be able to trust
the region domain will honor that metadata.
There are two levels of trust defined when working with digital
assets: host-based trust and user-based trust. The former represents
one system's expectation that the other will honor the metadata
regarding ownership, creatorship and rights and restrictions implied
by these concepts. Host based trust is carried by X.509 / PKIX
certificates and implies a managed PKI. User-based trust represents
the expectation the asset server will expose sensitive resources only
to users with the right to access such resources.
Provided trust is established between the asset server and a
simulation host, and the simulation host can demonstrate it is acting
on behalf of a user with rights to access a particular resource,
VWRAP defines a protocol for transferring a representation of the
digital asset for simulation. As part of this protocol, access to a
digital asset may be restricted while the object exists "in world."
This is the case for objects whose creators or owners specify that
only one copy of the asset may exist at a time.
4. IANA Considerations
This memo includes no request to IANA.
5. Security Considerations
As mentioned previously, the concept of a persistent, ubiquitous
identity in the virtual world is core to the user experience.
Keeping agent based services distinct from region or object based
services has advantages for scalability and flexibility. However, it
does have ramifications for the security of the virtual world as a
whole.
Most notably, this structure puts the agent domain in the role of a
trust broker. That is, the agent domain is trusted both by the set
of users who operate client applications and by the set of users who
administer peer domains. A transitive trust relationship exists
between the peer domains and end users by way of the agent domain.
The administrators of the peer domain trusts the agent domain to
properly identify end users, and potentially to ensure they are
members of a particular class. The end users trust the agent domain
to properly identify peer domains and to potentially limit the
transfer of digital assets to only those domains that have explicitly
agreed to honor asset permissions meta-data.
Hamrick Expires August 16, 2010 [Page 27]
Internet-Draft VWRAP: Introduction and Goals February 2010
VWRAP does not REQUIRE domains to adhere to any preset policy,
however. It instead provides a mechanism for communicating identity
information so that such a policy MAY be enforced.
5.1. Capabilities
VWRAP makes extensive use of RESTful resources accessed via HTTP.
Application state is communicated and changed by accessing web based
resources. One characteristic of such resources is they have a well
defined URL, many of which are formatted as URL-based capabilities.
[I-D.lentczner-vwrap-foundation] Capabilities have the characteristic
that possession of the URL implies the right to access the resource
it identifies. It is important that capability URLs are shared only
with trusted participants. The VWRAP Base document defines the
characteristics of URL-based capabilities, including the requirement
that they include an unpredictable random component in the URL.
Implementers need also ensure that these URLs are protected using
suitable mechanisms (such as TLS, IPSec or link encryption.)
5.2. User Authentication
Prior to granting an end user access to any agent domain managed
sensitive resource, the agent domain MUST authenticate the end user.
The VWRAP Authentication specification defines three techniques for
using shared secrets to authenticate end users. The agent_login
resource used for end user authentication provides an extensible
mechanism, allowing the development and use of additional
authentication techniques (SRP, TLS Client Certificates, SASL, etc.)
Again, it should be noted that VWRAP as currently defined does not
REQUIRE an agent domain to support a particular authentication scheme
(shared secret, public key, secure remote password, etc.) But it
does define the mechanism for three shared secret options.
Once a user is successfully authenticated, their client application
is passed a seed capability (as described in the VWRAP Base
specification.) This seed capability is used by the client
application to request access to resources and services managed by
the agent domain (including services like "place my avatar in the
virtual world.")
5.3. Agent Domain to Region Domain Authentication
Agent Domain authentication, or the process of authenticating an
agent host to a region host uses a X.509 PKI. Prior to
communicating, the agent domain generates a key pair for a particular
agent host under their control and requests a certificate from each
the region domain with which they wish to interact. The region
Hamrick Expires August 16, 2010 [Page 28]
Internet-Draft VWRAP: Introduction and Goals February 2010
domain returns a signed certificate to the agent domain which the
agent domain uses in subsequent communication with the region.
5.4. Access Control for Digital Assets
In addition to security characteristics addressing traditional
network and user security issues, the raison d'etre of VWRAP is to
communicate state concerning items inhabiting a virtual world. Some
of these items may have access control restrictions within the scope
of the applications used to simulate and render the virtual world.
VWRAP defines an extensible permissions model which allows
permissions meta-data to be associated with virtual items.
6. References
6.1. Normative References
[I-D.hamrick-vwrap-authentication]
Chu, T., Hamrick, M., and M. Lentczner, "VWRAP Trust Model
and User Authentication",
draft-hamrick-vwrap-authentication-00 (work in progress),
February 2010.
[I-D.hamrick-vwrap-type-system]
Brashears, A., Hamrick, M., and M. Lentczner, "VWRAP :
Abstract Type System for the Transmission of Dynamic
Structured Data", draft-hamrick-vwrap-type-system-00 (work
in progress), February 2010.
[I-D.lentczner-vwrap-foundation]
Lentczner, M., "Virtual World Region Agent Protocol:
Foundation", draft-lentczner-vwrap-foundation-00 (work in
progress), February 2010.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
6.2. Informative References
[RFC1822] Lowe, J., "A Grant of Rights to Use a Specific IBM patent
with Photuris", RFC 1822, August 1995.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within
Hamrick Expires August 16, 2010 [Page 29]
Internet-Draft VWRAP: Introduction and Goals February 2010
HTTP/1.1", RFC 2817, May 2000.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.
Appendix A. Definitions of Important Terms
agent domain
The agent domain is the administrative authority responsible for
managing services related to avatars and users. Identity
management, group membership, avatar appearance, profile
information, user authentication and group messaging are examples
of services and information maintained by the agent domain.
agent host
A network host maintained by the agent domain is called an "agent
host."
avatar
The avatar is the representation of a user in the virtual world.
The avatar's shape and appearance are used by other users to
render a graphical representation of the inhabited virtual world.
The user's view of the virtual world is rendered from the
perspective of their avatar.
client application
A client application is any application that is operated for the
benefit of the user. Common client applications might include a
"viewer" that renders the virtual world on the user's workstation
or a web application used to manipulate the user's digital
assets. VWRAP does not provide a canonical list of client
application categories, but if an application is not a part of an
agent domain or a region domain and it is manipulating user data
or an avatar on behalf of a user, with the user's permission, it
is a client application.
region domain
The region domain is the administrative authority responsible for
managing services related to presence in the virtual world and
it's simulation. Typical services exposed by a region domain
would include physics simulation, avatar presence and virtual
Hamrick Expires August 16, 2010 [Page 30]
Internet-Draft VWRAP: Introduction and Goals February 2010
object presence lifecycle management (i.e. - the creation,
manipulation and destruction of objects in the virtual world.)
region host
A network host maintained by the region domain is called a
"region host", though the historical term "simulator" is still
very common.
user
The entity controlling an avatar in world is the "user".
Appendix B. Acknowledgements
The author gratefully acknowledges the contributions of: Mark
Lentczner, David Levine, David Crocker, Larry Mastiner, Joshua Bell,
Barry Leiba, Joe Hildebrand, Chris Newman, Katherine Mancuso and Jon
Peterson.
Author's Address
Meadhbh Siobhan Hamrick
Linden Research, Inc.
945 Battery St.
San Francisco, CA 94111
US
Phone: +1 650 283 0344
Email: infinity@lindenlab.com
Hamrick Expires August 16, 2010 [Page 31]