idnits 2.17.1 draft-ietf-vwrap-intro-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 (July 5, 2010) is 5041 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 3920 (Obsoleted by RFC 6120) -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 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 4 Internet-Draft D. Levine 5 Intended status: Informational IBM Thomas J. Watson Research 6 Expires: January 6, 2011 Center 7 July 5, 2010 9 VWRAP: Introduction and Goals 10 draft-ietf-vwrap-intro-00 12 Abstract 14 The Virtual World Region Agent Protocol (VWRAP) defines interactions 15 between hosts collaborating to create an shared, internet scale 16 virtual world experience. This document introduces the protocol, the 17 objectives and requirements it imposes on hosts implementing the 18 protocol. To the extent it affects protocol interactions, this 19 document describes the model assumed by the protocol. A document 20 roadmap is included that briefly describes the contents of other 21 documents produced by the VWRAP Working Group. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on January 6, 2011. 40 Copyright Notice 42 Copyright (c) 2010 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction and Motivation . . . . . . . . . . . . . . . . . 4 58 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 59 2. Introducing the Virtual World Region Agent Protocol . . . . . 4 60 2.1. A Brief Introduction to Virtual Worlds . . . . . . . . . . 4 61 2.2. Architectural Objectives and Requirements . . . . . . . . 6 62 3. Virtual World Region Agent Protocol Architecture . . . . . . . 8 63 3.1. Protocol Objectives . . . . . . . . . . . . . . . . . . . 8 64 3.2. Structural Architecture and Services . . . . . . . . . . . 11 65 3.2.1. The Client Application . . . . . . . . . . . . . . . . 12 66 3.2.2. Services . . . . . . . . . . . . . . . . . . . . . . . 12 67 3.2.3. Deployment Patterns . . . . . . . . . . . . . . . . . 13 68 3.3. Architectural Elements . . . . . . . . . . . . . . . . . . 14 69 3.3.1. Communicating Application State Using REST-Like 70 Resource Accesses . . . . . . . . . . . . . . . . . . 15 71 3.3.2. Bi-Directional Messaging with the VWRAP Event Queue . 15 72 3.3.3. Using Capabilities to Simplify Access Control 73 Between Trust Domains . . . . . . . . . . . . . . . . 16 74 3.3.4. Using Flexible Format Descriptions to Avoid 75 Version Skew . . . . . . . . . . . . . . . . . . . . . 17 76 4. Services Defined by the Virtual World Region Agent Protocol . 18 77 4.1. User Authentication . . . . . . . . . . . . . . . . . . . 18 78 4.2. Presence in the Virtual World . . . . . . . . . . . . . . 20 79 4.2.1. Establishing Presence with the Region Domain . . . . . 20 80 4.2.2. Moving Presence . . . . . . . . . . . . . . . . . . . 21 81 4.3. User and Group Messaging . . . . . . . . . . . . . . . . . 22 82 4.3.1. Spatial Messaging . . . . . . . . . . . . . . . . . . 22 83 4.3.2. User to User and User to Group Messaging . . . . . . . 23 84 4.4. Digital Asset Access and Manipulation . . . . . . . . . . 23 85 4.4.1. Manipulating Digital Assets . . . . . . . . . . . . . 24 86 4.4.2. Establishing Presence for Digital Assets . . . . . . . 25 87 5. Document Roadmap . . . . . . . . . . . . . . . . . . . . . . . 26 88 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 89 7. Security Considerations . . . . . . . . . . . . . . . . . . . 29 90 7.1. Capabilities . . . . . . . . . . . . . . . . . . . . . . . 29 91 7.2. User Authentication . . . . . . . . . . . . . . . . . . . 30 92 7.3. Agent Domain to Region Domain Authentication . . . . . . . 30 93 7.4. Access Control for Digital Assets . . . . . . . . . . . . 30 94 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 95 8.1. Normative References . . . . . . . . . . . . . . . . . . . 31 96 8.2. Informative References . . . . . . . . . . . . . . . . . . 31 97 Appendix A. Definitions of Important Terms . . . . . . . . . . . 32 98 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 33 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 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 protocol 109 suite is intended to carry information about a virtual world: its 110 shape, its residents and objects existing within it. VWRAP's goal is 111 to define an extensible set of messages for carrying state and state 112 change information between hosts participating in the simulation of 113 the virtual world. 115 Virtual worlds differ in their capabilities and architectural 116 features. The VWRAP protocol is not appropriate for all massively 117 multi-participant experiences. This document provides an 118 introduction to virtual worlds and defines characteristics of virtual 119 worlds VWRAP explicitly supports. It also describes the specific 120 objectives of the protocol suite. An overview of the protocol is 121 included, including an architectural description and list of services 122 defined in a typical virtual world deployment. A guide to the 123 documents proposed by the VWRAP working group is provided in an 124 effort to describe which protocol features are defined in which 125 working group deliverable. 127 1.1. Requirements Language 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in RFC 2119 [RFC2119]. 133 2. Introducing the Virtual World Region Agent Protocol 135 2.1. A Brief Introduction to Virtual Worlds 137 At its most basic level, the virtual world mirrors the reified world. 138 It is inhabited by people and contains objects. Objects and people 139 have a distinct place in the world and respond to external forces. 140 The social construction of the virtual world is also similar to the 141 reified world. People meet and interact with others to complete work 142 tasks or for simple enjoyment. People converse, share media, and 143 even sing to each other. A virtual world may allow commerce or 144 enable building of virtual assets. Nearly the complete range of 145 human interaction can be replicated in the virtual world. Properly 146 rendered, an experience in a virtual world can carry the same impact 147 as one in consensus reality. 149 To be relevant to the participant's experience, virtual worlds must 150 retain characteristics of the "real world." Objects in the virtual 151 world are models of familiar shapes and textures, represented using a 152 common data format so they may be easily processed by the human 153 visual cortex. At the same time they must carry sufficient 154 information to be consumed by participants with visual impairments or 155 to be processed by automated systems. Though the virtual world's 156 state is maintained by abstract collections of data, it is rendered 157 as recognizable (though occasionally fantastical) physical objects. 159 But virtual worlds are not completely faithful mirrors of the world 160 our physical bodies inhabit. Virtual worlds are not limited by 161 distance. With appropriate network connectivity, users may interact 162 even if they are on opposite sides of the earth. Virtual worlds also 163 allow participants to "play" with physical constraints. They provide 164 the subjective experience of things not possible in consensus 165 reality: participants can fly, the effects of "death" are temporary, 166 users may call items into existence, examine the International Space 167 Station with friends, examine DNA codon by codon with coworkers, or 168 experience with a works of interactive art. 170 Virtual worlds inherit the intellectual property characteristics of 171 other digital media. Implementers wishing to replicate the economy 172 of scarcity present in the reified world must take special measures 173 to avoid or limit the ramifications of unauthorized content 174 duplication. 176 The VWRAP suite assumes network hosts, likely operated by distinct 177 organizations will collaborate to simulate the virtual world. It 178 also assumes that services originally defined for other environments 179 (like the world wide web) will enhance the experience of the virtual 180 world. The virtual world is expected to be simulated using software 181 from multiple sources; interoperability standards are essential for 182 delivering a robust services and compelling user experiences. VWRAP 183 provides these interoperability standards. It may be used with large 184 arrays of hosts simulating a vast virtual world, or small worlds 185 operated for the benefit a few persons. It defines a trust model so 186 hosts from different organizations may limit access to sensitive 187 information. 189 VWRAP presupposes a virtual world with the following characteristics: 191 1. The virtual world exists independent of the participating 192 clients. 194 This is in contrast to systems that dynamically create virtual 195 environments for specific social or task-oriented simulation. 196 VWRAP assumes the state virtual world is "always on" and does not 197 require a specific protocol to establish new virtual worlds. 199 2. Avatars have a single, unique presence in the virtual world. 201 Users are represented in the virtual world by a digital 202 representation called an avatar. A user's avatar has an 203 existence that mirrors the common physical world. Like people, 204 avatars exist in only one place at one time. Avatars have a 205 single identity that persists between user sessions. This 206 identity may be used to render user-specific avatar shape or as 207 the basis for access control. 209 3. The virtual world contains persistent objects. 211 Objects in the virtual world are governed by a "rational" life- 212 cycle. They are created, persist and are (optionally) destroyed. 214 2.2. Architectural Objectives and Requirements 216 The overall objective of the VWRAP suite is to enable a stable, 217 extensible and secure virtual world. The protocols defined by this 218 working group do not mandate a specific system or network 219 architecture. However, previous implementations of large distributed 220 systems can yield clues as to how VWRAP compliant systems will be 221 deployed. Documents produced by this working group reflect the 222 consensus view of best common practice for producing large-scale, 223 loosely-coupled distributed systems. VWRAP does not require a 224 specific architecture, but its protocols are defined with a specific 225 series of architectural patterns in mind. 227 These architectural patterns have the following objectives in mind: 229 1. Systems implementing virtual world services must be distributed. 231 Virtual worlds are inherently distributed systems. They are 232 collaborative tools intended to reduce the effect of distance on 233 meaningful social, educational and commercial interaction. 234 Typical virtual worlds are envisioned as drawing services from 235 network hosts operated by a wide array of organizational 236 entities. Virtual worlds may also be large enough that a single 237 system or cluster of systems is not capable of providing all 238 services to each client. 240 Experience with previous virtual world technologies suggests 241 systems implementing the virtual world assume services they 242 depend on are provided by distinct hosts in different 243 administrative domains. The virtual world, its user base and the 244 constellation of virtual objects they use are simply too vast and 245 varied to assume a single system or a single provider. 247 This does not mean, however, that virtual worlds simulated by the 248 VWRAP suite must exist on more than one system. Quite the 249 contrary, all VWRAP components (including the user agent) could 250 operate on a single system. But there is little reason to 251 believe the protocol used to exchange information between virtual 252 world services must differ between small and large systems. 254 Large virtual worlds with many users are certain to implement 255 virtual world services differently than small ones. But the 256 protocol used to to communicate between systems implementing the 257 virtual world can be the same. To be sure, optimizations may be 258 possible for smaller deployments. Implementers of these "small" 259 systems may find it useful to utilize standard, unoptimised 260 protocols to allow for the possibility of growth. 262 But however large (or small) a virtual world deployment is, or 263 how many distinct organizations contribute to its operation, 264 software implementing virtual world services MUST assume 265 resources required to perform its function are distributed 266 amongst multiple hosts. 268 2. Services supporting collaboration are hosted on 'central' 269 systems. 271 The "authoritative state" of the virtual world is stored on 272 'central' servers. Clients use protocols described in the VWRAP 273 suite to access this state information (or to notified of state 274 changes.) This is in contrast to some virtual world and 275 Massively Multi-Participant systems in which state may be 276 distributed. This is in contrast to 'client authoritative' or 277 'co-simulation' architectures in which each client is required to 278 perform physics simulation for objects within view of the user's 279 avatar. 281 3. Virtual world services default to being 'open'. 283 The VWRAP suite does not describe protocols for exclusive use 284 within a "walled garden." Implementers and deployers are given 285 the freedom to identify information sources and to determine 286 which entities on the network they will trust. Service deployers 287 may limit which users may access their services to a small set of 288 individuals, employees of a particular company, residents of a 289 particular country, users of a particular website. Or they may 290 impose no restrictions whatsoever. It is entirely up to the 291 service operator. 293 These same operators may require virtual assets to be hosted on 294 their own servers, or they may identify a list of trusted asset 295 servers operated by other organizations. Or they may impose no 296 restrictions whatsoever. The decision is entirely up to the 297 service operator. 299 The VWRAP suite describes protocols that are by default, "open." 300 There is no requirement in these specifications that arbitrary 301 bindings between services be enforced. In other words, requiring 302 two services (e.g. - physics simulation and asset storage) be 303 managed by the same organization's servers is an issue of local 304 policy, not of protocol. 306 3. Virtual World Region Agent Protocol Architecture 308 3.1. Protocol Objectives 310 The primary objective of the Virtual World Region Agent Protocol is 311 to provide a stable, extensible, secure system for virtual world 312 information interchange with the following characteristics: 314 1. Identity is universal. 316 Many network services are provided anonymously; the nature of the 317 service does not require identity authentication prior to its 318 use. But with the increasing deployment of customizable services 319 delivered on the internet, identity is increasingly important. 320 Even services that contain information that might not be 321 considered "sensitive" require a representation of digital 322 identity if for no other reason than to match service requests 323 with user preferences. For example, a web page presenting 324 current weather information may be enhanced by remembering 325 locations of interest to each user. Recent work with "web mash 326 ups," where multiple personalized or v sensitive resources are 327 used in concert with one another points to the utility of a 328 "universal" identity. The representation of this universal 329 identity enables independent services to cooperate to present the 330 facade of a unified application to the service consumer. This 331 allows service aggregators to more easily integrate "best of 332 breed" services into a consistent solution. 334 Universal identity is critical to the virtual world. To achieve 335 an internet scale virtual world, user services must be 336 distributed amongst multiple hosts. To achieve a compelling 337 experience, it must be easy for service providers to deliver 338 their services in the virtual world. To facilitate a compelling 339 social experience in the virtual world, all users must have the 340 ability evaluate identity information of other users. Domains 341 responsible for virtual world simulation MUST use a consistent 342 representation of identity across all their hosts; simulation 343 would otherwise be uncoordinated. Service providers who deliver 344 content into the virtual world MUST use a consistent 345 representation of identity to maintain the persistence of the 346 virtual manifestation of their service; virtual objects used in 347 conjunction with these services might otherwise appear to change 348 state without apparent cause. Users depend on the persistent, 349 universal identity of other users; if an avatar's identity 350 changed unexpectedly, the result would be a suboptimal virtual 351 world experience. 353 2. Presentation of protocol data is in a flexible fashion. 355 While the primary purpose of the virtual world is to simulate a 356 physical or social space, the tools used to access objects in the 357 virtual world may be varied. Using a "3d viewer" is the primary 358 mode of interaction with the virtual world, but other tools may 359 be better suited for some tasks. For instance, it may be easier 360 for a user to use a web browser to review avatar profile 361 information, or to change details of virtual objects. Further, 362 virtual world "mash ups" may prove to be important to some 363 communities. To support the web (where XML [XML2008] and JSON 364 [ECMA262] are the lingua franca of information exchange) while 365 also supporting tools where binary encodings are more 366 appropriate, VWRAP was designed to be "presentation neutral." 368 VWRAP resources are intended to be accessed via HTTP [RFC2616] or 369 HTTPS [RFC2818]. In some circumstances, however, there may be 370 advantages to accessing resources using other transports. 371 HTTP(S) is well suited when request-response plus meta-data 372 semantics are desired. For instance, event streams may be better 373 suited by using XMPP [RFC3920] while time sensitive messages may 374 be better carried over RTP [RFC3550]. Except where noted, 375 implementers should assume that resources are accessed using HTTP 376 or HTTPS. 378 VWRAP protocol exchanges are described in terms of an abstract 379 type system [I-D.ietf-vwrap-type-system] describing the content 380 of virtual world resources in a language and transport neutral 381 fashion. An interface description notation allows implementers 382 and service designers to describe the flow of abstract data 383 between protocol participants. Abstract structured data types 384 and information flows are reified using serialization rules most 385 appropriate for the application. Web-based applications may 386 choose to use JSON or XML. Server-to-server interactions may use 387 the VWRAP specific binary serialization scheme if implementers 388 and deployers view binary encoding to be advantageous. The 389 decision of which serialization scheme to use is ultimately that 390 of the system implementer. VWRAP has been designed to provide 391 this flexibility to system implementers and those tasked with 392 deploying VWRAP compatible systems. 394 3. Separation of concerns and easy extension is the norm. 396 VWRAP has been designed to allow meaningful separation of 397 concerns. In other words, changes in one part of the protocol 398 should not appreciably affect other parts. 400 For example, the authentication portion of the protocol is 401 independent of the part of the protocol that deals with instant 402 messaging or instantiating objects in the virtual world. In 403 addition to defining messages for communicating application 404 state, the specification also defines pre- and post-conditions. 405 Should one particular authentication scheme be found to be 406 lacking, it can be modified or replaced without affecting other 407 systems. 409 This type of separation of concerns in the protocol specification 410 also makes it easy to deploy "related solutions." While VWRAP 411 was designed primarily to communicate the state of the virtual 412 world between servers and client applications, a number of 413 related applications also exist. E-Commerce web sites related to 414 the virtual world and mobile chat clients allowing instant 415 messaging between mobile networks and virtual world participants 416 are just two examples of such applications. Proper separation of 417 concerns allows new services to be specified and deployed without 418 the need to redefine existing protocol. 420 4. The system exhibits resilience in the face of version skew. 422 Core to the VWRAP protocol is the idea that different components 423 and services may be operated by different administrative 424 entities; identity management services might be operated one 425 business while simulation services are operated by another. In 426 environments where many different organizations participate, 427 version skew can be an important concern. VWRAP was designed to 428 "degrade gracefully" when two systems running different versions 429 of the protocol attempt to communicate. 431 VWRAP uses a flexible abstract type system and interface 432 description notation to describe the structure and type semantics 433 of elements in messages sent between systems. Because this type 434 system makes extensive use of variable width, clearly delineated 435 data fields, services which consume protocol messages may 436 identify and extract only those message elements they know how to 437 handle. While this is not a guarantee that message semantics may 438 be preserved in all version skew situations, it does eliminate 439 one important cause of interoperability failures. 441 3.2. Structural Architecture and Services 443 The Virtual World Region Agent Protocol assumes services on many 444 different network hosts will collaborate to simulate the virtual 445 world. Each service is responsible for a particular task: 446 maintaining agent presence information, physics simulation, relaying 447 text and voice chat information, etc. Services themselves are 448 comprised of resources whose attributes are accessed by way of 449 RESTful patterns at unique addresses. Because individual resources 450 are accessed using their address, they are often referred to as 451 "protocol endpoints." 453 Figure 1 below is intended to communicate the following concepts 454 regarding the structural architecture of VWRAP: 456 o VWRAP uses a client-server architecture. 458 o There are likely to be a multitude of user agents. 460 o There are likely to be several instances of each defined service 461 (i.e. - there is no single, "blessed" authentication or asset 462 service.) 464 o Services may be clients of other services (i.e. - it's not only 465 user agents that are clients.) 467 o There is no obligation that each client establish a relationship 468 with each type of service. (e.g. - it's okay to authenticate, then 469 communicate exclusively with a chat server or an asset server.) 470 +-------------+ +-------------+ +-------------+ 471 | User Agent |----->| Auth |----->| Asset | 472 | | +-->| Service 'A' | +->| Server 'A' | 473 +-------------+ | +-------------+ | +-------------+ 474 | | 475 +-------------+ | | +-------------+ 476 | User Agent |--+ | | Region | 477 | |------------------------+->| Simulator | 478 +-------------+ | +-------------+ 479 +-------------------+ | 480 +-------------+ | +-------------+ | | +-------------+ 481 | Client |--+ | Auth | | |->| Text Chat | 482 | Application |----->| Service 'B' | +--->| Service | 483 +-------------+ +-------------+ +-------------+ 485 Figure 1: Example Protocol Flows in VWRAP 487 3.2.1. The Client Application 489 VWRAP presumes the virtual world is simulated for the benefit of 490 human users. Whether that human is operating a "viewer" application 491 to render the virtual world, or using a web interface to perform 492 routine maintenance tasks, the user is expected to be operating 493 software outside the administrative control of organizations offering 494 virtual worlds services. VWRAP makes no assumptions about client 495 software save it adheres to the described protocol. 497 It is important to remember that there are likely to be more types of 498 client applications than just 3d virtual world renderers. Some 499 client applications, termed "user agents," will be intended to be 500 operated directly by human beings for their benefit. Other client 501 applications may be automated services: search and indexing, backup 502 and restore, etc. 504 3.2.2. Services 506 "Services" are loosely-coupled collections of RESTful protocol 507 endpoints, each providing access to the internal state of 508 applications simulating the virtual world. Services are operated by 509 an "End Entity," who is responsible for it's proper operation. End 510 entities will become more important when discussing the VWRAP trust 511 model. There is no requirement that the protocol endpoints that 512 comprise a service be meaningfully related, but it does tend to make 513 the system more understandable. This is to say, the VWRAP suite 514 makes no attempt to enforce a policy that services be comprised of 515 related protocol endpoints. 517 Implementers and deployers should also note that there is no 518 requirement that all endpoints in a service be operated on network 519 hosts administered by the same end entity. In other words, it is 520 perfectly acceptable for a "service" to be comprised of resources 521 whose access addresses map to hosts from multiple organizations. 522 Implementers should never assume that one trusted endpoint in a 523 service implies that all endpoints in that service are trusted. 525 3.2.3. Deployment Patterns 527 The VWRAP suite assumes that the services that simulate the virtual 528 world will be hosted on multiple network hosts. Client applications 529 that render the virtual world for end users are assumed to be on 530 distinct hosts as well. 532 +---------------------+ 533 | organization 1 | 534 | | 535 | +----------------+ | +-------------+ 536 +------>| service host 1 |<------>] | 537 | | +----------------+ | | client | 538 | | | +-->| application | 539 +-------------+ | | | | | | 540 | |<----+ | +----------------+ | | +-------------+ 541 | client |<----------->| service host 2 |<---+ ^ 542 | application | | +----------------+ | | 543 | |<----+ +---------------------+ | 544 +-------------+ | | 545 | +---------------------+ | 546 | | organization 2 | | 547 | | | | 548 | | +----------------+ | | 549 +------>| service host 3 |<---------+ 550 | +----------------+ | 551 +---------------------+ 553 Figure 2: Protocol Flows Between Organizations 555 Figure 2 above demonstrates a typical virtual world deployment. In 556 it we see multiple client applications connecting to several servers 557 operated by multiple organizations. Each "service host" in this 558 diagram exposes an interface to a collection of resources 559 representing the state of objects in the virtual world. It is 560 traditional to discuss related resources as exposing "an interface" 561 while related interfaces comprise "a service." Typical services are 562 listed in a different section. 564 There is no restriction on how services map to hosts. Deployments 565 where all resource interfaces are hosted on a single host is just as 566 valid as one where resources are spread between a wide array of 567 systems. Client applications should support both. Resource 568 interfaces are addressed using URLs. Clients should treat the URLs 569 for resources as opaque resource locations. 571 The VWRAP suite makes extensive use of capabilities. Provisioning of 572 the initial "seed capability" is described in the document describing 573 the VWRAP trust model and user authentication techniques 574 [I-D.ietf-vwrap-authentication]. The standard technique for "logging 575 in" involves querying the authentication service for the location of 576 other services. Implementers should note there are no restrictions 577 on the location of these subordinate services. They may be 578 implemented on the same host as the authentication service, or in the 579 same domain, or they may be hosted by a completely different 580 organization. 582 Operators of authentication services SHOULD configure their systems 583 to only provide clients with service locations operated by trusted 584 entities. 586 Implementers should note that client applications may be configured 587 to allow end users to ignore the authentication service and directly 588 provision their client applications to use explicit service 589 locations. Client application developers may wish to consider 590 offering such an option. Developers and operators of virtual world 591 services MUST assume the client may provide them with data from 592 untrusted services. 594 3.3. Architectural Elements 596 VWRAP utilizes a number of "architectural motifs" or recurring design 597 patterns. Most notably they include: 599 o exposing application state via RESTful resources 601 o using URIs [RFC3986] to represent the address of application 602 resources 604 o using HTTP(S) to transport message oriented protocol data 606 o using XMPP to transport data appropriately modeled as event 607 streams 609 o using (S)RTP to transport time-sensitive messages 611 o defining application resources using reified formats for abstract 612 type and interface description notations 614 o using an abstract type system to define access semantics of fields 615 in protocol messages 617 o using multiple reification schemes to "serialize" abstract 618 structured data (defined serializations include XML, JSON and 619 Binary.) 621 3.3.1. Communicating Application State Using REST-Like Resource 622 Accesses 624 Not all virtual world interactions must be real-time exchanges. Many 625 common activities like user authentication and texture and object 626 transfer do not require "real time" semantics in the same way that 627 applications like video-conferencing and Voice Over IP (VOIP) do. 628 While it is generally a better experience if textures download 629 quickly, if they are delayed, it does not have the same ramifications 630 as if a voice packet in a VOIP system were delayed. Additionally, 631 some interactions with the virtual world are strongly reminiscent of 632 the request / response semantics used by popular protocols (like 633 HTTP, POP3, etc.) 635 Because many protocol exchanges in the virtual world may be 636 represented as non-real-time request / response interactions, VWRAP 637 "reuses" the messaging semantics of HTTP. The justification for this 638 is simple. Were VWRAP to not use HTTP, many of the features of HTTP 639 would need to be re-invented or at least re-specified. Features like 640 the use of mime types to identify payload structure; the use of 641 message headers to modify the request or response and the use of URIs 642 to address and identify resources. HTTP also has the benefit of 643 being well supported by tools vendors and well understood by 644 manufacturers of networking equipment. 646 VWRAP messages that communicate request / response style messages 647 flow between clients and servers, use HTTP(S) as a message transport. 648 Message flows that are better modeled using an event stream MAY use 649 XMPP as a transport. Time sensitive messages MAY use RTP as a 650 transport. In each case, application objects representing the 651 application state expose a RESTful interface and are addressed 652 unambiguously using URIs. 654 3.3.2. Bi-Directional Messaging with the VWRAP Event Queue 656 Not all protocol interactions are easily represented by HTTP's 657 request / response semantics. When the server has a message for the 658 client, there is no widely deployed technique for the server to 659 initiate a HTTP request to the client. It is interesting to note 660 that this is the same problem developers of "rich web applications" 661 see when deploying their applications. Though VWRAP is not targeted 662 for implementation exclusively in web browsers, we can utilize some 663 of the techniques common in COMET applications. 665 Work is ongoing to define a general solution for "reverse HTTP," but 666 many of these solutions require the definition of new protocol and 667 deploying new code to web servers. The current best practice for 668 COMET-style interaction is the use of the "long poll." 670 To avoid "technology lock in," VWRAP defines an Event Queue 671 abstraction that represents the flow of messages from the server to 672 the client. The Event Queue is expected to be implemented using the 673 long poll technique. When additional options such as Reverse HTTP or 674 web sockets are specified and in general deployment, the Event Queue 675 may be re-implemented using these techniques. 677 3.3.3. Using Capabilities to Simplify Access Control Between Trust 678 Domains 680 Simulated objects and services delivered by VWRAP compliant systems 681 will require some level of access control. Distributed access 682 control is a notoriously difficult problem, however. VWRAP seeks to 683 minimize the drawbacks of distributed access control by use of 684 capabilities. In this context, a capability is an opaque URL, some 685 portion of which contains a securely generated, cryptographically 686 unguessable sequence of digits. Capabilities are used to define 687 service endpoints and are intended to only be in the possession of 688 trusted parties. 690 For example, a system may export the capability: 692 http://www.example.org/s/B2A2A445-D234-463A-BE6D-6C54E5854FE4/ 694 This URL defines the protocol endpoint used to communicate 695 application state changes (or query application state) for a specific 696 application object by a specific user (or delegate.) 698 Capabilities are required to be effectively unguessable as they 699 represent the right to perform a set of operations on a particular 700 resource. Additionally, they must be kept "secret." While the task 701 of maintaining the confidentiality of a number of web resource 702 addresses may be a burden, it does have the advantage of simplifying 703 access delegation. If a subject wishes to delegate access to a third 704 party, they simply communicate the capability. 706 To reduce the likelihood of successful guessing attacks, inadvertent 707 disclosure of a capability and "time of check, time of use" attacks, 708 capabilities in VWRAP have a fixed lifetime, after which they expire. 709 Systems SHOULD pick capability lifetimes commensurate with their 710 security requirements and MUST NOT respond to protocol requests 711 directed at a capability's URL after it has expired. Additionally, 712 VWRAP capabilities may be "single use" or "one shot," meaning that 713 they may only be used once before expiring. 715 Because capabilities are randomly generated with a short lifetime, 716 VWRAP defines a mechanism for securely communicating capabilities and 717 re-requesting expired capabilities. 719 It is important to note that capabilities do not completely replace 720 traditional access control models. Systems may still use traditional 721 Subject-Permission-Object schemes to represent access control for 722 objects under their control. Capabilities provide a mechanism for 723 communicating access control decisions among loosely coupled trusted 724 systems. 726 3.3.4. Using Flexible Format Descriptions to Avoid Version Skew 728 It is a common practice in large, complicated software systems to 729 divide the system into smaller, more manageable pieces. The precise 730 nature of this partitioning is beyond the scope of this protocol. 731 Practical experience has demonstrated that services distributed 732 across multiple cooperating hosts must contend with the issue of 733 version skew. Simply stated, version skew is the condition where 734 multiple versions of a service are interoperating simultaneously. 736 There are many reasons why version skew may be introduced. In VWRAP, 737 services may be operated by different organizations with different 738 deployment schedules. Or perhaps one particular service operator is 739 required to support an obsolete version of a particular service 740 endpoint for a small number of customers. Whatever the cause of 741 version skew, it has, in the past introduced difficulties in 742 deploying distributed services. 744 VWRAP does not seek to eliminate version skew, but attempts to reduce 745 its impact. VWRAP services are defined in using an abstract 746 interface description notation. It defines the type semantics of 747 fields inside a protocol message using an abstract type system. Each 748 of the types defined in its abstract type system has a default value 749 and common conversions between conformable types are defined. The 750 protocol also defines systems for serializing protocol messages prior 751 to transmission across the network. Each of serialization scheme 752 renders protocol messages into a collection of variable length 753 fields. Protocol content is identified by JSON syntax, binary tags 754 or XML element semantics, not by its position in the message. The 755 abstract type system and interface notation does not support the 756 concept of a "required field." If a field defined in a protocol 757 interaction is not present in the serialized message, it is 758 semantically equivalent to the field being present and containing the 759 default value for the field's type. 761 Careful construction of application resources allows them to operate 762 without fear version skew induced format differences may cause the 763 semantics of the message to be unclear. If a message arrives at a 764 service endpoint with extra fields (fields defined in a later 765 revision of the protocol exchange), the consumer can still extract 766 those fields it understands. If a message arrives lacking a field 767 described in the protocol exchange, the service endpoint SHOULD 768 interpret it as if the field was present and contained the default 769 value for its type. This implies the message consumer cannot depend 770 on the format of the message to determine validity, but must examine 771 the contents of the message, converting missing fields to present 772 fields with default values, and then determine if sufficient 773 information is present to imply semantics about the protocol 774 exchange. 776 This technique will not eliminate all ramifications of version skew, 777 but carefully constructed service descriptions should be able to 778 avoid the most common problems found when services interoperate with 779 minor revision differences. While the Virtual World Region Agent 780 Protocol itself does not mandate this style of message 781 interpretation, it does require that messages be constructed so that 782 service endpoints may do so. 784 4. Services Defined by the Virtual World Region Agent Protocol 786 4.1. User Authentication 788 User Authentication in the Virtual World Region Agent Protocol is 789 intended to verify the user's authorization to control their avatar 790 in the virtual world and associated services. VWRAP currently 791 defines three methods for authenticating a user, as well as 792 recommendations for integrating some third party authentication 793 schemes. The inputs to authentication are an avatar or account 794 identifier and a related authentication token. Assuming the token is 795 successfully authenticated, the output of authentication is a seed 796 capability or "seed cap." 798 Like many VWRAP protocol exchanges, authentication protocol data is 799 represented as serialized data carried over a secure HTTPS transport. 800 The use of TLS with VWRAP authentication is recommended for all 801 deployers who do not employ some other network security scheme 802 (IPSec, link encryption, etc.) Implementers are advised that in 803 addition to user passwords and other credentials, the seed capability 804 returned after successful authentication is also considered 805 "sensitive" and should be protected with appropriate network security 806 measures. 808 Authentication schemes defined in the VWRAP Trust Model and User 809 Authentication [I-D.ietf-vwrap-authentication] specification use a 810 cryptographic hash to demonstrate the user is in possession of the 811 shared secret associated with their account. Recommendations also 812 exist for using transport authentication mechanisms (such as TLS 813 client certificates) in place of shared secrets. 815 The authentication mechanisms described above are believed to be 816 sufficient at the time of this writing. It is an unfortunate truth, 817 however, that cryptographic primitives are occasionally shown to be 818 less secure than originally believed. For this reason, VWRAP 819 Authentication was designed to be extensible; allowing future users 820 to define new authentication schemes without invalidating other 821 authentication components. A further benefit of flexibility is the 822 ability to integrate other authentication schemes into an VWRAP 823 context. OpenID and SAML, for instance, are popular identity and 824 user authentication technologies that are defined outside the IETF. 825 VWRAP's flexible authentication system allows organizations 826 responsible for these standards to define their use with VWRAP 827 without having to change the text of the VWRAP Authentication 828 standard. 830 A typical flow of events for user authentication follows. This is a 831 simplified version; readers with an interest in authentication are 832 referred to the VWRAP Trust Model and User Authentication 833 [I-D.ietf-vwrap-authentication] specification. 835 1. The end user presents their account identifier and an 836 authenticator to the authentication services of the agent domain. 837 Endpoints for user authentication protocol messages are typically 838 well defined, public URLs. 840 2. The authentication service authenticates the authenticator. If 841 the credentials cannot be authenticated, an error condition is 842 returned. 844 3. The authentication service generates a seed capability and 845 returns it to the user. 847 4. The user queries the "seed cap," requesting capabilities for 848 other services the user is authorized to use. 850 It is important to note that in the last step listed above, the 851 client is free to request a subset of services offered by the agent 852 domain. This allows the same authentication service to be used by 853 restricted clients (for instance, a group-chat only client) as well 854 as traditional 3d viewers. 856 4.2. Presence in the Virtual World 858 "Presence" in VWRAP refers to at least two related concepts: account 859 presence and avatar presence. "Account Presence" describes the 860 readiness for interaction between a user and an agent domain. A 861 client applications signals the user's readiness for interaction with 862 an agent domain's services by initiating (and completing) user 863 authentication. Once authenticated, the user is "present." But an 864 agent domain may export more services than interacting with the 865 virtual world. It is conceivable a user may simply wish to 866 manipulate their profile data, reorganize their digital assets, or 867 make use of messaging services exported by the agent domain. 868 Interacting with these services requires only "account presence." 869 This type of presence implies only a client application presented 870 legitimate credentials to the agent domain's authentication service. 872 When a user wishes to interact with the virtual world, their avatar 873 must be placed or "rezzed" there. Placing an avatar requires the 874 cooperation between the agent domain and the region domain 875 controlling the system with authority for the target virtual 876 location. The quality of the system describing this interaction is 877 "avatar presence." 879 4.2.1. Establishing Presence with the Region Domain 881 Once authenticated with the agent domain, the client application has 882 established "account presence." Once in possession of a valid seed 883 capability, the client application may request a set of capabilities 884 representing services offered by the agent domain: digital asset 885 management, instant message and voice chat support as well as placing 886 the user's avatar into the virtual world. 888 Placing an avatar in the virtual world begins with the client 889 exercising the "place my avatar in a region" capability. As part of 890 this transaction, the client provides the URI representing a region. 891 Upon receipt of this request, the agent domain determines the 892 validity of the URL provided, and if the URL resolves to a trusted 893 region domain begins the protocol between the agent domain and the 894 region domain to place the user's avatar in the region. 896 The precise exchange of messages between each party is beyond the 897 scope of this document, but is described in the VWRAP Teleport 898 specification But a few important points should be noted: 900 o The protocol endpoint at the agent domain the client application 901 uses to place the user's avatar in a region is provided to the 902 client as a capability following successful authentication. It is 903 not a publicly defined, fixed URL. 905 o The region the client wishes the agent domain to place their 906 avatar in is represented as a URI. This URI may be a URN, in 907 which case the agent domain SHOULD have the ability to convert the 908 URN into a URL. If the target region is identified by a URL, it 909 MUST use the HTTP [RFC2616] or HTTPS [RFC2817] URI schemes. 911 o The agent domain MAY apply a local policy to the URI and reject 912 the request before attempting to connect with the region domain. 913 (a "behind the firewall" agent domain may limit clients connecting 914 to it to systems known to be inside the local intranet, for 915 instance.) 917 o The agent domain MAY apply a local policy and reject the request 918 after it makes an initial communication request with the remote 919 region. (for example, if the region domain is operating servers 920 with expired TLS certificates, or if those certificates are issued 921 by a certifying authority the agent domain does not trust, it may 922 reject the request.) 924 o The process of placing the avatar in the region results in 925 capabilities from the region being communicated back to the agent 926 domain for controlling the avatar. The agent domain SHOULD 927 forward these capabilities to the client application. 929 o The process also results in the agent domain issuing capabilities 930 to the region domain, allowing it limited access to information 931 about the avatar such as the avatar's shape and appearance. 933 After an avatar is "placed" in a region, the agent domain is 934 responsible for maintaining its presence. That is to say, after the 935 avatar has been successfully been placed in the region, the agent 936 domain MUST refuse to allow a second region to "take" the avatar's 937 presence without removing the avatar from its current region. 939 4.2.2. Moving Presence 941 When an avatar moves between regions, special care must be taken that 942 the agent domain and both the source and destination regions end the 943 process with the same understanding as to the avatar's location. 945 Moving between regions is typically initiated by the client. The 946 process is largely the same as the initial avatar placement, but with 947 the important added step of removing the avatar from its source 948 location before rezzing it in its destination. (In fact, the initial 949 placement of an avatar can be thought of as a transfer from 950 "nowhere.") 952 The process of moving between regions is described in the VWRAP 953 Teleport specification, thought implementers should keep the 954 following important considerations in mind: 956 o The client signals to the agent domain its desire to move from one 957 region to another by accessing the same capability as is used for 958 initial placement of the avatar. 960 o The agent domain must again check that local policy allows 961 movement to the new destination, and MUST receive a capability for 962 placing the client into the new region before it removes the 963 avatar from its current location. 965 o The agent domain MUST also remove the avatar from its current 966 location before placing the avatar in the destination location. 967 Capabilities granted to the current region MUST be revoked as part 968 of this process. 970 o The location of the avatar MUST be unambiguous and the agent 971 domain MUST NOT represent the avatars location as being in two 972 places at once. If required, for the short period between 973 removing the avatar from one region and placing it in another, the 974 avatar's location may be "in transit." 976 4.3. User and Group Messaging 978 4.3.1. Spatial Messaging 980 Besides the presence of a fully articulated 3-dimensional 981 representation of the user, the most important feature of the virtual 982 world is interaction. The virtual world is a social space; 983 communication with other users is important. Because the virtual 984 world simulates features of consensus reality, "proximity chat" or 985 "spatial messaging" is an important function. This mode of 986 interaction allows users to "hear" text messages that are spatially 987 proximal to the user's avatar, while ignoring other messages. The 988 assumption being that avatar's whose users share a common interest 989 will congregate in specific locations in the virtual world. Or they 990 may find their avatars in the company of other users' avatars who are 991 engaging in interesting conversation. Either use case is possible; 992 emulating the consensus reality feature that people can hear 993 conversations close to them, but not hear more distant conversations 994 is an important feature of the virtual world. 996 Spatial messaging is managed by the region domain, and may be 997 initiated by users' client applications or by the region itself. It 998 is associated with an object in the virtual world (either an avatar 999 or a "plain" object) and occurs at a particular location. The host 1000 in the region domain responsible for managing spatial chat applies a 1001 proximity algorithm to the chat to determine which avatars or objects 1002 are close enough to hear it. Those objects are all sent messages 1003 with the contents of the message. 1005 Client initiated chat begins when the client application posts a 1006 message to the capability created by the region for an avatar's 1007 outgoing chat messages. This capability is given to the client after 1008 successfully establishing presence in the region. Incoming spatial 1009 chat messages are posted to the event queue established between the 1010 client and the region. 1012 Complicating matters somewhat, spatial chat may occur near region 1013 boundaries. When this occurs, the host managing a region's messaging 1014 must have a mechanism to communicate chat messages to its peers. 1015 Hosts responsible for spatial chat in a region must establish event 1016 queues with their peers in order to receive chat messages that 1017 originated near the region's borders. 1019 4.3.2. User to User and User to Group Messaging 1021 Instead of speaking on the "public" spatial chat channel (remember, 1022 each avatar within a defined range will be able to hear these chat 1023 messages,) users may send private user to user messages. These 1024 messages are managed by the user's agent domain. After 1025 authentication, a client may request a capability for establishing a 1026 instant messaging sessions. The client then accesses this 1027 capability, providing a unique identifier for the target user. If 1028 the agent domain is able to successfully establish a session with the 1029 target user, the message originator is provided a capability to which 1030 outgoing messages are posted. 1032 User to Group messaging is similar, but groups are used as the target 1033 for a message. 1035 Incoming user to user or user to group messages will arrive in the 1036 event queue shared by the client application and the agent domain. 1038 4.4. Digital Asset Access and Manipulation 1040 The virtual world contains multiple digital objects; they have a 1041 position and an orientation as well as a shape and potentially a 1042 texture and other features applied to them. VWRAP defines formats 1043 for describing objects and avatar shapes, but more importantly it 1044 describes the mechanism by which those digital asset descriptions are 1045 transferred between client applications, agent domains and region 1046 domains. VWRAP also defines a trust model and a basic permissions 1047 system, describing which users or groups have the ability to make 1048 changes to any given object. 1050 Digital assets may be "at rest" or "in world." Objects "at rest" 1051 exist only as a description of the object, maintained by a network 1052 addressable server and accessible via a unique URL. When an object 1053 is "rezzed in world," its representation is transferred to a 1054 simulation host in a region domain and it becomes viewable by avatars 1055 and other objects in that region. 1057 Several classes of digital assets are defined: primitive shapes, 1058 textures, sound and animations for example. In addition to the data 1059 describing the asset, metadata my be applied to objects. Unique 1060 identifiers for creators, owners and affiliated groups may be 1061 maintained by an object. Permission metadata may be added to an 1062 object to limit its distribution to remote systems or to define the 1063 allowable operations by given users or classes of users. Object 1064 name, description and tag values may be applied and should help with 1065 indexing and searching for objects. Creation and modification dates 1066 may be applied to assist systems that cache assets. Recent 1067 discussions regarding open content licenses implies an interest in 1068 license metadata. Such metadata could be of use to consumers of 1069 digital assets; allowing them to more clearly interpret the creators 1070 intent with respect to sharing. 1072 4.4.1. Manipulating Digital Assets 1074 A number of useful manipulations of digital assets "at rest" are 1075 defined by VWRAP. Where appropriate, asset metadata may be altered 1076 by directly communicating with the network host with authority for 1077 that asset. This host may be part of the user's agent domain, or in 1078 the case of region-specific assets, it could be associated with a 1079 region domain. It is important to note, however, that not all 1080 metadata is modifiable by all users, even the asset's owner. 1081 Specifically, the semantics of the creator metadata do not allow the 1082 owner to change the creator's identity. Group membership may carry 1083 some rights like the ability to manipulate the size, shape and 1084 texture of an asset, but not an asset's owner. 1086 The ability to access or manipulate digital assets is based on the 1087 accessor's identity. Accessing and manipulating digital assets is 1088 performed via capabilities which expose the state of the asset to an 1089 authorized client. This requires positive identification of the 1090 accessor prior to access. In the case where an asset server is owned 1091 by the same authority as the agent domain, this access may be as 1092 simple as providing the proper capability after user authentication. 1093 In cases where the asset server is owned by a different authority, 1094 systems for deferred authentication may be necessary. Work is 1095 currently underway to integrate OAuth and SAML into VWRAP for this 1096 purpose. 1098 At a gross level, the types of resources exposed by a digital asset 1099 server would include: 1101 o a resource for searching an agent's inventory 1103 o a resource for iterating across an agent's inventory 1105 o a resource for accessing or manipulating a digital asset's 1106 metadata 1108 o a resource for uploading new digital assets, or changes to an 1109 existing asset. 1111 o a resource for removing a digital asset from the authority of the 1112 asset server's domain 1114 o a resource for transferring the asset or a copy of the asset to a 1115 remote asset server 1117 o a resource for instantiating an object "in world" 1119 4.4.2. Establishing Presence for Digital Assets 1121 Digital assets are intended to be used "in world," meaning there must 1122 be a way for a user to direct a simulation host to take an asset from 1123 an asset store and imbue it with presence in the virtual world. The 1124 separation between agent based services and region based services is 1125 fundamental to VWRAP and implies the authority for the system 1126 maintaining the asset "at rest" may be distinct from that which 1127 simulates the asset "in world." In practical terms, a region 1128 simulator may need to communicate with an asset server owned by a 1129 different person or company. In situations like this, trust is 1130 paramount. Because an asset's metadata may limit the owner's right 1131 to make copies of an asset, the agent domain MUST be able to trust 1132 the region domain will honor that metadata. 1134 There are two levels of trust defined when working with digital 1135 assets: host-based trust and user-based trust. The former represents 1136 one system's expectation that the other will honor the metadata 1137 regarding ownership, creatorship and rights and restrictions implied 1138 by these concepts. Host based trust is carried by X.509 / PKIX 1139 certificates and implies a managed PKI. User-based trust represents 1140 the expectation the asset server will expose sensitive resources only 1141 to users with the right to access such resources. 1143 Provided trust is established between the asset server and a 1144 simulation host, and the simulation host can demonstrate it is acting 1145 on behalf of a user with rights to access a particular resource, 1146 VWRAP defines a protocol for transferring a representation of the 1147 digital asset for simulation. As part of this protocol, access to a 1148 digital asset may be restricted while the object exists "in world." 1149 This is the case for objects whose creators or owners specify that 1150 only one copy of the asset may exist at a time. 1152 5. Document Roadmap 1154 This section provides a brief overview of the thirteen documents 1155 expected to be delivered by the VWRAP working group. A brief 1156 description of each document's contents is provided. The documents 1157 may be read in any order, but reading this document followed by 1158 abstract type system specification, foundation document and 1159 authentication document is recommended. The diagram below provides 1160 recommended sequence. 1162 +-----------------+ 1163 | Intro and Goals | 1164 +-----------------+ 1165 | 1166 v 1167 +----------------------+ 1168 | Abstract Type System | 1169 +----------------------+ 1170 | 1171 +---------+--------+ 1172 | | 1173 v v 1174 +-------------+ +----------------+ 1175 | Foundations | | Authentication | 1176 +-------------+ +----------------+ 1177 | | 1178 | v 1179 | +--------+ 1180 | | Launch | 1181 | +--------+ 1182 v 1183 * all other docs 1185 Figure 3: Document Roadmap 1186 1. VWRAP : Introduction and Goals (this document) 1188 This document provides a detailed introduction to the working 1189 group's efforts. It describes the characteristics of VWRAP 1190 virtual worlds and sets objectives for the virtual world 1191 experience and requirements for the protocol. Specific verbiage 1192 relating to the proposed architecture of VWRAP virtual worlds and 1193 deployment patterns are provided. 1195 2. VWRAP : Abstract Type System for the Transmission of Dynamic 1196 Structured Data 1198 The VWRAP protocols are intended to sit at the "application 1199 layer." This means that VWRAP protocol messages may be carried 1200 over HTTP, XMPP, RTP or raw UDP. Other specifications in the 1201 VWRAP series use an interface description language and an 1202 abstract type system to specify protocol messages in a language 1203 and operating system neutral manner. The abstract type system 1204 and interface description language are defined in this document. 1205 Guidelines for carrying VWRAP over HTTP and mime types for three 1206 serialization formats are provided as well. 1208 3. VWRAP : Foundational Concepts and Transport Expectations 1210 The "foundations" document provides a brief introduction and 1211 definition of certain fundamental technical concepts referenced 1212 in VWRAP. Important concepts described in this document include 1213 capabilities, a HTTP based event queue and important issues for 1214 implementers wishing to carry VWRAP messages over new transports. 1216 4. VWRAP : Client Application Launch Message 1218 This draft defines a MIME type and message format carrying 1219 virtual world session initiation information. It is intended to 1220 be used by web browsers to launch virtual world user agents. 1221 Virtual worlds that use web authentication technologies such as 1222 OpenID, OAuth and HTTP authentication may use this message to 1223 signal the web browser to launch a client which initiates a 1224 virtual world session. 1226 5. VWRAP : Trust Model and User Authentication 1228 The VWRAP architecture assumes a distributed constellation of 1229 servers cooperating to simulate a virtual world. This document 1230 describes a trust model hosts may use to determine whether the 1231 origin of a request is trustworthy. The specification does not 1232 require a host to discard messages without origin integrity, but 1233 it does specify how messages carry attestations of inter-domain 1234 trust. This draft also defines the agent_login and optional 1235 maintenance resources for VWRAP authentication. 1237 6. VWRAP : Voice and Text Communication Channel Establishment 1239 VWRAP is expected to rely on external text and voice 1240 communications standards. XMPP is the presumed choice for text 1241 communication while RTP is the presumed choice for voice. 1242 Neither XMPP or RTP define virtual locations as addressable 1243 endpoints, so this document defines a technique for identifying 1244 them for spatial text and voice. 1246 7. VWRAP : Agent Presence Establishment 1248 Also known as "the teleport protocol," this specification defines 1249 how an authorized user's agent establishes its avatar's presence 1250 in the virtual world. 1252 8. VWRAP : Region Description Format 1254 This document defines the format of the virtual world's scene 1255 graph and the protocol interaction used by clients to retrieve 1256 it. 1258 9. VWRAP : Digital Asset Access 1260 This document defines the protocol used to request and receive 1261 information about digital assets. It also defines asset types an 1262 implementer MUST support (primitive shapes, textures, etc.) 1264 10. VWRAP : Primitive Object Format 1266 This document defines MIME types and formats for objects in the 1267 virtual world: primitive shapes, NURBS and meshes. 1269 11. VWRAP : Avatar Format 1271 Avatars are expected to require more detailed information about 1272 shape and movement than primitive shapes. This specification 1273 describes how primitive objects and (optionally) bio-mechanical 1274 skeletal models may be requested by client applications. 1276 12. VWRAP : Entity Identifiers 1278 This document describes how avatars, primitive objects, regions, 1279 assets and locations in the virtual world are represented as URIs 1280 or URLs. 1282 13. VWRAP : Time Sensitive Messages 1284 Some state updates in the VWRAP protocol are considered "time 1285 sensitive." That is, they will be useless unless delivered 1286 within a proscribed period. object updates and avatar control 1287 messages may fall in this category. This document describes the 1288 format and semantics of time sensitive messages within the VWRAP 1289 protocol. 1291 6. IANA Considerations 1293 This memo includes no request to IANA. 1295 7. Security Considerations 1297 As mentioned previously, the concept of a persistent, ubiquitous 1298 identity in the virtual world is core to the user experience. 1299 Keeping agent based services distinct from region or object based 1300 services has advantages for scalability and flexibility. However, it 1301 does have ramifications for the security of the virtual world as a 1302 whole. 1304 Most notably, this structure puts the agent domain in the role of a 1305 trust broker. That is, the agent domain is trusted both by the set 1306 of users who operate client applications and by the set of users who 1307 administer peer domains. A transitive trust relationship exists 1308 between the peer domains and end users by way of the agent domain. 1309 The administrators of the peer domain trusts the agent domain to 1310 properly identify end users, and potentially to ensure they are 1311 members of a particular class. The end users trust the agent domain 1312 to properly identify peer domains and to potentially limit the 1313 transfer of digital assets to only those domains that have explicitly 1314 agreed to honor asset permissions meta-data. 1316 VWRAP does not REQUIRE domains to adhere to any preset policy, 1317 however. It instead provides a mechanism for communicating identity 1318 information so that such a policy MAY be enforced. 1320 7.1. Capabilities 1322 VWRAP makes extensive use of RESTful resources accessed via HTTP. 1323 Application state is communicated and changed by accessing web based 1324 resources. One characteristic of such resources is they have a well 1325 defined URL, many of which are formatted as URL-based capabilities. 1326 Capabilities have the characteristic that possession of the URL 1327 implies the right to access the resource it identifies. It is 1328 important that capability URLs are shared only with trusted 1329 participants. The VWRAP Base document defines the characteristics of 1330 URL-based capabilities, including the requirement that they include 1331 an unpredictable random component in the URL. Implementers need also 1332 ensure that these URLs are protected using suitable mechanisms (such 1333 as TLS, IPSec or link encryption.) 1335 7.2. User Authentication 1337 Prior to granting an end user access to any agent domain managed 1338 sensitive resource, the agent domain MUST authenticate the end user. 1339 The VWRAP Authentication specification defines three techniques for 1340 using shared secrets to authenticate end users. The agent_login 1341 resource used for end user authentication provides an extensible 1342 mechanism, allowing the development and use of additional 1343 authentication techniques (SRP, TLS Client Certificates, SASL, etc.) 1345 Again, it should be noted that VWRAP as currently defined does not 1346 REQUIRE an agent domain to support a particular authentication scheme 1347 (shared secret, public key, secure remote password, etc.) But it 1348 does define the mechanism for three shared secret options. 1350 Once a user is successfully authenticated, their client application 1351 is passed a seed capability (as described in the VWRAP Base 1352 specification.) This seed capability is used by the client 1353 application to request access to resources and services managed by 1354 the agent domain (including services like "place my avatar in the 1355 virtual world.") 1357 7.3. Agent Domain to Region Domain Authentication 1359 Agent Domain authentication, or the process of authenticating an 1360 agent host to a region host uses a X.509 PKI. Prior to 1361 communicating, the agent domain generates a key pair for a particular 1362 agent host under their control and requests a certificate from each 1363 the region domain with which they wish to interact. The region 1364 domain returns a signed certificate to the agent domain which the 1365 agent domain uses in subsequent communication with the region. 1367 7.4. Access Control for Digital Assets 1369 In addition to security characteristics addressing traditional 1370 network and user security issues, the raison d'etre of VWRAP is to 1371 communicate state concerning items inhabiting a virtual world. Some 1372 of these items may have access control restrictions within the scope 1373 of the applications used to simulate and render the virtual world. 1374 VWRAP defines an extensible permissions model which allows 1375 permissions meta-data to be associated with virtual items. 1377 8. References 1379 8.1. Normative References 1381 [ECMA262] "ECMAScript Language Specification (5th Edition)", 1382 December 2009. 1384 [I-D.ietf-vwrap-authentication] 1385 Hamrick, M., "VWRAP : Trust Model and User 1386 Authentication", draft-ietf-vwrap-authentication-00 (work 1387 in progress), July 2010. 1389 [I-D.ietf-vwrap-type-system] 1390 Brashears, A., Hamrick, M., and M. Lentczner, "VWRAP : 1391 Abstract Type System for the Transmission of Dynamic 1392 Structured Data", draft-ietf-vwrap-type-system-00 (work in 1393 progress), July 2010. 1395 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1396 Requirement Levels", BCP 14, RFC 2119, March 1997. 1398 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1399 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1400 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1402 [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within 1403 HTTP/1.1", RFC 2817, May 2000. 1405 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1406 Jacobson, "RTP: A Transport Protocol for Real-Time 1407 Applications", STD 64, RFC 3550, July 2003. 1409 [RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence 1410 Protocol (XMPP): Core", RFC 3920, October 2004. 1412 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1413 Resource Identifier (URI): Generic Syntax", STD 66, 1414 RFC 3986, January 2005. 1416 [XML2008] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and 1417 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth 1418 Edition)", November 2008. 1420 8.2. Informative References 1422 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 1424 Appendix A. Definitions of Important Terms 1426 Agent 1428 An "agent" is the abstract information-oriented representation of 1429 a user in the system. An agent differs from an "avatar" in that 1430 it is not a visual representation and intended to be manipulated 1431 and observed by computing systems (not people.) 1433 Authentication ("Auth") Service 1435 A service responsible for accepting user credentials and 1436 providing service endpoints for other services. 1438 Avatar 1440 The "avatar" is the user's (mostly) visual representation in the 1441 virtual world. It is the entity that end users (humans) are 1442 likely interested in interacting with. 1444 Client Application 1446 A "client application" is any application that mostly consumes 1447 virtual world services. Client applications may or may not be 1448 "user agents." 1450 Region 1452 A "region" is the set of data maintained by a "simulator." 1454 Simulator 1456 A service whose primary responsibility is to simulate 3d spaces 1457 (including physics simulation and object presence maintenance) is 1458 termed a "Simulator." 1460 User 1462 The entity controlling an avatar in world is the "user". 1464 User Agent 1466 A "user agent" is a client application operated predominantly by 1467 an end user. 1469 Appendix B. Acknowledgments 1471 The author gratefully acknowledges the contributions of: Mark 1472 Lentczner, David Crocker, Larry Mastiner, Joshua Bell, Barry Leiba, 1473 Joe Hildebrand, Chris Newman, Katherine Mancuso and Jon Peterson. 1475 Authors' Addresses 1477 Meadhbh Siobhan Hamrick 1478 P.O. Box 783 1479 Boulder Creek, CA 95006 1480 US 1482 Phone: +1 650 283 0344 1483 Email: OhMeadhbh@gmail.com 1485 David W. Levine 1486 IBM Thomas J. Watson Research Center 1487 19 Skyline Drive 1488 Hawthorn, NY 10532 1489 US 1491 Phone: +1 914 784 7427 1492 Email: dwl@us.ibm.com