idnits 2.17.1 draft-hamrick-vwrap-intro-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 12, 2010) is 5186 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC1822' is defined on line 1317, but no explicit reference was found in the text == Outdated reference: A later version (-01) exists of draft-hamrick-vwrap-authentication-00 -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Virtual World Region Agent M. Hamrick 3 Protocol Linden Research, Inc. 4 Internet-Draft February 12, 2010 5 Intended status: Informational 6 Expires: August 16, 2010 8 VWRAP: Introduction and Goals 9 draft-hamrick-vwrap-intro-00 11 Abstract 13 The Virtual World Region Agent Protocol (VWRAP) defines interactions 14 between hosts collaborating to create an shared, internet scale 15 virtual world experience. This document introduces the protocol, its 16 objectives and requirements it imposes on hosts and users utilizing 17 the protocol. This document also describes the model assumed by the 18 protocol (to the extent it affects protocol interactions.) 20 Status of this Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on August 16, 2010. 43 Copyright Notice 45 Copyright (c) 2010 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the BSD License. 58 Table of Contents 60 1. Introduction and Motivation . . . . . . . . . . . . . . . . . 4 61 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 7 62 2. Virtual World Region Agent Protocol Architecture . . . . . . . 7 63 2.1. Protocol Objectives . . . . . . . . . . . . . . . . . . . 7 64 2.2. Structural Architecture and the Role of Domains . . . . . 9 65 2.2.1. The Client Application . . . . . . . . . . . . . . . . 11 66 2.2.2. The Agent Domain . . . . . . . . . . . . . . . . . . . 11 67 2.2.3. The Region Domain . . . . . . . . . . . . . . . . . . 13 68 2.2.3.1. Protocol Flows . . . . . . . . . . . . . . . . . . 14 69 2.3. Architectural Elements . . . . . . . . . . . . . . . . . . 15 70 2.3.1. Communicating Application State Using REST-Like 71 Resource Accesses . . . . . . . . . . . . . . . . . . 15 72 2.3.2. Bi-Directional Messaging with the VWRAP Event Queue . 17 73 2.3.3. Using Capabilities to Simplify Inter-Domain Access 74 Control . . . . . . . . . . . . . . . . . . . . . . . 17 75 2.3.4. Using LLSD to Avoid Version Skew . . . . . . . . . . . 18 76 3. Services Defined by the Virtual World Region Agent Protocol . 19 77 3.1. User Authentication . . . . . . . . . . . . . . . . . . . 19 78 3.2. Presence in the Virtual World . . . . . . . . . . . . . . 21 79 3.2.1. Establishing Presence with the Region Domain . . . . . 21 80 3.2.2. Moving Presence . . . . . . . . . . . . . . . . . . . 23 81 3.3. User and Group Messaging . . . . . . . . . . . . . . . . . 23 82 3.3.1. Spatial Messaging . . . . . . . . . . . . . . . . . . 23 83 3.3.2. User to User and User to Group Messaging . . . . . . . 24 84 3.4. Digital Asset Access and Manipulation . . . . . . . . . . 25 85 3.4.1. Manipulating Digital Assets . . . . . . . . . . . . . 25 86 3.4.2. Establishing Presence for Digital Assets . . . . . . . 26 87 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 88 5. Security Considerations . . . . . . . . . . . . . . . . . . . 27 89 5.1. Capabilities . . . . . . . . . . . . . . . . . . . . . . . 28 90 5.2. User Authentication . . . . . . . . . . . . . . . . . . . 28 91 5.3. Agent Domain to Region Domain Authentication . . . . . . . 28 92 5.4. Access Control for Digital Assets . . . . . . . . . . . . 29 93 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 94 6.1. Normative References . . . . . . . . . . . . . . . . . . . 29 95 6.2. Informative References . . . . . . . . . . . . . . . . . . 29 97 Appendix A. Definitions of Important Terms . . . . . . . . . . . 30 98 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 31 99 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 31 101 1. Introduction and Motivation 103 Virtual Worlds are of increasing interest to the internet community. 104 Innumerable examples of virtual world implementations exist; most 105 using proprietary protocols. With roots in games and social 106 interaction, virtual worlds are now finding use in business, 107 education and information exchange. This document introduces the 108 Virtual World Region Agent Protocol (VWRAP) suite. This suite of 109 protocols is intended to carry information about the virtual world: 110 its shape, its residents and objects existing within it. VWRAP's 111 goal is to define an extensible set of messages for carrying state 112 and state change information between hosts participating in the 113 simulation of the virtual world. 115 At its most basic level, the virtual world mirrors the reified world. 116 It is inhabited by people and contains objects. Objects and people 117 have a distinct place in the world and respond to forces external to 118 them. The social construction of the virtual world is also similar 119 to the reified world. People may meet and interact with other 120 people, either to complete work tasks or for simple enjoyment. 121 People converse, share media, and even sing to each other. A virtual 122 world may allow commerce or enable building of virtual assets. 123 Nearly the complete range of human interaction can be replicated in 124 the virtual world. Properly rendered, an experience in a virtual 125 world can carry the same impact as one in consensus reality. 127 To be relevant to the participant's experience, virtual worlds must 128 retain some characteristics of the "real world." Objects represented 129 in the virtual world must be rendered so they are easily processed by 130 the human visual cortex. At the same time they must carry sufficient 131 information to be consumed by participants with visual impairments. 132 Though virtual, objects are familiar shapes and textures. Though the 133 virtual world's state is maintained by abstract collections of data, 134 it is rendered as recognizable (though occasionally fantastical) 135 physical objects. 137 But virtual worlds are not complete mirrors for the world our 138 physical bodies inhabit. Virtual worlds are not limited by distance. 139 Given appropriate network connectivity, two virtual world 140 participants can interact even if they are on opposite sides of the 141 earth. Virtual worlds also allow participants to "play" with 142 physical constraints. They provide the subjective experience of 143 things not possible in consensus reality: participants can fly, the 144 effects of "death" are temporary, users may call items into 145 existence, examine the International Space Station, examine DNA codon 146 by codon, or interact with a massive works of art. And they do these 147 things with co-workers and friends. 149 The VWRAP suite assumes hosts, potentially operated by many 150 organizations will collaborate to simulate the virtual world. It 151 also assumes that services originally defined for other environments 152 (like the world wide web) will enhance the experience of the virtual 153 world. The virtual world is expected to be simulated using software 154 from multiple sources; the definition of how these systems will 155 interoperate is essential for delivering a robust collection of co- 156 operating hosts and a compelling user experience. VWRAP describes 157 this definition. It may be used to describe the interactions between 158 large collections of systems simulating large virtual worlds, or 159 small worlds operated for the benefit of one or a few persons. It 160 defines a trust model to allow hosts from multiple organizations to 161 be used to simulate the same apparent virtual world. 163 VWRAP presupposes a virtual world with the following characteristics: 165 The Virtual World exists independent of the participating clients. 167 This is in contrast to some systems which "call virtual worlds 168 into being" as needed as a backdrop for social or task-oriented 169 simulation. VWRAP assumes the state virtual world is "always on" 170 and does not require a specific protocol to establish new virtual 171 worlds. 173 Avatars have a single, unique presence in the virtual world. 175 The avatar, or the digital representation of an end user in the 176 virtual world, has an existence that mirrors the common physical 177 world; avatars (like people) do not exist in two places at once. 178 Further, the avatar has a single, persistent identity that may be 179 used to render a user-specific avatar shape or as the basis for 180 access control. 182 The virtual world contains persistent objects. 184 Objects in the virtual world are governed by a "rational" life- 185 cycle. They are created, persist and are (optionally) destroyed. 187 The VWRAP suite assumes that multiple hosts will participate in 188 simulating the virtual world. Related to this assumption: 190 The virtual world may be partitioned. 192 The virtual world is envisioned as being large; so large that it 193 is impractical for a single system or cluster of systems to 194 manage avatar presence, object persistence and physics 195 simulation. The virtual world MAY therefore be partitioned to 196 move services offered by different administrative domains onto 197 distinct hosts. Virtual space may also be partitioned so that 198 different "regions" of the virtual world are simulated by 199 distinct hosts. 201 Presence, state and simulation happens on authoritative servers. 203 The presence, location and physical behavior of virtual objects 204 and avatars are maintained and simulated by a host authoritative 205 for a portion of the virtual world. This is in contrast to the 206 "co-simulation" technique where each client maintains this 207 information and communicates changes to each of its peers. 209 Version skew between simulation hosts MUST be tolerable. 211 The virtual world created by VWRAP is intended to be hosted on 212 systems from several different administrative domains. It is 213 unrealistic to assume that each administrative domain will run 214 precisely the same version of the protocol. To protect against 215 "brittleness" from version skew, the Virtual World Region Agent 216 Protocol uses a flexible object representation system known as 217 LLSD. Used correctly, semantics of remote resource access may be 218 maintained even when the participants in the protocol do not 219 adhere to exactly the same revision of the protocol. 221 VWRAP uses Representational State Transfer (REST) style interaction 222 over HTTP. 224 Much of the protocol interaction between systems participating in 225 the virtual world simulation uses a request / response 226 interaction style. Rather than creating a new messaging 227 framework, VWRAP layers much of it's protocol atop HTTP. 228 Further, VWRAP uses Representational State Transfer (REST) like 229 semantics when exposing a protocol interface. 231 A persistent, ubiquitous identity accompanies requests between hosts 232 involved in the virtual world simulation. 234 As in the consensus physical reality, each item is assumed to 235 have a (largely) non-mutable identity. Unless acted upon by an 236 external force, objects tend to retain their identifying 237 characteristics (bricks remain bricks unless pulverized, etc.) 238 Avatars too maintain an identity that allows the virtual world to 239 properly render them. 241 1.1. Requirements Language 243 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 244 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 245 document are to be interpreted as described in RFC 2119 [RFC2119]. 247 2. Virtual World Region Agent Protocol Architecture 249 2.1. Protocol Objectives 251 The primary objective of the Virtual World Region Agent Protocol is 252 to provide a stable, extensible, secure system for virtual world 253 information interchange with the following characteristics: 255 Identity is universal 257 Many network services are provided anonymously; the nature of the 258 service does not require identity authentication prior to it's 259 use. But with the increasing deployment of customizable services 260 delivered on the internet, identity is increasingly important. 261 Even services that contain information that might not be 262 considered "sensitive" require a representation of digital 263 identity if for no other reason than to match service requests 264 with user preferences. For example, a web page presenting 265 current weather information may be enhanced by remembering 266 locations of interest to each user. Recent work with "web mash 267 ups," where multiple personalized or sensitive resources are used 268 in concert with one another points to the utility of a 269 "universal" identity. The representation of this universal 270 identity enables independent services to cooperate to present the 271 facade of a unified application to the service consumer. This 272 allows service aggregators to more easily integrate "best of 273 breed" services into a consistent solution. 275 Universal identity is critical to the virtual world. To achieve 276 an internet scale virtual world, user services must be 277 distributed amongst multiple hosts. To achieve a compelling 278 experience, it must be easy for service providers to deliver 279 their services in the virtual world. To facilitate a compelling 280 social experience in the virtual world, all users must have the 281 ability evaluate identity information of other users. Domains 282 responsible for virtual world simulation MUST use a consistent 283 representation of identity across all their hosts; simulation 284 would otherwise be uncoordinated. Service providers who deliver 285 content into the virtual world MUST use a consistent 286 representation of identity to maintain the persistence of the 287 virtual manifestation of their service; virtual objects used in 288 conjunction with these services might otherwise appear to change 289 state without apparent cause. Users depend on the persistent, 290 universal identity of other users; if an avatar's identity 291 changed unexpectedly, the result would be a suboptimal virtual 292 world experience. 294 Flexible presentation of protocol data 296 While the primary purpose of the virtual world is to simulate a 297 physical or social space, the tools used to access objects in the 298 virtual world may be varied. Using a "3d viewer" is the primary 299 mode of interaction with the virtual world, but other tools may 300 be better suited for some tasks. For instance, it may be easier 301 for a user to use a web browser to review avatar profile 302 information, or to change details of virtual objects. Further, 303 virtual world "mash ups" may prove to be important to some 304 communities. To support the web (where XML and JSON are the 305 lingua franca of information exchange) while also supporting 306 tools where binary encodings are more appropriate, VWRAP was 307 designed to be "presentation neutral." 309 VWRAP protocol exchanges are described in terms of an abstract 310 type system using an interface description language. 311 Implementations may choose to instantiate actual protocol data 312 units using the most appropriate presentation format. Web-based 313 applications may choose to use JSON or XML. Server-to-server 314 interactions may use the VWRAP specific binary serialization 315 scheme if implementers and deployers view binary encoding to be 316 advantageous. The decision of which serialization scheme to use 317 is ultimately that of the system implementer. VWRAP has been 318 designed to provide this flexibility to system implementers and 319 those tasked with deploying VWRAP compatible systems. 321 Flexible decomposition of concerns and ease of extension 323 VWRAP has been designed to allow meaningful separation of 324 concerns. In other words, changes in one part of the protocol 325 should not appreciably affect other parts. 327 For example, the authentication portion of the protocol is 328 independent of the part of the protocol that deals with instant 329 messaging or instantiating objects in the virtual world. In 330 addition to defining messages for communicating application 331 state, the specification also defines pre- and post-conditions. 332 Should one particular authentication scheme be found to be 333 lacking, it can be modified or replaced without affecting other 334 systems. 336 This type of separation of concerns in the protocol specification 337 also makes it easy to deploy "related solutions." While VWRAP 338 was designed primarily to communicate the state of the virtual 339 world between servers and client applications, a number of 340 related applications also exist. E-Commerce web sites related to 341 the virtual world and mobile chat clients allowing instant 342 messaging between mobile networks and virtual world participants 343 are just two examples of such applications. Proper separation of 344 concerns allows new services to be specified and deployed without 345 the need to redefine existing protocol. 347 Resilience in the face of version skew 349 Core to the VWRAP protocol is the idea that different components 350 and services may be operated by different administrative 351 entities; identity management services might be operated one 352 business while simulation services are operated by another. In 353 environments where many different organizations participate, 354 version skew can be an important concern. VWRAP was designed to 355 "degrade gracefully" when two systems running different versions 356 of the protocol attempt to communicate. 358 VWRAP uses the LLSD abstract type system and the LLIDL interface 359 description language to describe the structure and type semantics 360 of elements in messages sent between systems. Because LLSD makes 361 extensive use of variable width, clearly delineated data fields, 362 services which consume protocol messages may identify and extract 363 only those message elements they know how to handle. While this 364 is not a guarantee that message semantics may be preserved in all 365 version skew situations, it does eliminate one important cause of 366 interoperability failures. 368 2.2. Structural Architecture and the Role of Domains 370 The Virtual World Region Agent Protocol assumes a division between 371 systems offering user / avatar oriented services and systems offering 372 virtual world simulation services. VWRAP is intended to be used in 373 an environment where services may be delivered by hosts in different 374 administrative domains. A VWRAP "domain" is a collection of network 375 hosts with the same administrative authority. "Services" are offered 376 by domains and are comprised of collections of related RESTful 377 resources. Two special classes of domains are defined. A domain 378 that exposes a user authentication service is an "agent domain" while 379 a domain exposing an object presence service is termed a "region 380 domain." The protocol allows, but does not require, the agent domain 381 and region domain to be distinct; in other words, a user's identity 382 may be managed by one organization while the virtual world they 383 inhabit may be simulated by hosts owned by a completely different 384 organization. 386 The motivation for this split is two-fold: First, it allows systems 387 to scale along the two most independent axes (agent count and virtual 388 world size.) Second, it moves identity management out of the domain 389 of virtual world simulation, allowing the same avatar to be easily 390 used in virtual world simulations managed by different administrative 391 domains. 393 Each domain offers services to authenticated peers: user 394 authentication, avatar and object presence, physics simulation, 395 digital asset hosting, group messaging, etc. User authentication and 396 avatar presence define the agent domain; they are it's raison d'etre. 397 Physics simulation and object presence define the region domain. 398 Other services are assigned to the agent or region domain according 399 to the expected scaling behavior, though their presence in a 400 particular domain does not imply a hard and fast rule they may only 401 exist in that domain. Digital assets, for instance, are expected to 402 generally be under the administrative control of an agent domain. 403 The digital asset service is thought to be an "agent domain service." 404 However, some deployers may find it convenient to define assets 405 belonging to a specific region as being a "region domain service." 407 It should also be noted that a client may consume services from 408 multiple agent and region domains. The agent domain responsible for 409 a user's profile and presence information may delegate responsibility 410 for digital asset services, group messaging or user to user voice 411 communication to a third party domain. It is expected that different 412 parts of the same virtual world may be simulated on hosts from 413 distinct region domains. 415 +--------------------------+ 416 | agent domain | 417 | | 418 | +----------------+ | 419 +------->| agent host |-+ | 420 | | +----------------+ |-+ | 421 | | +----------- ^ --+ | | 422 +-------------+ | | +--------- | ----+ | 423 | |<----+ +---------------- | -------+ 424 | client | | 425 | application | | 426 | |<----+ +---------------- | --------+ 427 +-------------+ | | region domain | | 428 | | v | 429 | | +-----------------+ | 430 +------->| region host |-+ | 431 | +-----------------+ |-+ | 432 | +-----------------+ | | 433 | +-----------------+ | 434 +---------------------------+ 436 Figure 1: Protocol Flows in VWRAP 438 2.2.1. The Client Application 440 VWRAP presumes the virtual world is simulated for the benefit of 441 human users. Whether that human is operating a "viewer" application 442 to render the virtual world, or using a web interface to perform 443 routine maintenance tasks, the user is expected to be operating 444 software outside the administrative control of either the agent or 445 region domain. VWRAP makes no assumptions about client software save 446 it adheres to the described protocol. 448 2.2.2. The Agent Domain 450 The Agent Domain is the administrative entity that operates systems 451 managing information about agents (i.e. - people) and related 452 concepts. The agent domain is responsible for the following data and 453 tasks: 455 o User and Avatar Profile and Identity Information 457 Virtual worlds are social spaces, used to interact with people. 458 Information like the avatar's name, online friends and co-workers, 459 group membership, personal and public notes and a user's list of 460 "interesting places" in the virtual world are examples of the 461 types of avatar profile information. 463 The agent domain may also wish to store information about the 464 user: account name, contact information, billing information, etc. 466 o User Authentication 468 The first step in interacting with the virtual world is to 469 authenticate the user's credentials (thus proving the user's right 470 to control the avatar.) 472 Some system developers are interested in supporting completely 473 anonymous avatars in the virtual world. Support for this feature 474 is an option left to individual agent domains, but it should be 475 mentioned that even if an agent domain wishes to support 476 anonymity, the "authentication" step is required. In addition to 477 demonstrating the user's right to control an avatar, the 478 authentication step reserves server resources for use by the 479 avatar. (see the discussion about seed capabilities later in this 480 document.) Even if an agent domain wishes to support anonymous 481 avatars, there is still a need to provide session specific shared 482 secrets to ensure that anonymous avatars may not be "hijacked" by 483 malicious virtual world participants. 485 o Avatar Appearance Information 487 Avatars in the virtual world are generally three dimensional 488 figures represented using constructive geometry or polygon meshes. 489 This information is of critical importance to client applications; 490 without it, it cannot render the avatar. 492 o User Groups 494 Because virtual worlds are (often) social spaces, many systems 495 support user groups to facilitate messaging and permissions 496 amongst avatars who share similar interests. 498 o Individual or Group Text and Voice Chat 500 In keeping with the theme of virtual worlds being social spaces, 501 agent domains may wish to support text, voice or even video chat 502 between two users or amongst a group of users. 504 o Digital Assets at Rest 506 The virtual world is filled with virtual objects: conference 507 tables, houses, airships, dragons, etc. These objects may or may 508 not be instantiated in the virtual world. When objects are "at 509 rest" or not being simulated in the virtual world, objects that 510 are owned by a particular user are stored in an asset server 511 associated with the agent domain. 513 o Avatar Presence 515 When a user authenticates themselves and wishes to interact with 516 the virtual world, the user's avatar presence must be established. 517 Simulating a user's avatar is a task shared by the agent domain, 518 the region domain and the client application. The agent domain is 519 responsible for establishing the user's presence in the virtual 520 world simulated by the region domain, and to provide information 521 about the avatar so it may be properly rendered. 523 2.2.3. The Region Domain 525 The Region Domain is the administrative entity that operates systems 526 managing information about virtual land and related concepts. The 527 region domain is responsible for the following data and tasks: 529 o Object Presence 531 The state of objects in the virtual world (landscapes, avatars, 532 virtual "things") must be communicated to all participants. It is 533 the responsibility of the region domain to keep track of each 534 object's state. The landscape can change; clouds in the virtual 535 sky may move and change shape; virtual people may move around and 536 virtual "things" can undergo any number of state changes. The 537 region domain is responsible for receiving input from virtual 538 world inhabitants, evaluating how that input changes the state of 539 objects in the virtual world, and then communicating those state 540 changes to other observers. 542 o Physics Simulation 544 Simulating the physical behavior of objects in the virtual world 545 is a core feature of any virtual world. Regions may choose "earth 546 like" conditions, or may modify gravity and atmospheric settings 547 to create the experience of being on a different planet. Still 548 other options include simulating quantum effects seen at very 549 small scales or the large scale relativistic effects seen on 550 galactic scales. Whatever the "physics" involved, it is the 551 individual hosts in the region domain tasked with the simulation. 553 o Effects of Programmatic Changes 555 (aka "scripting.") Some virtual worlds allow users to modify the 556 state of objects using simple programming languages. The region 557 domain is generally responsible for managing and executing scripts 558 that modify the state of objects. 560 o Region Specific Asset Storage 562 Though most "assets at rest" are associated with an avatar, it is 563 conceptually appropriate for some items to be associated with a 564 region; textures associated with landscapes, for instance. Or in 565 some situations, the operator of a region may wish to bind 566 "sensitive" resources to the location to ensure they do not follow 567 region visitors to regions outside the originating region's 568 administrative authority. 570 2.2.3.1. Protocol Flows 572 VWRAP defines protocol between the three architectural components 573 above: the client application, the agent domain and the region 574 domain. 576 User authentication 578 Before the agent or region domain expose service endpoints 579 providing access to sensitive resources, the user operating the 580 client application must be authenticated. The VWRAP Trust Model 581 and User Authentication [I-D.hamrick-vwrap-authentication] 582 specification describes the process of authentication between the 583 client application and the agent domain. 585 Digital Asset Access 587 Responsibility for digital assets is shared between the agent and 588 region domains. Digital assets "at rest" may be stored in an 589 asset server associated with an agent domain. The agent domain 590 exposes an interface allowing an asset's owner to manipulate some 591 of that asset's metadata. The region host (or simulator) uses 592 the same interface to retrieve the digital representation of the 593 asset so it may be scheduled for simulation. Though the 594 interface is the same, the asset server may trust the region host 595 with sensitive data that may not be exposed to the client 596 interface. After the asset is "rezzed" in world, the region host 597 exposes an interface client applications use to receive a 598 description of the asset and updates to its state. 600 Avatar Placement and Movement 602 After a user is authenticated, their avatar may be placed into 603 the virtual world (a process described as "rezzing".) After the 604 avatar is "rezzed in-world", responsibility for its simulation 605 may move from one region host to another. Initial placement and 606 movement in the virtual world is an intricate interaction between 607 hosts in the agent domain (which maintain information about the 608 avatar's presence) and hosts in the region domain (which simulate 609 the avatar and communicate its actions to client applications.) 610 Initial placement is initiated by the client application, 611 communicated to the agent domain which then communicates the 612 request to the region domain on the client's behalf. Movement is 613 usually initiated by the client and communicated to the region 614 domain. If an avatar moves out of the virtual world region 615 managed by a particular simulator and into a new simulator, the 616 client must initiate the transit to the new simulator. The agent 617 domain then contacts the new region, moves the avatar's presence 618 there and removes it from the initial simulator. 620 Object Update 622 When an avatar initially enters a region, the agent domain 623 provides it with an interface it may query on the region host to 624 begin to construct the scene graph maintained by that simulator. 625 Object state changes (movement, rotation, texture change, etc.) 626 are communicated to the client application from the region host 627 using a related interface. 629 2.3. Architectural Elements 631 VWRAP utilizes a number of "architectural motifs" or recurring design 632 patterns. Most notably they include: 634 o exposing application state via RESTful resources 636 o using URIs to represent the address of application resources 638 o using HTTP to "carry" message oriented protocol data 640 o defining application state transitions and accesses with an 641 interface description language (called LLIDL) 643 o using an abstract type system (called LLSD) to define access 644 semantics of fields in protocol messages 646 o using multiple "serializations" of the abstract type system to 647 support different categories of consumers; defined serializations 648 include XML, JSON and Binary. 650 2.3.1. Communicating Application State Using REST-Like Resource 651 Accesses 653 Contrary to popular opinion, not ALL virtual world interactions must 654 be real-time exchanges. Many common activities like user 655 authentication and texture and object transfer do not require "real 656 time" semantics in the same way that applications like video- 657 conferencing and Voice Over IP (VOIP) do. While it is generally a 658 better experience if textures download quickly, if they are delayed, 659 it does not have the same ramifications as if a voice packet in a 660 VOIP system were delayed. Additionally, some interactions with the 661 virtual world are strongly reminiscent of the request / response 662 semantics used by popular protocols (like HTTP, POP3, etc.) 664 Because many protocol exchanges in the virtual world may be 665 represented as non-real-time request / response interactions, VWRAP 666 "reuses" the messaging semantics of HTTP. The justification for this 667 is simple. Were VWRAP to not use HTTP, many of the features of HTTP 668 would need to be re-invented or at least re-specified. Features like 669 the use of mime types to identify payload structure; the use of 670 message headers to modify the request or response and the use of URIs 671 to address and identify resources. HTTP also has the benefit of 672 being well supported by tools vendors and well understood by 673 manufacturers of networking equipment. 675 Protocol exchanges in VWRAP that utilize request / response semantics 676 are described using the LLSD / LLIDL abstract type system 677 [I-D.hamrick-vwrap-type-system]. LLSD defines type semantics for 678 elements in a protocol data unit as well as rules for converting the 679 data into a serialized form suitable for transmission across the 680 network. VWRAP defines HTTP (and HTTPS) as the transports for 681 serialized messages. 683 Addressable protocol endpoints in VWRAP are represented as URIs 684 [RFC3986]. Protocol endpoints generally address RESTful resources. 685 The VWRAP protocol uses HTTP verbs to provide read and write access 686 to resources which represent the application state of the remote 687 peer. 689 To recap, the objective of VWRAP is to communicate application state 690 about the virtual world to all participants. VWRAP messages that 691 communicate request / response style messages flow between clients 692 and servers, using HTTP(S) as a message transport. Application 693 objects representing the application state expose a RESTful interface 694 and are addressed unambiguously using URIs. The VWRAP message 695 formats are described using LLIDL, the interface description language 696 defined as part of the LLSD abstract type system. LLIDL defines 697 RESTful resource accesses in terms of the LLSD abstract type system, 698 which may be serialized using one of three well defined serialization 699 mechanisms: XML, JSON and Binary. Protocol participants decide 700 before interacting which serialization mechanism is most appropriate 701 or use the content negotiation mechanisms defined in HTTP. 703 2.3.2. Bi-Directional Messaging with the VWRAP Event Queue 705 Not all protocol interactions are easily represented by HTTP's 706 request / response semantics. When the server has a message for the 707 client, there is no widely deployed technique for the server to 708 initiate a HTTP request to the client. It is interesting to note 709 that this is the same problem developers of "rich web applications" 710 see when deploying their applications. Though VWRAP is not targeted 711 for implementation exclusively in web browsers, we can utilize some 712 of the techniques common in COMET applications. 714 Work is ongoing to define a general solution for "reverse HTTP," but 715 many of these solutions require the definition of new protocol and 716 deploying new code to web servers. The current best practice for 717 COMET-style interaction is the use of the "long poll." 719 To avoid "technology lock in," VWRAP defines an Event Queue 720 abstraction that represents the flow of messages from the server to 721 the client. The Event Queue is expected to be implemented using the 722 long poll technique. When additional options such as Reverse HTTP or 723 web sockets are specified and in general deployment, the Event Queue 724 may be re-implemented using these techniques. However, the interface 725 defined by the Event Queue in the VWRAP Foundation document 726 [I-D.lentczner-vwrap-foundation] should not change. 728 2.3.3. Using Capabilities to Simplify Inter-Domain Access Control 730 Simulated objects and services delivered by VWRAP compliant systems 731 will require some level of access control. Unfortunately, 732 distributed access control is a notoriously difficult problem. VWRAP 733 seeks to minimize the drawbacks of distributed access control by use 734 of capabilities. In this context, a capability is an opaque URL, 735 some portion of which contains a securely generated, 736 cryptographically unguessable sequence of digits. Capabilities are 737 used to define service endpoints and are intended to only be in the 738 possession of trusted parties. 740 For example, a system may export the capability: 742 http://www.example.org/s/B2A2A445-D234-463A-BE6D-6C54E5854FE4/ 744 This URL defines the protocol endpoint used to communicate 745 application state changes (or query application state) for a specific 746 application object by a specific user (or delegate.) 748 Capabilities are required to be effectively unguessable as they 749 represent the right to perform a set of operations on a particular 750 resource. Additionally, they must be kept "secret." While the task 751 of maintaining the confidentiality of a number of web resource 752 addresses may be a burden, it does have the advantage of simplifying 753 access delegation. If a subject wishes to delegate access to a third 754 party, they simply communicate the capability. 756 To reduce the likelihood of successful guessing attacks, inadvertent 757 disclosure of a capability and "time of check, time of use" attacks, 758 capabilities in VWRAP have a fixed lifetime, after which they expire. 759 Systems SHOULD pick capability lifetimes commensurate with their 760 security requirements and MUST NOT respond to protocol requests 761 directed at a capability's URL after it has expired. Additionally, 762 VWRAP capabilities may be "single use" or "one shot," meaning that 763 they may only be used once before expiring. 765 Because capabilities are randomly generated with a short lifetime, 766 VWRAP defines a mechanism for securely communicating capabilities and 767 re-requesting expired capabilities. 769 It is important to note that capabilities do not completely replace 770 traditional access control models. Systems may still use traditional 771 Subject-Permission-Object schemes to represent access control for 772 objects under their control. Capabilities provide a mechanism for 773 communicating access control decisions among loosely coupled trusted 774 systems. 776 2.3.4. Using LLSD to Avoid Version Skew 778 It is a common practice in large, complicated software systems to 779 divide the system into smaller, more manageable pieces. The precise 780 nature of this partitioning is beyond the scope of this protocol. 781 However, practical experience has demonstrated that services 782 distributed across multiple co-operating hosts MUST contend with the 783 issue of version skew. Simply stated, version skew is the condition 784 where multiple versions of a service are interoperating 785 simultaneously. 787 There are many reasons why version skew may be introduced. In VWRAP, 788 agent domain hosts and region domain hosts may be operated by 789 different organizations with different deployment schedules. Or 790 perhaps a domain operator is required to support an obsolete version 791 of a particular service endpoint for a small number of customers. 792 Whatever the cause of version skew, it has, in the past introduced 793 difficulties in deploying distributed services. 795 VWRAP does not seek to eliminate version skew, but it does attempt to 796 reduce it's impact. VWRAP services are defined in using the LLIDL 797 interface description language. LLIDL defines the type semantics of 798 fields inside a protocol message using the LLSD abstract type system. 800 Each of the abstract types defined in LLSD has a default value, and 801 common conversions between conformable types are defined. LLSD 802 specifies three standard techniques for serializing a protocol 803 message prior to transmission across the network. Each of the three 804 serialization techniques renders protocol messages into a collection 805 of variable length fields. Protocol content is identified by JSON 806 syntax, binary tags or XML element semantics, not by it's position in 807 the message. LLIDL does not support the concept of a "required 808 field." If a field defined in a protocol interaction is not present 809 in the serialized message, it is semantically equivalent to the field 810 being present and containing the default value for the field's type. 812 Careful construction of service endpoints allows them to consume 813 messages described using LLIDL without fear that version skew induced 814 format differences may cause the semantics of the message to be 815 unclear. If a message arrives at a service endpoint with extra 816 fields (fields defined in a later revision of the protocol exchange), 817 the consumer can still extract those fields it understands. If a 818 message arrives lacking a field described in the protocol exchange, 819 the service endpoint SHOULD interpret it as if the field was present 820 and contained the default value for it's type. This implies the 821 message consumer cannot depend on the format of the message to 822 determine validity, but must examine the contents of the message, 823 converting missing fields to present fields with default values, and 824 then determine if sufficient information is present to imply 825 semantics about the protocol exchange. 827 This technique will not eliminate all ramifications of version skew, 828 but carefully constructed service descriptions should be able to 829 avoid the most common problems found when services interoperate with 830 minor revision differences. While the Virtual World Region Agent 831 Protocol itself does not mandate this style of message 832 interpretation, it does require that messages be constructed so that 833 service endpoints may do so. 835 3. Services Defined by the Virtual World Region Agent Protocol 837 3.1. User Authentication 839 User Authentication in the Virtual World Region Agent Protocol is 840 intended to verify the user's authorization to control their avatar 841 in the virtual world and associated services. VWRAP currently 842 defines three methods for authenticating a user, as well as 843 recommendations for integrating some third party authentication 844 schemes. The inputs to authentication are an avatar or account 845 identifier and a related authentication token. Assuming the token is 846 successfully authenticated, the output of authentication is a seed 847 capability or "seed cap." 849 Like most VWRAP protocol exchanges, authentication protocol data is 850 represented as LLSD serialized data carried over a secure HTTPS 851 transport. The use of TLS with VWRAP authentication is recommended 852 for all deployers who do not employ some other network security 853 scheme (IPSec, link encryption, etc.) Implementers are advised that 854 in addition to user's password (or other credential,) the seed 855 capability returned after successful authentication is also 856 considered "sensitive" and should be protected with appropriate 857 network security measures. 859 The three authentication schemes defined in the VWRAP Trust Model and 860 User Authentication [I-D.hamrick-vwrap-authentication] specification 861 use a cryptographic hashes to demonstrate the user is in possession 862 of the shared secret associated with their account. Recommendations 863 also exist for using transport authentication mechanisms (such as TLS 864 client certificates) in place of shared secrets. Also, work is 865 currently underway to define protocol messages for use with Secure 866 Remote Password (SRP). 868 The authentication mechanisms described above are believed to be 869 sufficient at the time of this writing. It is an unfortunate truth, 870 however, that cryptographic primitives are occasionally shown to be 871 less secure than originally believed. For this reason, VWRAP 872 Authentication was designed to be extensible; allowing future users 873 to define new authentication schemes without invalidating other 874 authentication components. A further benefit of flexibility is the 875 ability to integrate other authentication schemes into an VWRAP 876 context. OpenID and SAML, for instance, are popular identity and 877 user authentication technologies that are defined outside the IETF. 878 VWRAP's flexible authentication system allows organizations 879 responsible for these standards to define their use with VWRAP 880 without having to change the text of the VWRAP Authentication 881 standard. 883 A typical flow of events for user authentication follows. This is a 884 simplified version; readers with an interest in authentication are 885 referred to the VWRAP Trust Model and User Authentication 886 [I-D.hamrick-vwrap-authentication] specification. 888 1. The end user presents their account identifier (either avatar 889 name or account name) and an authenticator to the authentication 890 services of the agent domain. Endpoints for user authentication 891 protocol messages are typically well defined, public URLs. 893 2. The authentication service authenticates the authenticator. If 894 the credentials cannot be authenticated, an error condition is 895 returned. 897 3. The authentication service generates a seed capability and 898 returns it to the user. 900 4. The user queries the "seed cap," requesting capabilities for 901 other services the user is authorized to use. 903 It is important to note that in the last step listed above, the 904 client is free to request a subset of services offered by the agent 905 domain. This allows the same authentication service to be used by 906 restricted clients (for instance, a group-chat only client) as well 907 as traditional 3d viewers. 909 3.2. Presence in the Virtual World 911 "Presence" in VWRAP refers to at least two related concepts: account 912 presence and avatar presence. "Account Presence" describes the 913 readiness for interaction between a user and an agent domain. A 914 client applications signals the user's readiness for interaction with 915 an agent domain's services by initiating (and completing) user 916 authentication. Once authenticated, the user is "present." But an 917 agent domain may export more services than interacting with the 918 virtual world. It is conceivable a user may simply wish to 919 manipulate their profile data, reorganize their digital assets, or 920 make use of messaging services exported by the agent domain. 921 Interacting with these services requires only "account presence." 922 This type of presence implies only a client application presented 923 legitimate credentials to the agent domain's authentication service. 925 When a user wishes to interact with the virtual world, their avatar 926 must be placed or "rezzed" there. Placing an avatar requires the 927 cooperation between the agent domain and the region domain 928 controlling the system with authority for the target virtual 929 location. The quality of the system describing this interaction is 930 "avatar presence." 932 3.2.1. Establishing Presence with the Region Domain 934 Once authenticated with the agent domain, the client application has 935 established "account presence." Once in possession of a valid seed 936 capability, the client application may request a set of capabilities 937 representing services offered by the agent domain: digital asset 938 management, instant message and voice chat support as well as placing 939 the user's avatar into the virtual world. 941 Placing an avatar in the virtual world begins with the client 942 exercising the "place my avatar in a region" capability. As part of 943 this transaction, the client provides the URI representing a region. 944 Upon receipt of this request, the agent domain determines the 945 validity of the URL provided, and if the URL resolves to a trusted 946 region domain begins the protocol between the agent domain and the 947 region domain to place the user's avatar in the region. 949 The precise exchange of messages between each party is beyond the 950 scope of this document, but is described in the VWRAP Teleport 951 specification But a few important points should be noted: 953 o The protocol endpoint at the agent domain the client application 954 uses to place the user's avatar in a region is provided to the 955 client as a capability following successful authentication. It is 956 not a publicly defined, fixed URL. 958 o The region the client wishes the agent domain to place their 959 avatar in is represented as a URI. This URI may be a URN, in 960 which case the agent domain SHOULD have the ability to convert the 961 URN into a URL. If the target region is identified by a URL, it 962 MUST use the HTTP [RFC2616] or HTTPS [RFC2817] URI schemes. 964 o The agent domain MAY apply a local policy to the URI and reject 965 the request before attempting to connect with the region domain. 966 (a "behind the firewall" agent domain may limit clients connecting 967 to it to systems known to be inside the local intranet, for 968 instance.) 970 o The agent domain MAY apply a local policy and reject the request 971 after it makes an initial communication request with the remote 972 region. (for example, if the region domain is operating servers 973 with expired TLS certificates, or if those certificates are issued 974 by a certifying authority the agent domain does not trust, it may 975 reject the request.) 977 o The process of placing the avatar in the region results in 978 capabilities from the region being communicated back to the agent 979 domain for controlling the avatar. The agent domain SHOULD 980 forward these capabilities to the client application. 982 o The process also results in the agent domain issuing capabilities 983 to the region domain, allowing it limited access to information 984 about the avatar such as the avatar's shape and appearance. 986 After an avatar is "placed" in a region, the agent domain is 987 responsible for maintaining it's presence. That is to say, after the 988 avatar has been successfully been placed in the region, the agent 989 domain MUST refuse to allow a second region to "take" the avatar's 990 presence without removing the avatar from its current region. 992 3.2.2. Moving Presence 994 When an avatar moves between regions, special care must be taken that 995 the agent domain and both the source and destination regions end the 996 process with the same understanding as to the avatar's location. 998 Moving between regions is typically initiated by the client. The 999 process is largely the same as the initial avatar placement, but with 1000 the important added step of removing the avatar from it's source 1001 location before rezzing it in it's destination. (In fact, the 1002 initial placement of an avatar can be thought of as a transfer from 1003 "nowhere.") 1005 The process of moving between regions is described in the VWRAP 1006 Teleport specification, thought implementers should keep the 1007 following important considerations in mind: 1009 o The client signals to the agent domain it's desire to move from 1010 one region to another by accessing the same capability as is used 1011 for initial placement of the avatar. 1013 o The agent domain must again check that local policy allows 1014 movement to the new destination, and MUST receive a capability for 1015 placing the client into the new region before it removes the 1016 avatar from it's current location. 1018 o The agent domain MUST also remove the avatar from it's current 1019 location before placing the avatar in the destination location. 1020 Capabilities granted to the current region MUST be revoked as part 1021 of this process. 1023 o The location of the avatar MUST be unambiguous and the agent 1024 domain MUST NOT represent the avatars location as being in two 1025 places at once. If required, for the short period between 1026 removing the avatar from one region and placing it in another, the 1027 avatar's location may be "in transit." 1029 3.3. User and Group Messaging 1031 3.3.1. Spatial Messaging 1033 Besides the presence of a fully articulated 3-dimensional 1034 representation of the user, the most important feature of the virtual 1035 world is interaction. The virtual world is a social space; 1036 communication with other users is important. Because the virtual 1037 world simulates features of consensus reality, "proximity chat" or 1038 "spatial messaging" is an important function. This mode of 1039 interaction allows users to "hear" text messages that are spatially 1040 proximal to the user's avatar, while ignoring other messages. The 1041 assumption being that avatar's whose users share a common interest 1042 will congregate in specific locations in the virtual world. Or they 1043 may find their avatars in the company of other users' avatars who are 1044 engaging in interesting conversation. Either use case is possible; 1045 emulating the consensus reality feature that people can hear 1046 conversations close to them, but not hear more distant conversations 1047 is an important feature of the virtual world. 1049 Spatial messaging is managed by the region domain, and may be 1050 initiated by users' client applications or by the region itself. It 1051 is associated with an object in the virtual world (either an avatar 1052 or a "plain" object) and occurs at a particular location. The host 1053 in the region domain responsible for managing spatial chat applies a 1054 proximity algorithm to the chat to determine which avatars or objects 1055 are close enough to hear it. Those objects are all sent messages 1056 with the contents of the message. 1058 Client initiated chat begins when the client application posts a 1059 message to the capability created by the region for an avatar's 1060 outgoing chat messages. This capability is given to the client after 1061 successfully establishing presence in the region. Incoming spatial 1062 chat messages are posted to the event queue established between the 1063 client and the region. 1065 Complicating matters somewhat, spatial chat may occur near region 1066 boundaries. When this occurs, the host managing a region's messaging 1067 must have a mechanism to communicate chat messages to it's peers. 1068 Hosts responsible for spatial chat in a region must establish event 1069 queues with their peers in order to receive chat messages that 1070 originated near the region's borders. 1072 3.3.2. User to User and User to Group Messaging 1074 Instead of speaking on the "public" spatial chat channel (remember, 1075 each avatar within a defined range will be able to hear these chat 1076 messages,) users may send private user to user messages. These 1077 messages are managed by the user's agent domain. After 1078 authentication, a client may request a capability for establishing a 1079 instant messaging sessions. The client then accesses this 1080 capability, providing a unique identifier for the target user. If 1081 the agent domain is able to successfully establish a session with the 1082 target user, the message originator is provided a capability to which 1083 outgoing messages are posted. 1085 User to Group messaging is similar, but groups are used as the target 1086 for a message. 1088 Incoming user to user or user to group messages will arrive in the 1089 event queue shared by the client application and the agent domain. 1091 3.4. Digital Asset Access and Manipulation 1093 The virtual world contains multiple digital objects; they have a 1094 position and an orientation as well as a shape and potentially a 1095 texture and other features applied to them. VWRAP defines formats 1096 for describing objects and avatar shapes, but more importantly it 1097 describes the mechanism by which those digital asset descriptions are 1098 transferred between client applications, agent domains and region 1099 domains. VWRAP also defines a trust model and a basic permissions 1100 system, describing which users or groups have the ability to make 1101 changes to any given object. 1103 Digital assets may be "at rest" or "in world." Objects "at rest" 1104 exist only as a description of the object, maintained by a network 1105 addressable server and accessible via a unique URL. When an object 1106 is "rezzed in world," its representation is transferred to a 1107 simulation host in a region domain and it becomes viewable by avatars 1108 and other objects in that region. 1110 Several classes of digital assets are defined: primitive shapes, 1111 textures, sound and animations for example. In addition to the data 1112 describing the asset, metadata my be applied to objects. Unique 1113 identifiers for creators, owners and affiliated groups may be 1114 maintained by an object. Permission metadata may be added to an 1115 object to limit it's distribution to remote systems or to define the 1116 allowable operations by given users or classes of users. Object 1117 name, description and tag values may be applied and should help with 1118 indexing and searching for objects. Creation and modification dates 1119 may be applied to assist systems that cache assets. Recent 1120 discussions regarding open content licenses implies an interest in 1121 license metadata. Such metadata could be of use to consumers of 1122 digital assets; allowing them to more clearly interpret the creators 1123 intent with respect to sharing. 1125 3.4.1. Manipulating Digital Assets 1127 A number of useful manipulations of digital assets "at rest" are 1128 defined by VWRAP. Where appropriate, asset metadata may be altered 1129 by directly communicating with the network host with authority for 1130 that asset. This host may be part of the user's agent domain, or in 1131 the case of region-specific assets, it could be associated with a 1132 region domain. It is important to note, however, that not all 1133 metadata is modifiable by all users, even the asset's owner. 1134 Specifically, the semantics of the creator metadata do not allow the 1135 owner to change the creator's identity. Group membership may carry 1136 some rights like the ability to manipulate the size, shape and 1137 texture of an asset, but not an asset's owner. 1139 The ability to access or manipulate digital assets is based on the 1140 accessor's identity. Accessing and manipulating digital assets is 1141 performed via capabilities which expose the state of the asset to an 1142 authorized client. This requires positive identification of the 1143 accessor prior to access. In the case where an asset server is owned 1144 by the same authority as the agent domain, this access may be as 1145 simple as providing the proper capability after user authentication. 1146 In cases where the asset server is owned by a different authority, 1147 systems for deferred authentication may be necessary. Work is 1148 currently underway to integrate OAuth and SAML into VWRAP for this 1149 purpose. 1151 At a gross level, the types of resources exposed by a digital asset 1152 server would include: 1154 o a resource for searching an agent's inventory 1156 o a resource for iterating across an agent's inventory 1158 o a resource for accessing or manipulating a digital asset's 1159 metadata 1161 o a resource for uploading new digital assets, or changes to an 1162 existing asset. 1164 o a resource for removing a digital asset from the authority of the 1165 asset server's domain 1167 o a resource for transferring the asset or a copy of the asset to a 1168 remote asset server 1170 o a resource for instantiating an object "in world" 1172 3.4.2. Establishing Presence for Digital Assets 1174 Digital assets are intended to be used "in world," meaning there must 1175 be a way for a user to direct a simulation host to take an asset from 1176 an asset store and imbue it with presence in the virtual world. The 1177 separation between agent based services and region based services is 1178 fundamental to VWRAP and implies the authority for the system 1179 maintaining the asset "at rest" may be distinct from that which 1180 simulates the asset "in world." In practical terms, a region 1181 simulator may need to communicate with an asset server owned by a 1182 different person or company. In situations like this, trust is 1183 paramount. Because an asset's metadata may limit the owner's right 1184 to make copies of an asset, the agent domain MUST be able to trust 1185 the region domain will honor that metadata. 1187 There are two levels of trust defined when working with digital 1188 assets: host-based trust and user-based trust. The former represents 1189 one system's expectation that the other will honor the metadata 1190 regarding ownership, creatorship and rights and restrictions implied 1191 by these concepts. Host based trust is carried by X.509 / PKIX 1192 certificates and implies a managed PKI. User-based trust represents 1193 the expectation the asset server will expose sensitive resources only 1194 to users with the right to access such resources. 1196 Provided trust is established between the asset server and a 1197 simulation host, and the simulation host can demonstrate it is acting 1198 on behalf of a user with rights to access a particular resource, 1199 VWRAP defines a protocol for transferring a representation of the 1200 digital asset for simulation. As part of this protocol, access to a 1201 digital asset may be restricted while the object exists "in world." 1202 This is the case for objects whose creators or owners specify that 1203 only one copy of the asset may exist at a time. 1205 4. IANA Considerations 1207 This memo includes no request to IANA. 1209 5. Security Considerations 1211 As mentioned previously, the concept of a persistent, ubiquitous 1212 identity in the virtual world is core to the user experience. 1213 Keeping agent based services distinct from region or object based 1214 services has advantages for scalability and flexibility. However, it 1215 does have ramifications for the security of the virtual world as a 1216 whole. 1218 Most notably, this structure puts the agent domain in the role of a 1219 trust broker. That is, the agent domain is trusted both by the set 1220 of users who operate client applications and by the set of users who 1221 administer peer domains. A transitive trust relationship exists 1222 between the peer domains and end users by way of the agent domain. 1223 The administrators of the peer domain trusts the agent domain to 1224 properly identify end users, and potentially to ensure they are 1225 members of a particular class. The end users trust the agent domain 1226 to properly identify peer domains and to potentially limit the 1227 transfer of digital assets to only those domains that have explicitly 1228 agreed to honor asset permissions meta-data. 1230 VWRAP does not REQUIRE domains to adhere to any preset policy, 1231 however. It instead provides a mechanism for communicating identity 1232 information so that such a policy MAY be enforced. 1234 5.1. Capabilities 1236 VWRAP makes extensive use of RESTful resources accessed via HTTP. 1237 Application state is communicated and changed by accessing web based 1238 resources. One characteristic of such resources is they have a well 1239 defined URL, many of which are formatted as URL-based capabilities. 1240 [I-D.lentczner-vwrap-foundation] Capabilities have the characteristic 1241 that possession of the URL implies the right to access the resource 1242 it identifies. It is important that capability URLs are shared only 1243 with trusted participants. The VWRAP Base document defines the 1244 characteristics of URL-based capabilities, including the requirement 1245 that they include an unpredictable random component in the URL. 1246 Implementers need also ensure that these URLs are protected using 1247 suitable mechanisms (such as TLS, IPSec or link encryption.) 1249 5.2. User Authentication 1251 Prior to granting an end user access to any agent domain managed 1252 sensitive resource, the agent domain MUST authenticate the end user. 1253 The VWRAP Authentication specification defines three techniques for 1254 using shared secrets to authenticate end users. The agent_login 1255 resource used for end user authentication provides an extensible 1256 mechanism, allowing the development and use of additional 1257 authentication techniques (SRP, TLS Client Certificates, SASL, etc.) 1259 Again, it should be noted that VWRAP as currently defined does not 1260 REQUIRE an agent domain to support a particular authentication scheme 1261 (shared secret, public key, secure remote password, etc.) But it 1262 does define the mechanism for three shared secret options. 1264 Once a user is successfully authenticated, their client application 1265 is passed a seed capability (as described in the VWRAP Base 1266 specification.) This seed capability is used by the client 1267 application to request access to resources and services managed by 1268 the agent domain (including services like "place my avatar in the 1269 virtual world.") 1271 5.3. Agent Domain to Region Domain Authentication 1273 Agent Domain authentication, or the process of authenticating an 1274 agent host to a region host uses a X.509 PKI. Prior to 1275 communicating, the agent domain generates a key pair for a particular 1276 agent host under their control and requests a certificate from each 1277 the region domain with which they wish to interact. The region 1278 domain returns a signed certificate to the agent domain which the 1279 agent domain uses in subsequent communication with the region. 1281 5.4. Access Control for Digital Assets 1283 In addition to security characteristics addressing traditional 1284 network and user security issues, the raison d'etre of VWRAP is to 1285 communicate state concerning items inhabiting a virtual world. Some 1286 of these items may have access control restrictions within the scope 1287 of the applications used to simulate and render the virtual world. 1288 VWRAP defines an extensible permissions model which allows 1289 permissions meta-data to be associated with virtual items. 1291 6. References 1293 6.1. Normative References 1295 [I-D.hamrick-vwrap-authentication] 1296 Chu, T., Hamrick, M., and M. Lentczner, "VWRAP Trust Model 1297 and User Authentication", 1298 draft-hamrick-vwrap-authentication-00 (work in progress), 1299 February 2010. 1301 [I-D.hamrick-vwrap-type-system] 1302 Brashears, A., Hamrick, M., and M. Lentczner, "VWRAP : 1303 Abstract Type System for the Transmission of Dynamic 1304 Structured Data", draft-hamrick-vwrap-type-system-00 (work 1305 in progress), February 2010. 1307 [I-D.lentczner-vwrap-foundation] 1308 Lentczner, M., "Virtual World Region Agent Protocol: 1309 Foundation", draft-lentczner-vwrap-foundation-00 (work in 1310 progress), February 2010. 1312 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1313 Requirement Levels", BCP 14, RFC 2119, March 1997. 1315 6.2. Informative References 1317 [RFC1822] Lowe, J., "A Grant of Rights to Use a Specific IBM patent 1318 with Photuris", RFC 1822, August 1995. 1320 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1321 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1322 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1324 [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within 1325 HTTP/1.1", RFC 2817, May 2000. 1327 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1328 Resource Identifier (URI): Generic Syntax", STD 66, 1329 RFC 3986, January 2005. 1331 Appendix A. Definitions of Important Terms 1333 agent domain 1335 The agent domain is the administrative authority responsible for 1336 managing services related to avatars and users. Identity 1337 management, group membership, avatar appearance, profile 1338 information, user authentication and group messaging are examples 1339 of services and information maintained by the agent domain. 1341 agent host 1343 A network host maintained by the agent domain is called an "agent 1344 host." 1346 avatar 1348 The avatar is the representation of a user in the virtual world. 1349 The avatar's shape and appearance are used by other users to 1350 render a graphical representation of the inhabited virtual world. 1351 The user's view of the virtual world is rendered from the 1352 perspective of their avatar. 1354 client application 1356 A client application is any application that is operated for the 1357 benefit of the user. Common client applications might include a 1358 "viewer" that renders the virtual world on the user's workstation 1359 or a web application used to manipulate the user's digital 1360 assets. VWRAP does not provide a canonical list of client 1361 application categories, but if an application is not a part of an 1362 agent domain or a region domain and it is manipulating user data 1363 or an avatar on behalf of a user, with the user's permission, it 1364 is a client application. 1366 region domain 1368 The region domain is the administrative authority responsible for 1369 managing services related to presence in the virtual world and 1370 it's simulation. Typical services exposed by a region domain 1371 would include physics simulation, avatar presence and virtual 1372 object presence lifecycle management (i.e. - the creation, 1373 manipulation and destruction of objects in the virtual world.) 1375 region host 1377 A network host maintained by the region domain is called a 1378 "region host", though the historical term "simulator" is still 1379 very common. 1381 user 1383 The entity controlling an avatar in world is the "user". 1385 Appendix B. Acknowledgements 1387 The author gratefully acknowledges the contributions of: Mark 1388 Lentczner, David Levine, David Crocker, Larry Mastiner, Joshua Bell, 1389 Barry Leiba, Joe Hildebrand, Chris Newman, Katherine Mancuso and Jon 1390 Peterson. 1392 Author's Address 1394 Meadhbh Siobhan Hamrick 1395 Linden Research, Inc. 1396 945 Battery St. 1397 San Francisco, CA 94111 1398 US 1400 Phone: +1 650 283 0344 1401 Email: infinity@lindenlab.com