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