idnits 2.17.1 draft-ietf-vwrap-launch-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 5015 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4288 (Obsoleted by RFC 6838) -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 5849 (Obsoleted by RFC 6749) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 4 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 J. Hurliman 5 Intended status: Informational Intel Corporation 6 Expires: January 6, 2011 July 5, 2010 8 Virtual World Region Agent Protocol : Client Application Launch Message 9 draft-ietf-vwrap-launch-00 11 Abstract 13 This document describes the LLIDL interface description for the 14 Virtual World Region Agent Protocol (VWRAP) Client Application Launch 15 message format. Messages in this format are intended to be used in 16 conjunction with standard web authentication or authorization 17 technologies such as OpenID or OAuth. This document describes the 18 message format, the processing expectations and three MIME types that 19 may be used to identify requests to initiate a virtual worlds 20 session. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on January 6, 2011. 39 Copyright Notice 41 Copyright (c) 2010 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 58 2. The VWRAP Client Application Launch Message Format . . . . . . 3 59 3. Message Flow . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 4. Processing Expectations . . . . . . . . . . . . . . . . . . . 6 61 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 62 6. MIME Type Registrations . . . . . . . . . . . . . . . . . . . 7 63 6.1. MIME Type Registration for application/calm+xml . . . . . 7 64 6.2. MIME Type Registration for application/calm+json . . . . . 8 65 6.3. MIME Type Registration for application/calm+binary . . . . 9 66 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 67 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 68 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 69 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 72 1. Introduction 74 Web authentication protocols such as OpenID [OPENID] and web 75 authorization protocols such as OAuth [RFC5849] are of increasing 76 interest to the internet community. They have great utility in web- 77 based application environments. Best practice for their use in 78 conjunction with applications that do not expose a HTML rendering 79 interface is less clear. Virtual World (VW) client applications, for 80 instance, are often implemented as "desktop applications" instead of 81 "web apps". This introduces difficulty in using web based 82 authentication and authorization protocols to initiate a virtual 83 world session. 85 OpenID and OAuth traditionally use a HTTP redirect [RFC2616] after 86 user or token authentication to begin an authorized session with a 87 web application. The problem in using desktop applications with "web 88 auth" technologies is that desktop applications do not generally have 89 a URL to act as the target of HTTP redirection. 91 One possible solution to this problem is to register a unique MIME 92 type [RFC2046] with the user's web browser and following successful 93 user or token authentication, redirect the user's web browser to a 94 resource with that MIME type. Upon receipt of such a resource, a 95 properly configured web browser could then launch the client desktop 96 application. 98 This document describes the format of a web resource suitable for 99 signaling the user's web browser to launch a virtual world client 100 application that uses Virtual World Region Agent Protocol (VWRAP) 101 Authentication [I-D.ietf-vwrap-authentication] to establish a session 102 between the client application and network resources implementing the 103 virtual world. 105 1.1. Requirements Language 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in RFC 2119 [RFC2119]. 111 2. The VWRAP Client Application Launch Message Format 113 The Client Application Launch message is an LLSD 114 [I-D.ietf-vwrap-type-system] message, defined by the LLIDL below, but 115 is identified with a unique MIME type (described below.) It may be 116 transmitted in XML, JSON or Binary format, at the web server's 117 convenience. Compliant client applications SHOULD support XML, JSON 118 and Binary serialization formats. 120 ; note that the &request defined here uses named type &authenticator 121 ; which is defined in draft-ietf-vwrap-authentication-00 123 &request = { 124 authenticator : &authenticator, 125 account_name : string, 126 loginurl : uri, 127 region : uri 128 } 130 %% launch_request << &request 132 Figure 1 : VWRAP Client Application Launch Message 134 3. Message Flow 136 The VWRAP Client Application Launch Message is intended to be sent by 137 a web server to a web browser following successful authentication. 138 Requirements for web authentication are explicitly not defined in 139 this document, and left as a responsibility of the authenticating web 140 service. 142 Two techniques for processing a client application launch message are 143 defined. The first requests a one time "single use only" secret from 144 an agent domain. This secret is used to authenticate the client to 145 the agent domain. The second technique uses possession of a web 146 capability to authenticate the client. The message flow for both 147 techniques is the same. 149 Figure 2 below shows message flows between four conceptual entities. 150 It is provided for expository purposes only; implementers may choose 151 to combine conceptual entities into fewer reified components. That 152 is, nothing in this specification should be interpreted to require 153 four distinct, deployed entities. 155 +------------------+ 2. +--------------------+ 156 | |---------------->| | 157 | Web Auth Service | 3. | VWRAP Agent Domain | 158 | |<----------------| | 159 +------------------+ +--------------------+ 160 ^ | ^ 161 1. | | 4. | 6. 162 | v | 163 +------------------+ 5. +--------------------+ 164 | |---------------->| | 165 | Web Browser | | VWRAP Client App | 166 | | | | 167 +------------------+ +--------------------+ 169 Figure 2 : Message Flow For Client Application Launch Requests 171 0. Registering MIME types as Web Browser Helper Applications 173 The technique defined in this document depends on the traditional 174 web browser capability to define a "helper application" when the 175 browser receives a MIME type it cannot handle itself. Compliant 176 VWRAP Client Applications SHOULD register themselves as the 177 helper application for the three MIME types listed in IANA 178 Considerations (Section 5) below. 180 The exact technique used to register the client application with 181 the VWRAP Client Application Launch Message is beyond the scope 182 of this document. 184 1. Web Client to Web Server Authentication / Authorization 186 The process of launching an VWRAP client application using a web 187 based authentication or authorization system begins with 188 successful user authentication or token authentication. It is 189 traditional in these systems for the user's web browser to be 190 redirected to a web based application following authentication. 191 This document assumes the user's web browser will instead be 192 redirected to an HTTP or HTTPS URI that will eventually respond 193 with a Client Application Launch Message. 195 The exact nature of the web-based authentication or authorization 196 scheme used is beyond the scope of this document. 198 2. One Time Password or LoginURL Capability Request 200 Before the web service responsible for communicating the launch 201 message to the user's web browser may download the message, it 202 must first request a "single use only" shared secret or the 203 LoginURL web capability. 205 The exact mechanism for this request is beyond the scope of this 206 document. However, the request from the authentication service 207 to the agent domain SHOULD contain an account or avatar name 208 known to the agent domain and SHOULD be communicated over a 209 secure channel. 211 3. One Time Password or LoginURL Capability Response 213 The agent domain responds with a One Time Password or web 214 capability. If the one time password is used, the password 215 SHOULD be a sequence of unguessable octets, thought the exact 216 encoding and transport of the request is beyond the scope of this 217 document. 219 4. Client Application Launch Download 221 After the One Time Password or web capability is passed from the 222 agent domain to the authorization service, it is included in the 223 Client Application Launch Message along with an account or avatar 224 identifier, a login URI for the agent domain and an initial 225 region URI indicating the avatar's initial location in the 226 virtual world. 228 5. Web Browser Launches Client Application 230 When the user's web browser receives the Client Application 231 Launch Message, it forwards the contents of the message AND the 232 message's MIME type to the registered Client Application. 234 6. VWRAP Authentication 236 In response to receipt of the Client Application Launch Message, 237 the client application uses the information in the message to 238 begin the VWRAP Authentication process and initial placement of 239 the user's avatar in the virtual world. 241 4. Processing Expectations 243 When a client application receives a client application launch 244 message, it is expected to request a seed capability from the service 245 endpoint from in the loginurl specified in message. The loginurl is 246 expected to identify the service endpoint for an agent_login resource 247 defined in the VWRAP Trust Model and User Authentication 248 [I-D.ietf-vwrap-authentication] specification. The client SHOULD 249 pass the &authenticator and account_name map entries to the 250 agent_login resource unaltered. 252 5. IANA Considerations 254 In accordance with [RFC5226], this document registers the following 255 mime types: 257 application/calm+xml 259 application/calm+json 261 application/calm+binary 263 See the MIME Type Registrations section (Section 6) below for 264 detailed information on MIME Type registrations. 266 6. MIME Type Registrations 268 This section provides media-type registration applications (as per 269 RFC 4288 [RFC4288].) 271 6.1. MIME Type Registration for application/calm+xml 273 To: ietf-types@iana.org 275 Subject: Registration of media type application/calm+xml 277 Type name: application 279 Subtype name: calm+xml 281 Required Parameters: none 283 Optional Parameters: none 285 Encoding Considerations: The Extensible Markup Language (XML) 286 specification allows for the use of multiple character sets. The 287 character set used to encode the body of the message is defined 288 as part of the XML header. If no character set is indicated in 289 the XML header, compliant systems MUST assume UTF-8. When 290 encoding binary data using RFC 4648 [RFC4648], characters outside 291 the base alphabet are explicitly allowable and should be ignored. 293 Security Considerations: The VWRAP Client Application Launch Request 294 Message contains sensitive information. Compliant systems SHOULD 295 ensure the confidentiality of the communications media between 296 the web authentication service and the VWRAP agent domain as well 297 as that between the web authentication service and the user's web 298 browser. 300 Interoperability Considerations: While it is possible for compliant 301 implementations to specify the use of character sets other than 302 UTF-8, such systems MUST accept UTF-8 input and SHOULD generate 303 UTF-8 output. 305 Published specification: this specification. 307 Applications that use this media type: Virtual world, tele-presence 308 and content management systems related to "virtual reality" 309 systems. 311 Additional Information: 313 Magic Number(s): none 315 File Extension: calmx 317 Macintosh File Type Code(s): CALX 319 Person & email address to contact for further information: Meadhbh 320 Hamrick 322 Intended Usage: COMMON 324 Author: IESG 326 Change Controller: IESG 328 6.2. MIME Type Registration for application/calm+json 330 To: ietf-types@iana.org 332 Subject: Registration of media type application/calm+json 334 Type name: application 336 Subtype name: calm+json 337 Required Parameters: none 339 Optional Parameters: none 341 Encoding Considerations: Use of Unicode is Mandatory ECMA-262 342 [ECMA262r5] requires the use of Unicode, but allows the use of 343 UTF-8, UTF-16 or UTF-32 character encodings. 345 Security Considerations: The VWRAP Client Application Launch Request 346 Message contains sensitive information. Compliant systems SHOULD 347 ensure the confidentiality of the communications media between 348 the web authentication service and the VWRAP agent domain as well 349 as that between the web authentication service and the user's web 350 browser. 352 Interoperability Considerations: none 354 Published specification: This specification. 356 Applications that use this media type: Virtual world, tele-presence 357 and content management systems related to "virtual reality" 358 systems. 360 Additional Information: 362 Magic Number(s): none 364 File Extension: calmj 366 Macintosh File Type Code(s): CALJ 368 Person & email address to contact for further information: Meadhbh 369 Hamrick 371 Intended Usage: COMMON 373 Author: IESG 375 Change Controller: IESG 377 6.3. MIME Type Registration for application/calm+binary 379 To: ietf-types@iana.org 381 Subject: Registration of media type application/calm+binary 382 Type name: application 384 Subtype name: calm+binary 386 Required Parameters: none 388 Optional Parameters: none 390 Encoding Considerations: LLSD Binary Serialization REQUIRES the use 391 of binary content-transfer-encoding Section 5 of RFC 2045 [RFC2045] 392 describes the binary Content-Transfer-Encoding header field. 393 This specification REQUIRES the use of this header to alert 394 intermediary systems that information being included in the 395 message should be interpreted as binary data with no end-of-line 396 semantics which could be considerably longer than allowed in an 397 RFC 821 transport. 399 Security Considerations: The VWRAP Client Application Launch Request 400 Message contains sensitive information. Compliant systems SHOULD 401 ensure the confidentiality of the communications media between 402 the web authentication service and the VWRAP agent domain as well 403 as that between the web authentication service and the user's web 404 browser. 406 Interoperability Considerations: none 408 Published specification: This specification. 410 Applications that use this media type: Virtual world, tele-presence 411 and content management systems related to "virtual reality" 412 systems. 414 Additional Information: 416 Magic Number(s): none 418 File Extension: calb 420 Macintosh File Type Code(s): CALB 422 Person & email address to contact for further information: Meadhbh 423 Hamrick 425 Intended Usage: COMMON 426 Author: IESG 428 Change Controller: IESG 430 7. Security Considerations 432 Security considerations for this specification are, fortunately, 433 either simple or beyond the scope of this document. RFC 3552 434 [RFC3552] describes several aspects to use when evaluating the 435 security of a specification or implementation. The authors believe 436 most common security concerns users of this specification will 437 encounter are more appropriately considered as transport, network or 438 link layer issues. Or, as higher level "application security" 439 issues. 441 8. References 443 8.1. Normative References 445 [ECMA262r5] 446 ECMA International, "Standard ECMA-262, 5th Edition : 447 ECMAScript Language Specification", December 2009, . 451 [I-D.ietf-vwrap-authentication] 452 Hamrick, M., "VWRAP : Trust Model and User 453 Authentication", draft-ietf-vwrap-authentication-00 (work 454 in progress), July 2010. 456 [I-D.ietf-vwrap-type-system] 457 Brashears, A., Hamrick, M., and M. Lentczner, "VWRAP : 458 Abstract Type System for the Transmission of Dynamic 459 Structured Data", draft-ietf-vwrap-type-system-00 (work in 460 progress). 462 [OPENID] OpenID Foundation, "OpenID Authentication 2.0 - Final", 463 2007. 465 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 466 Extensions (MIME) Part One: Format of Internet Message 467 Bodies", RFC 2045, November 1996. 469 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 470 Extensions (MIME) Part Two: Media Types", RFC 2046, 471 November 1996. 473 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 474 Requirement Levels", BCP 14, RFC 2119, March 1997. 476 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 477 Registration Procedures", BCP 13, RFC 4288, December 2005. 479 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 480 Encodings", RFC 4648, October 2006. 482 8.2. Informative References 484 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 485 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 486 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 488 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 489 Text on Security Considerations", BCP 72, RFC 3552, 490 July 2003. 492 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 493 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 494 May 2008. 496 [RFC5849] Hammer-Lahav, E., "The OAuth 1.0 Protocol", RFC 5849, 497 April 2010. 499 Authors' Addresses 501 Meadhbh Siobhan Hamrick 502 P.O. Box 783 503 Boulder Creek, CA 95006 504 US 506 Phone: +1 650 283 0344 507 Email: OhMeadhbh@gmail.com 509 John Hurliman 510 Intel Corporation 511 3600 Juliette Lane 512 Santa Clara, CA 95051 513 US 515 Phone: +1 408 123 4560 516 Email: john.hurliman@intel.com