Virtual World Region Agent                                    M. Hamrick
Internet-Draft                                                 D. Levine
Intended status: Informational             IBM Thomas J. Watson Research
Expires: January 6, 2011                                          Center
                                                            July 5, 2010

                     VWRAP: Introduction and Goals


   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, the
   objectives and requirements it imposes on hosts implementing the
   protocol.  To the extent it affects protocol interactions, this
   document describes the model assumed by the protocol.  A document
   roadmap is included that briefly describes the contents of other
   documents produced by the VWRAP Working Group.

Status of this Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at

   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."

   This Internet-Draft will expire on January 6, 2011.

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
   ( in effect on the date of
   publication of this document.  Please review these documents

Hamrick & Levine         Expires January 6, 2011                [Page 1]

Internet-Draft        VWRAP: Introduction and Goals            July 2010

   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 Simplified BSD License.

Table of Contents

   1.  Introduction and Motivation  . . . . . . . . . . . . . . . . .  4
     1.1.  Requirements Language  . . . . . . . . . . . . . . . . . .  4
   2.  Introducing the Virtual World Region Agent Protocol  . . . . .  4
     2.1.  A Brief Introduction to Virtual Worlds . . . . . . . . . .  4
     2.2.  Architectural Objectives and Requirements  . . . . . . . .  6
   3.  Virtual World Region Agent Protocol Architecture . . . . . . .  8
     3.1.  Protocol Objectives  . . . . . . . . . . . . . . . . . . .  8
     3.2.  Structural Architecture and Services . . . . . . . . . . . 11
       3.2.1.  The Client Application . . . . . . . . . . . . . . . . 12
       3.2.2.  Services . . . . . . . . . . . . . . . . . . . . . . . 12
       3.2.3.  Deployment Patterns  . . . . . . . . . . . . . . . . . 13
     3.3.  Architectural Elements . . . . . . . . . . . . . . . . . . 14
       3.3.1.  Communicating Application State Using REST-Like
               Resource Accesses  . . . . . . . . . . . . . . . . . . 15
       3.3.2.  Bi-Directional Messaging with the VWRAP Event Queue  . 15
       3.3.3.  Using Capabilities to Simplify Access Control
               Between Trust Domains  . . . . . . . . . . . . . . . . 16
       3.3.4.  Using Flexible Format Descriptions to Avoid
               Version Skew . . . . . . . . . . . . . . . . . . . . . 17
   4.  Services Defined by the Virtual World Region Agent Protocol  . 18
     4.1.  User Authentication  . . . . . . . . . . . . . . . . . . . 18
     4.2.  Presence in the Virtual World  . . . . . . . . . . . . . . 20
       4.2.1.  Establishing Presence with the Region Domain . . . . . 20
       4.2.2.  Moving Presence  . . . . . . . . . . . . . . . . . . . 21
     4.3.  User and Group Messaging . . . . . . . . . . . . . . . . . 22
       4.3.1.  Spatial Messaging  . . . . . . . . . . . . . . . . . . 22
       4.3.2.  User to User and User to Group Messaging . . . . . . . 23
     4.4.  Digital Asset Access and Manipulation  . . . . . . . . . . 23
       4.4.1.  Manipulating Digital Assets  . . . . . . . . . . . . . 24
       4.4.2.  Establishing Presence for Digital Assets . . . . . . . 25
   5.  Document Roadmap . . . . . . . . . . . . . . . . . . . . . . . 26
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 29
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 29
     7.1.  Capabilities . . . . . . . . . . . . . . . . . . . . . . . 29
     7.2.  User Authentication  . . . . . . . . . . . . . . . . . . . 30
     7.3.  Agent Domain to Region Domain Authentication . . . . . . . 30
     7.4.  Access Control for Digital Assets  . . . . . . . . . . . . 30
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 31

Hamrick & Levine         Expires January 6, 2011                [Page 2]

Internet-Draft        VWRAP: Introduction and Goals            July 2010

     8.2.  Informative References . . . . . . . . . . . . . . . . . . 31
   Appendix A.  Definitions of Important Terms  . . . . . . . . . . . 32
   Appendix B.  Acknowledgments . . . . . . . . . . . . . . . . . . . 33
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33

Hamrick & Levine         Expires January 6, 2011                [Page 3]

Internet-Draft        VWRAP: Introduction and Goals            July 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 protocol
   suite is intended to carry information about a 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.

   Virtual worlds differ in their capabilities and architectural
   features.  The VWRAP protocol is not appropriate for all massively
   multi-participant experiences.  This document provides an
   introduction to virtual worlds and defines characteristics of virtual
   worlds VWRAP explicitly supports.  It also describes the specific
   objectives of the protocol suite.  An overview of the protocol is
   included, including an architectural description and list of services
   defined in a typical virtual world deployment.  A guide to the
   documents proposed by the VWRAP working group is provided in an
   effort to describe which protocol features are defined in which
   working group deliverable.

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119 [RFC2119].

2.  Introducing the Virtual World Region Agent Protocol

2.1.  A Brief Introduction to Virtual Worlds

   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 external forces.
   The social construction of the virtual world is also similar to the
   reified world.  People meet and interact with others 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.

Hamrick & Levine         Expires January 6, 2011                [Page 4]

Internet-Draft        VWRAP: Introduction and Goals            July 2010

   To be relevant to the participant's experience, virtual worlds must
   retain characteristics of the "real world."  Objects in the virtual
   world are models of familiar shapes and textures, represented using a
   common data format so they may be easily processed by the human
   visual cortex.  At the same time they must carry sufficient
   information to be consumed by participants with visual impairments or
   to be processed by automated systems.  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 completely faithful mirrors of the world
   our physical bodies inhabit.  Virtual worlds are not limited by
   distance.  With appropriate network connectivity, users may 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 with friends, examine DNA codon by codon with coworkers, or
   experience with a works of interactive art.

   Virtual worlds inherit the intellectual property characteristics of
   other digital media.  Implementers wishing to replicate the economy
   of scarcity present in the reified world must take special measures
   to avoid or limit the ramifications of unauthorized content

   The VWRAP suite assumes network hosts, likely operated by distinct
   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; interoperability standards are essential for
   delivering a robust services and compelling user experiences.  VWRAP
   provides these interoperability standards.  It may be used with large
   arrays of hosts simulating a vast virtual world, or small worlds
   operated for the benefit a few persons.  It defines a trust model so
   hosts from different organizations may limit access to sensitive

   VWRAP presupposes a virtual world with the following characteristics:

   1. The virtual world exists independent of the participating

       This is in contrast to systems that dynamically create virtual
       environments for specific social or task-oriented simulation.
       VWRAP assumes the state virtual world is "always on" and does not

Hamrick & Levine         Expires January 6, 2011                [Page 5]

Internet-Draft        VWRAP: Introduction and Goals            July 2010

       require a specific protocol to establish new virtual worlds.

   2. Avatars have a single, unique presence in the virtual world.

       Users are represented in the virtual world by a digital
       representation called an avatar.  A user's avatar has an
       existence that mirrors the common physical world.  Like people,
       avatars exist in only one place at one time.  Avatars have a
       single identity that persists between user sessions.  This
       identity may be used to render user-specific avatar shape or as
       the basis for access control.

   3. 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.

2.2.  Architectural Objectives and Requirements

   The overall objective of the VWRAP suite is to enable a stable,
   extensible and secure virtual world.  The protocols defined by this
   working group do not mandate a specific system or network
   architecture.  However, previous implementations of large distributed
   systems can yield clues as to how VWRAP compliant systems will be
   deployed.  Documents produced by this working group reflect the
   consensus view of best common practice for producing large-scale,
   loosely-coupled distributed systems.  VWRAP does not require a
   specific architecture, but its protocols are defined with a specific
   series of architectural patterns in mind.

   These architectural patterns have the following objectives in mind:

   1. Systems implementing virtual world services must be distributed.

       Virtual worlds are inherently distributed systems.  They are
       collaborative tools intended to reduce the effect of distance on
       meaningful social, educational and commercial interaction.
       Typical virtual worlds are envisioned as drawing services from
       network hosts operated by a wide array of organizational
       entities.  Virtual worlds may also be large enough that a single
       system or cluster of systems is not capable of providing all
       services to each client.

       Experience with previous virtual world technologies suggests
       systems implementing the virtual world assume services they
       depend on are provided by distinct hosts in different
       administrative domains.  The virtual world, its user base and the
       constellation of virtual objects they use are simply too vast and

Hamrick & Levine         Expires January 6, 2011                [Page 6]

Internet-Draft        VWRAP: Introduction and Goals            July 2010

       varied to assume a single system or a single provider.

       This does not mean, however, that virtual worlds simulated by the
       VWRAP suite must exist on more than one system.  Quite the
       contrary, all VWRAP components (including the user agent) could
       operate on a single system.  But there is little reason to
       believe the protocol used to exchange information between virtual
       world services must differ between small and large systems.

       Large virtual worlds with many users are certain to implement
       virtual world services differently than small ones.  But the
       protocol used to to communicate between systems implementing the
       virtual world can be the same.  To be sure, optimizations may be
       possible for smaller deployments.  Implementers of these "small"
       systems may find it useful to utilize standard, unoptimised
       protocols to allow for the possibility of growth.

       But however large (or small) a virtual world deployment is, or
       how many distinct organizations contribute to its operation,
       software implementing virtual world services MUST assume
       resources required to perform its function are distributed
       amongst multiple hosts.

   2. Services supporting collaboration are hosted on 'central'

       The "authoritative state" of the virtual world is stored on
       'central' servers.  Clients use protocols described in the VWRAP
       suite to access this state information (or to notified of state
       changes.)  This is in contrast to some virtual world and
       Massively Multi-Participant systems in which state may be
       distributed.  This is in contrast to 'client authoritative' or
       'co-simulation' architectures in which each client is required to
       perform physics simulation for objects within view of the user's

   3. Virtual world services default to being 'open'.

       The VWRAP suite does not describe protocols for exclusive use
       within a "walled garden."  Implementers and deployers are given
       the freedom to identify information sources and to determine
       which entities on the network they will trust.  Service deployers
       may limit which users may access their services to a small set of
       individuals, employees of a particular company, residents of a
       particular country, users of a particular website.  Or they may
       impose no restrictions whatsoever.  It is entirely up to the
       service operator.

Hamrick & Levine         Expires January 6, 2011                [Page 7]

Internet-Draft        VWRAP: Introduction and Goals            July 2010

       These same operators may require virtual assets to be hosted on
       their own servers, or they may identify a list of trusted asset
       servers operated by other organizations.  Or they may impose no
       restrictions whatsoever.  The decision is entirely up to the
       service operator.

       The VWRAP suite describes protocols that are by default, "open."
       There is no requirement in these specifications that arbitrary
       bindings between services be enforced.  In other words, requiring
       two services (e.g. - physics simulation and asset storage) be
       managed by the same organization's servers is an issue of local
       policy, not of protocol.

3.  Virtual World Region Agent Protocol Architecture

3.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:

   1. Identity is universal.

       Many network services are provided anonymously; the nature of the
       service does not require identity authentication prior to its
       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 v 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

Hamrick & Levine         Expires January 6, 2011                [Page 8]

Internet-Draft        VWRAP: Introduction and Goals            July 2010

       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
       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.

   2. Presentation of protocol data is in a flexible fashion.

       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 [XML2008] and JSON
       [ECMA262] 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 resources are intended to be accessed via HTTP [RFC2616] or
       HTTPS [RFC2818].  In some circumstances, however, there may be
       advantages to accessing resources using other transports.
       HTTP(S) is well suited when request-response plus meta-data
       semantics are desired.  For instance, event streams may be better
       suited by using XMPP [RFC3920] while time sensitive messages may
       be better carried over RTP [RFC3550].  Except where noted,
       implementers should assume that resources are accessed using HTTP
       or HTTPS.

       VWRAP protocol exchanges are described in terms of an abstract
       type system [I-D.ietf-vwrap-type-system] describing the content
       of virtual world resources in a language and transport neutral
       fashion.  An interface description notation allows implementers
       and service designers to describe the flow of abstract data
       between protocol participants.  Abstract structured data types
       and information flows are reified using serialization rules most
       appropriate for the application.  Web-based applications may
       choose to use JSON or XML.  Server-to-server interactions may use
       the VWRAP specific binary serialization scheme if implementers

Hamrick & Levine         Expires January 6, 2011                [Page 9]

Internet-Draft        VWRAP: Introduction and Goals            July 2010

       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.

   3. Separation of concerns and easy extension is the norm.

       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

       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.

   4. The system exhibits 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 a flexible abstract type system and interface
       description notation to describe the structure and type semantics
       of elements in messages sent between systems.  Because this type
       system makes extensive use of variable width, clearly delineated
       data fields, services which consume protocol messages may

Hamrick & Levine         Expires January 6, 2011               [Page 10]

Internet-Draft        VWRAP: Introduction and Goals            July 2010

       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.

3.2.  Structural Architecture and Services

   The Virtual World Region Agent Protocol assumes services on many
   different network hosts will collaborate to simulate the virtual
   world.  Each service is responsible for a particular task:
   maintaining agent presence information, physics simulation, relaying
   text and voice chat information, etc.  Services themselves are
   comprised of resources whose attributes are accessed by way of
   RESTful patterns at unique addresses.  Because individual resources
   are accessed using their address, they are often referred to as
   "protocol endpoints."

   Figure 1 below is intended to communicate the following concepts
   regarding the structural architecture of VWRAP:

   o  VWRAP uses a client-server architecture.

   o  There are likely to be a multitude of user agents.

   o  There are likely to be several instances of each defined service
      (i.e. - there is no single, "blessed" authentication or asset

   o  Services may be clients of other services (i.e. - it's not only
      user agents that are clients.)

   o  There is no obligation that each client establish a relationship
      with each type of service. (e.g. - it's okay to authenticate, then
      communicate exclusively with a chat server or an asset server.)

Hamrick & Levine         Expires January 6, 2011               [Page 11]

Internet-Draft        VWRAP: Introduction and Goals            July 2010

         +-------------+      +-------------+      +-------------+
         | User Agent  |----->|    Auth     |----->|    Asset    |
         |             |  +-->| Service 'A' |   +->|  Server 'A' |
         +-------------+  |   +-------------+   |  +-------------+
                          |                     |
         +-------------+  |                     |  +-------------+
         | User Agent  |--+                     |  |   Region    |
         |             |------------------------+->|  Simulator  |
         +-------------+                        |  +-------------+
                          +-------------------+ |
         +-------------+  |   +-------------+ | |  +-------------+
         |   Client    |--+   |    Auth     | | |->|  Text Chat  |
         | Application |----->| Service 'B' | +--->|   Service   |
         +-------------+      +-------------+      +-------------+

   Figure 1: Example Protocol Flows in VWRAP

3.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 organizations offering
   virtual worlds services.  VWRAP makes no assumptions about client
   software save it adheres to the described protocol.

   It is important to remember that there are likely to be more types of
   client applications than just 3d virtual world renderers.  Some
   client applications, termed "user agents," will be intended to be
   operated directly by human beings for their benefit.  Other client
   applications may be automated services: search and indexing, backup
   and restore, etc.

3.2.2.  Services

   "Services" are loosely-coupled collections of RESTful protocol
   endpoints, each providing access to the internal state of
   applications simulating the virtual world.  Services are operated by
   an "End Entity," who is responsible for it's proper operation.  End
   entities will become more important when discussing the VWRAP trust
   model.  There is no requirement that the protocol endpoints that
   comprise a service be meaningfully related, but it does tend to make
   the system more understandable.  This is to say, the VWRAP suite
   makes no attempt to enforce a policy that services be comprised of
   related protocol endpoints.

   Implementers and deployers should also note that there is no

Hamrick & Levine         Expires January 6, 2011               [Page 12]

Internet-Draft        VWRAP: Introduction and Goals            July 2010

   requirement that all endpoints in a service be operated on network
   hosts administered by the same end entity.  In other words, it is
   perfectly acceptable for a "service" to be comprised of resources
   whose access addresses map to hosts from multiple organizations.
   Implementers should never assume that one trusted endpoint in a
   service implies that all endpoints in that service are trusted.

3.2.3.  Deployment Patterns

   The VWRAP suite assumes that the services that simulate the virtual
   world will be hosted on multiple network hosts.  Client applications
   that render the virtual world for end users are assumed to be on
   distinct hosts as well.

                             | organization 1      |
                             |                     |
                             | +----------------+  |     +-------------+
                       +------>| service host 1 |<------>]             |
                       |     | +----------------+  |     |   client    |
                       |     |                     | +-->| application |
   +-------------+     |     |                     | |   |             |
   |             |<----+     | +----------------+  | |   +-------------+
   |   client    |<----------->| service host 2 |<---+     ^
   | application |           | +----------------+  |       |
   |             |<----+     +---------------------+       |
   +-------------+     |                                   |
                       |     +---------------------+       |
                       |     | organization 2      |       |
                       |     |                     |       |
                       |     | +----------------+  |       |
                       +------>| service host 3 |<---------+
                             | +----------------+  |

   Figure 2: Protocol Flows Between Organizations

   Figure 2 above demonstrates a typical virtual world deployment.  In
   it we see multiple client applications connecting to several servers
   operated by multiple organizations.  Each "service host" in this
   diagram exposes an interface to a collection of resources
   representing the state of objects in the virtual world.  It is
   traditional to discuss related resources as exposing "an interface"
   while related interfaces comprise "a service."  Typical services are
   listed in a different section.

   There is no restriction on how services map to hosts.  Deployments
   where all resource interfaces are hosted on a single host is just as

Hamrick & Levine         Expires January 6, 2011               [Page 13]

Internet-Draft        VWRAP: Introduction and Goals            July 2010

   valid as one where resources are spread between a wide array of
   systems.  Client applications should support both.  Resource
   interfaces are addressed using URLs.  Clients should treat the URLs
   for resources as opaque resource locations.

   The VWRAP suite makes extensive use of capabilities.  Provisioning of
   the initial "seed capability" is described in the document describing
   the VWRAP trust model and user authentication techniques
   [I-D.ietf-vwrap-authentication].  The standard technique for "logging
   in" involves querying the authentication service for the location of
   other services.  Implementers should note there are no restrictions
   on the location of these subordinate services.  They may be
   implemented on the same host as the authentication service, or in the
   same domain, or they may be hosted by a completely different

   Operators of authentication services SHOULD configure their systems
   to only provide clients with service locations operated by trusted

   Implementers should note that client applications may be configured
   to allow end users to ignore the authentication service and directly
   provision their client applications to use explicit service
   locations.  Client application developers may wish to consider
   offering such an option.  Developers and operators of virtual world
   services MUST assume the client may provide them with data from
   untrusted services.

3.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 [RFC3986] to represent the address of application

   o  using HTTP(S) to transport message oriented protocol data

   o  using XMPP to transport data appropriately modeled as event

   o  using (S)RTP to transport time-sensitive messages

   o  defining application resources using reified formats for abstract
      type and interface description notations

Hamrick & Levine         Expires January 6, 2011               [Page 14]

Internet-Draft        VWRAP: Introduction and Goals            July 2010

   o  using an abstract type system to define access semantics of fields
      in protocol messages

   o  using multiple reification schemes to "serialize" abstract
      structured data (defined serializations include XML, JSON and

3.3.1.  Communicating Application State Using REST-Like Resource

   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 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.

   VWRAP messages that communicate request / response style messages
   flow between clients and servers, use HTTP(S) as a message transport.
   Message flows that are better modeled using an event stream MAY use
   XMPP as a transport.  Time sensitive messages MAY use RTP as a
   transport.  In each case, application objects representing the
   application state expose a RESTful interface and are addressed
   unambiguously using URIs.

3.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

Hamrick & Levine         Expires January 6, 2011               [Page 15]

Internet-Draft        VWRAP: Introduction and Goals            July 2010

   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.

3.3.3.  Using Capabilities to Simplify Access Control Between Trust

   Simulated objects and services delivered by VWRAP compliant systems
   will require some level of access control.  Distributed access
   control is a notoriously difficult problem, however.  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:

   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
   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

Hamrick & Levine         Expires January 6, 2011               [Page 16]

Internet-Draft        VWRAP: Introduction and Goals            July 2010

   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

3.3.4.  Using Flexible Format Descriptions 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.
   Practical experience has demonstrated that services distributed
   across multiple cooperating 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,
   services may be operated by different organizations with different
   deployment schedules.  Or perhaps one particular service 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 attempts to reduce
   its impact.  VWRAP services are defined in using an abstract
   interface description notation.  It defines the type semantics of
   fields inside a protocol message using an abstract type system.  Each
   of the types defined in its abstract type system has a default value
   and common conversions between conformable types are defined.  The
   protocol also defines systems for serializing protocol messages prior
   to transmission across the network.  Each of serialization scheme
   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 its position in the message.  The
   abstract type system and interface notation 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

Hamrick & Levine         Expires January 6, 2011               [Page 17]

Internet-Draft        VWRAP: Introduction and Goals            July 2010

   semantically equivalent to the field being present and containing the
   default value for the field's type.

   Careful construction of application resources allows them to operate
   without fear 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 its 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

   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.

4.  Services Defined by the Virtual World Region Agent Protocol

4.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
   capability or "seed cap."

   Like many VWRAP protocol exchanges, authentication protocol data is
   represented as 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 passwords and other credentials, the seed capability
   returned after successful authentication is also considered

Hamrick & Levine         Expires January 6, 2011               [Page 18]

Internet-Draft        VWRAP: Introduction and Goals            July 2010

   "sensitive" and should be protected with appropriate network security

   Authentication schemes defined in the VWRAP Trust Model and User
   Authentication [I-D.ietf-vwrap-authentication] specification use a
   cryptographic hash 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.

   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

   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.ietf-vwrap-authentication] specification.

   1.  The end user presents their account identifier 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

   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

Hamrick & Levine         Expires January 6, 2011               [Page 19]

Internet-Draft        VWRAP: Introduction and Goals            July 2010

   restricted clients (for instance, a group-chat only client) as well
   as traditional 3d viewers.

4.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."

4.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
   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:

Hamrick & Levine         Expires January 6, 2011               [Page 20]

Internet-Draft        VWRAP: Introduction and Goals            July 2010

   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

   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 its 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.

4.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 its source

Hamrick & Levine         Expires January 6, 2011               [Page 21]

Internet-Draft        VWRAP: Introduction and Goals            July 2010

   location before rezzing it in its destination.  (In fact, the initial
   placement of an avatar can be thought of as a transfer from

   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 its 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 its current location.

   o  The agent domain MUST also remove the avatar from its 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."

4.3.  User and Group Messaging

4.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
   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.

Hamrick & Levine         Expires January 6, 2011               [Page 22]

Internet-Draft        VWRAP: Introduction and Goals            July 2010

   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 its 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.

4.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.

   Incoming user to user or user to group messages will arrive in the
   event queue shared by the client application and the agent domain.

4.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

Hamrick & Levine         Expires January 6, 2011               [Page 23]

Internet-Draft        VWRAP: Introduction and Goals            July 2010

   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 its 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.

4.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
   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

Hamrick & Levine         Expires January 6, 2011               [Page 24]

Internet-Draft        VWRAP: Introduction and Goals            July 2010

   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

   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

   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"

4.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
   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

Hamrick & Levine         Expires January 6, 2011               [Page 25]

Internet-Draft        VWRAP: Introduction and Goals            July 2010

   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.

5.  Document Roadmap

   This section provides a brief overview of the thirteen documents
   expected to be delivered by the VWRAP working group.  A brief
   description of each document's contents is provided.  The documents
   may be read in any order, but reading this document followed by
   abstract type system specification, foundation document and
   authentication document is recommended.  The diagram below provides
   recommended sequence.

                            | Intro and Goals |
                         | Abstract Type System |
                           |                  |
                           v                  v
                    +-------------+  +----------------+
                    | Foundations |  | Authentication |
                    +-------------+  +----------------+
                           |                  |
                           |                  v
                           |             +--------+
                           |             | Launch |
                           |             +--------+
                     * all other docs

   Figure 3: Document Roadmap

Hamrick & Levine         Expires January 6, 2011               [Page 26]

Internet-Draft        VWRAP: Introduction and Goals            July 2010

   1. VWRAP : Introduction and Goals (this document)

       This document provides a detailed introduction to the working
       group's efforts.  It describes the characteristics of VWRAP
       virtual worlds and sets objectives for the virtual world
       experience and requirements for the protocol.  Specific verbiage
       relating to the proposed architecture of VWRAP virtual worlds and
       deployment patterns are provided.

   2. VWRAP : Abstract Type System for the Transmission of Dynamic
   Structured Data

       The VWRAP protocols are intended to sit at the "application
       layer."  This means that VWRAP protocol messages may be carried
       over HTTP, XMPP, RTP or raw UDP.  Other specifications in the
       VWRAP series use an interface description language and an
       abstract type system to specify protocol messages in a language
       and operating system neutral manner.  The abstract type system
       and interface description language are defined in this document.
       Guidelines for carrying VWRAP over HTTP and mime types for three
       serialization formats are provided as well.

   3. VWRAP : Foundational Concepts and Transport Expectations

       The "foundations" document provides a brief introduction and
       definition of certain fundamental technical concepts referenced
       in VWRAP.  Important concepts described in this document include
       capabilities, a HTTP based event queue and important issues for
       implementers wishing to carry VWRAP messages over new transports.

   4. VWRAP : Client Application Launch Message

       This draft defines a MIME type and message format carrying
       virtual world session initiation information.  It is intended to
       be used by web browsers to launch virtual world user agents.
       Virtual worlds that use web authentication technologies such as
       OpenID, OAuth and HTTP authentication may use this message to
       signal the web browser to launch a client which initiates a
       virtual world session.

   5. VWRAP : Trust Model and User Authentication

       The VWRAP architecture assumes a distributed constellation of
       servers cooperating to simulate a virtual world.  This document
       describes a trust model hosts may use to determine whether the
       origin of a request is trustworthy.  The specification does not
       require a host to discard messages without origin integrity, but
       it does specify how messages carry attestations of inter-domain

Hamrick & Levine         Expires January 6, 2011               [Page 27]

Internet-Draft        VWRAP: Introduction and Goals            July 2010

       trust.  This draft also defines the agent_login and optional
       maintenance resources for VWRAP authentication.

   6. VWRAP : Voice and Text Communication Channel Establishment

       VWRAP is expected to rely on external text and voice
       communications standards.  XMPP is the presumed choice for text
       communication while RTP is the presumed choice for voice.
       Neither XMPP or RTP define virtual locations as addressable
       endpoints, so this document defines a technique for identifying
       them for spatial text and voice.

   7. VWRAP : Agent Presence Establishment

       Also known as "the teleport protocol," this specification defines
       how an authorized user's agent establishes its avatar's presence
       in the virtual world.

   8. VWRAP : Region Description Format

       This document defines the format of the virtual world's scene
       graph and the protocol interaction used by clients to retrieve

   9. VWRAP : Digital Asset Access

       This document defines the protocol used to request and receive
       information about digital assets.  It also defines asset types an
       implementer MUST support (primitive shapes, textures, etc.)

   10. VWRAP : Primitive Object Format

       This document defines MIME types and formats for objects in the
       virtual world: primitive shapes, NURBS and meshes.

   11. VWRAP : Avatar Format

       Avatars are expected to require more detailed information about
       shape and movement than primitive shapes.  This specification
       describes how primitive objects and (optionally) bio-mechanical
       skeletal models may be requested by client applications.

   12. VWRAP : Entity Identifiers

       This document describes how avatars, primitive objects, regions,
       assets and locations in the virtual world are represented as URIs
       or URLs.

Hamrick & Levine         Expires January 6, 2011               [Page 28]

Internet-Draft        VWRAP: Introduction and Goals            July 2010

   13. VWRAP : Time Sensitive Messages

       Some state updates in the VWRAP protocol are considered "time
       sensitive."  That is, they will be useless unless delivered
       within a proscribed period. object updates and avatar control
       messages may fall in this category.  This document describes the
       format and semantics of time sensitive messages within the VWRAP

6.  IANA Considerations

   This memo includes no request to IANA.

7.  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

   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.

   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.

7.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.
   Capabilities have the characteristic that possession of the URL
   implies the right to access the resource it identifies.  It is

Hamrick & Levine         Expires January 6, 2011               [Page 29]

Internet-Draft        VWRAP: Introduction and Goals            July 2010

   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.)

7.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.")

7.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
   domain returns a signed certificate to the agent domain which the
   agent domain uses in subsequent communication with the region.

7.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.

Hamrick & Levine         Expires January 6, 2011               [Page 30]

Internet-Draft        VWRAP: Introduction and Goals            July 2010

8.  References

8.1.  Normative References

   [ECMA262]  "ECMAScript Language Specification (5th Edition)",
              December 2009.

              Hamrick, M., "VWRAP : Trust Model and User
              Authentication", draft-ietf-vwrap-authentication-00 (work
              in progress), July 2010.

              Brashears, A., Hamrick, M., and M. Lentczner, "VWRAP :
              Abstract Type System for the Transmission of Dynamic
              Structured Data", draft-ietf-vwrap-type-system-00 (work in
              progress), July 2010.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [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
              HTTP/1.1", RFC 2817, May 2000.

   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
              Jacobson, "RTP: A Transport Protocol for Real-Time
              Applications", STD 64, RFC 3550, July 2003.

   [RFC3920]  Saint-Andre, P., Ed., "Extensible Messaging and Presence
              Protocol (XMPP): Core", RFC 3920, October 2004.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, January 2005.

   [XML2008]  Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and
              F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth
              Edition)", November 2008.

8.2.  Informative References

   [RFC2818]  Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.

Hamrick & Levine         Expires January 6, 2011               [Page 31]

Internet-Draft        VWRAP: Introduction and Goals            July 2010

Appendix A.  Definitions of Important Terms


       An "agent" is the abstract information-oriented representation of
       a user in the system.  An agent differs from an "avatar" in that
       it is not a visual representation and intended to be manipulated
       and observed by computing systems (not people.)

       Authentication ("Auth") Service

       A service responsible for accepting user credentials and
       providing service endpoints for other services.


       The "avatar" is the user's (mostly) visual representation in the
       virtual world.  It is the entity that end users (humans) are
       likely interested in interacting with.

       Client Application

       A "client application" is any application that mostly consumes
       virtual world services.  Client applications may or may not be
       "user agents."


       A "region" is the set of data maintained by a "simulator."


       A service whose primary responsibility is to simulate 3d spaces
       (including physics simulation and object presence maintenance) is
       termed a "Simulator."


       The entity controlling an avatar in world is the "user".

       User Agent

       A "user agent" is a client application operated predominantly by
       an end user.

Hamrick & Levine         Expires January 6, 2011               [Page 32]

Internet-Draft        VWRAP: Introduction and Goals            July 2010

Appendix B.  Acknowledgments

   The author gratefully acknowledges the contributions of: Mark
   Lentczner, David Crocker, Larry Mastiner, Joshua Bell, Barry Leiba,
   Joe Hildebrand, Chris Newman, Katherine Mancuso and Jon Peterson.

Authors' Addresses

   Meadhbh Siobhan Hamrick
   P.O. Box 783
   Boulder Creek, CA  95006

   Phone: +1 650 283 0344

   David W. Levine
   IBM Thomas J. Watson Research Center
   19 Skyline Drive
   Hawthorn, NY  10532

   Phone: +1 914 784 7427

Hamrick & Levine         Expires January 6, 2011               [Page 33]