idnits 2.17.1 draft-wolf-vp-identity-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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 2009) is 5521 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Heiner Wolf 3 Internet-Draft virtual-presence.org 4 Intended status: Informational March 2009 5 Expires: September 5, 2009 7 Virtual Presence Identity 8 draft-wolf-vp-identity-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 September 2, 2007. 33 Copyright Notice 35 Copyright (c) 2007 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 Note 46 This protocol is proposed as input to the MMOX BoF and WG which is 47 currently being chartered. It shows, that the main point of 48 interoperability, namely the instantiation of avatars can be achieved 49 with a very simple yet powerful protocol. It shall serve as a working 50 showcase of light weight interoperation and as a reference point for 51 the discussion. 53 The protocol is Web/HTTP based, actually the transport is HTTP, the 54 container format is XML and avatar data can use any MIME type. The 55 architecture is inherently distributed by using basically XML to 56 organize asset URLs. 58 The protocol has been used by Weblin for 2 years with 3 Mio. users 59 and 25.000 concurrent clients. The primary purpose of the protocol is 60 to enable "simulators" to instantiate ("rez") avatars of users they 61 meet in a virtual world. The protocol has been designed for 62 interoperability, specifically to be able to use avatars from closed 63 virtual worlds on the Web. But it is equally suited to bridge from 64 one world to another. Actually, the Web is regarded as just one 65 virtual world with many regions, which are commonly called Web sites. 67 The protocol also offers a solution for the "foreign updates" 68 problem, where the avatar changes in one world and the change should 69 be displayed instantly in another world. Say your WoW avatar walks in 70 SL and an effect times out. That should be visible in SL with minimum 71 delay but also without maintaining long lists of subscriptions. The 72 protocol has a lean way to communicate changes. 74 The protocol addresses the "the low hanging fruit" of simulator 75 interoperability. But it is easily extensible, e.g. to virtual goods 76 ("dragon heads"). It supports variants of avatar models if multiple 77 formats are required. It provides trust using XML Signature (not 78 specified here, but in use at Weblin). OAuth is the canonical choice 79 for access authentication and selective disclosure of identity data. 81 It is assumed here, that the task of the MMOX WG will be restricted 82 to interoperability between simulators and asset services, and that 83 it will not include the communication between display and simulator. 84 There are so many different models how worlds structure their 85 communication between display and simulator. In Weblin the world 86 simulation runs in the client. In many 3D worlds the simulator is 87 regarded as a "server" which forwards scene changes to the display. 88 Games like WoW do much more simulation in the client than Second 89 Life. In the near future there will be simulation including rendering 90 in the cloud with only thin displays. For this reason the MMOX WG 91 should only work on simulator interoperability and keep the display- 92 simulator communication out of the scope. 94 This document is identical to [VPTN3]. It has been reformatted and 95 annotated for IETF submission. The document uses the term "virtual 96 presence client" to refer to an entity, which interprets avatar data 97 in order to instantiate avatars. This means any simulator, be it in a 98 grid, in a cloud, or in a client. 100 Abstract 102 A virtual presence client needs information to display people who 103 meet. It needs a name, an image, maybe an animated avatar, and more. 104 This document describes the storage and exchange of public user 105 identity data. The virtual presence identity data format is optimized 106 for VP applications, where many people need the public data of their 107 peers, some only once, some repeatedly, where changes happen 108 frequently and must be propagated quickly with minimum bandwidth. 110 Table of Contents 112 1. Introduction...................................................3 113 2. Concepts.......................................................4 114 2.1 Identity Data..............................................4 115 2.2 Identity Update............................................5 116 3. Specification..................................................5 117 3.1 Identity Data..............................................5 118 3.1.1 External Data..........................................6 119 3.1.2 Inline Data............................................6 120 3.1.3 Item Content Type......................................6 121 3.1.4 Item Order.............................................6 122 3.1.5 Item Encoding..........................................7 123 3.1.6 Item Digest............................................7 124 3.1.7 Properties.............................................7 125 3.1.8 Nickname...............................................8 126 3.1.9 Avatar.................................................9 127 3.1.10 Identity Digest.......................................9 128 3.2 Identity Update...........................................10 129 3.2.1 Identity URL..........................................10 130 3.2.2 Identity Digest.......................................11 131 3.2.3 Identity ID...........................................11 132 4. Requirements..................................................11 133 4.1 Data Format...............................................11 134 4.2 Caching and Updates.......................................12 135 4.3 Storage and Protocol......................................12 136 4.4 Ownership, Control, and Privacy...........................12 137 5. IANA requests.................................................12 138 6. Security Considerations.......................................12 139 6.1 Identity Data.............................................12 140 6.2 Identity ID...............................................13 141 7. References....................................................13 142 7.1 Informative References....................................13 144 1. Introduction 146 Any time users meet, they need at least a name to display their peer. 147 Graphical client software needs more. It shows an image or an avatar. 148 Clients also need other data for various purposes, e.g. availability 149 status, reputation, social status, a unique identifier, friends, 150 inventory, communication addresses, and probably more data types in 151 the future, than we can imagine now. 153 The data must be available to any peer. It must be available quickly. 154 It should be cached to be re-used later, when people meet again. It 155 must be updated quickly, if it changes, even if the change happens 156 while there is no association between the clients. The data must 157 always be up to date with a minimum use of bandwidth, because there 158 are many users to meet and many changes to process. 160 Clients could subscribe for updates to be notified when user data 161 changes. This would keep there local cache always up to date. 162 Subscriptions are a perfect solution for instant messaging clients, 163 where clients always show the latest information of peers on the 164 roster (buddy list). 166 But in a VP application, client software needs the information only, 167 if people meet. If user data changes, while users do not see each 168 other, the change can go unnoticed. Actually it should not be 169 propagated, because it will not be displayed anyway. The client 170 software needs the latest information only if users meet. But then it 171 the data must be available quickly with low overhead. 173 2. Concepts 175 This section describes the concepts of VP user data exchange. 176 Basically, the VP user data exchange makes sure, that users see each 177 other exactly like they want to be seen by their peers. 179 Users completely control their appearance. Users decide where they 180 store their data. All the data, that makes up the appearance on other 181 people's screens is summarized as the public "identity" of the user. 183 2.1 Identity Data 185 The identity usually has a nickname, an image, maybe a homepage URL, 186 or communication addresses. It may contain or reference an electronic 187 business card like a XMPP vCard. It may have an animated 3D model as 188 avatar. It may even include a reference to a social network rating 189 system. 191 It is up to the user to provide the data in the identity (identity 192 provider). And it is up to the user who receives the identity data to 193 display it (identity consumer). Clients are free to display the 194 information they want to display. 196 Users can change their data any time. They can change the nickname, 197 update the image, and any other item. 199 2.2 Identity Update 201 A simple way to communicate changes is a version number. The receiver 202 stores the version number with the data. A new version number means, 203 that the data changed. A unique digest of the data is very similar, 204 but more general. The only requirement is, that the digest changes 205 when the data changes. Actually a version number is a special kind of 206 digest. 208 When users meet, then their clients exchange an identifier, which 209 indicates the state of their user data. The identifier is a version 210 number or a digest, or any other short text sequence, which 211 identifies the state of the user data. If users change their data, 212 e.g. the avatar image or a nickname, then they have to make sure, 213 that their client communicates a different digest. 215 3. Specification 217 3.1 Identity Data 219 The identity is an XML document. 221 The top level identity-node contains multiple item-nodes. 223 Item-nodes either carry the item data as inner text or they reference 224 external data. 226 In addition, item-nodes may have these attributes: 228 - id: a unique identifier of the item inside the identity 229 - contenttype: indicates how to use the item, e.g. "avatar" 230 - mimetype: data type, e.g. "image/gif" 231 - order: a number, which indicates the display preference, if there 232 are multiple items of the same contenttype 233 - size: size of the item in bytes 234 - encoding: encoding of the node text, if any 235 - digest: a version identifier, which indicates the version of the 236 item 237 - src: a URL, which points to the data. 239 Example: 241 242 243 250 255 256 257 258 259 260 ]]> 261 263 3.1.1 External Data 265 External data is referenced by the src-attribute. The attribute value 266 is a URL. 268 If the src-attribute is present, then the mimetype-attribute and the 269 size-attribute may be used as hints, but the real values of data size 270 and MIME-type are determined by the response when fetching the actual 271 data. 273 3.1.2 Inline Data 275 If there is no src-attribute, then the item data is the inner text of 276 the item-node. 278 The item data must be valid XML text. An optional encoding-attributes 279 allows for base64-encoding of binary data. 281 3.1.3 Item Content Type 283 The contenttype-attribute indicates how the item is to be used. The 284 client is free to ignore the attribute, but it helps to identify 285 which item is to be shown as static image, which item contains the 286 nickname, etc. 288 Possible values of the contenttype-attribute: 290 - "avatar": an static avatar image 291 - "properties": a list of key-value pairs 292 - ... 294 3.1.4 Item Order 296 An identity may contain multiple items of the same content type. 297 There might be an "avatar"-item with mimetype="avatar/gif" and 298 another one with mimetype="avatar/flash". Both need the appropriate 299 decoder software. 301 If a client has only one of the required avatar decoders, then it 302 will usually select the item, that can be displayed rather than 303 displaying none. But a client which has both decoders may use the 304 order-attribute to determine which avatar is preferred by the user 305 who provided the identity. 307 3.1.5 Item Encoding 309 Binary data must be encoded, if it is inline (inner text of the item- 310 node). 312 Possible values of the encoding-attribute: 314 - "plain": not encoded (default) 315 - "base64": the data is base64 encoded. A decoder should dismiss 316 embedded line breaks ("\r" and/or "\n"), tabs and white space. 317 - "URL": URL encoding with "&" and "=" separators, and %HH encoding 318 of characters not allowed in HTTP-URLs. 320 3.1.6 Item Digest 322 Each item-node has a digest-attribute. The value of the digest- 323 attribute must change, if the item data changes. 325 3.1.7 Properties 327 The "properties"-item contains short textual values. The item data is 328 a list of key-value pairs. 330 The "properties"-item may have mimetype="text/xml". 332 Example: 334 335 336 337 338 340 Note: inline data must be inside a CDATA section. 342 Example: 344 349 350 351 352 353 354 ]]> 355 357 Property keys currently used include: 359 - Nickname: a short label which may replace the nickname supplied by 360 the chat protocol 361 - Gender: predefined values are "female", "male", "dontknow", 362 "donttell", any other value allowed 363 - NicknameLink: a URL to be opened if people click the nickname 364 - Birthdate: free form date 365 - Profession: free form text 366 - Zodiaksign: predefined values are "Capricorn", "Aquarius", "Pisces 367 ", "Aries", "Taurus", "Gemini", "Cancer", "Leo", "Virgo", "Libra", 368 "Scorpio", "Sagittarius", any other value allowed 369 - Eyecolor: free form text 370 - Country: ISO country code 371 - Languages: comma separated list of ISO country codes (e.g. "en") 372 or language codes (e.g. "en_UK") 373 - Hobbies: free form text 374 - Interests: free form tags which describe private and professional 375 interests 376 - Statement: short text message to the world 377 - Homepage: URL 379 All keys are optional. 381 Note: there are many free form text properties. They are meant for 382 users, not for the machine. Standardized tags and/or a 383 categorizations for hobbies, interests, profession, eye color, etc. 384 may be defined separately using other keys or other identity content 385 types. 387 Note: the "properties"-item may have a mimetype="text/plain". In this 388 case the data is a line-feed separated list of key=value pairs. This 389 variant is deprecated. 391 Example: 393 Nickname=Tassadar 394 Gender=male 396 3.1.8 Nickname 398 The nickname is very important, because clients will usually display 399 a nickname and an image. Since all chat protocols support the 400 nickname natively, a nickname is always available. 402 The nickname of the identity may override the nickname supplied by 403 the chat protocol. 405 The nickname is part of the item of contenttype="properties". 407 The nickname is not globally unique. 409 The nickname should not exceed 50 characters. 411 3.1.9 Avatar 413 An item-node of contenttype="avatar" contains the data to show an 414 avatar image. The avatar may be of any type. There may be animated 415 avatars 417 There may be multiple "avatar"-items. 419 At least one of the "avatar"-items should be an image. The "avatar"- 420 image should be mimetype="image/gif", "image/jpeg", or "image/png". 421 The dimensions should be should not exceed 100x100 pixel. The data 422 size should not exceed 10 kB. All graphical clients should be able to 423 display this "avatar"-image. 425 Note: clients may discover an alternate avatar-item of 426 contenttype="avatar2". The "avatar2"-item has the same properties as 427 the "avatar"-item. 429 3.1.10 Identity Digest 431 The identity digest is communicated to other clients. 433 The identity digest must change, if any of the items changes or if 434 the list of items changes, e.g. if an item is added or removed. 436 The identity digest may be added to the identity-node as digest- 437 attribute. This is not required by identity consumers. It makes the 438 identity self-contained and simplifies identity-updates for identity 439 providers. 441 Example: 443 444 ... 445 447 Note: the identity digest can be computed as a hash (message digest, 448 e.g. MD5) of a concatenation of all item digests. 100 bytes should be 449 enough. It should not exceed 1 kB. 451 3.2 Identity Update 453 Clients communicate the identity of their users. They exchange the 454 address of the identity file, the current identity digest, and a 455 unique user ID. The details depend on the chat protocol. 457 Clients send and consume the identity triple: 459 - identity URL 460 - identity digest 461 - identity ID 463 A client, which receives such an identity-triple checks the identity 464 digest of the user identified by the identity ID. If the digest is 465 different from the one, that has been received earlier, then the 466 client fetches the identity file using the identity URL. 468 After receiving the identity file, The client checks the item digest 469 of all items for changes and fetches external item data, if required. 471 XMPP Example: 473 474 479 ... (other child-nodes) 480 482 In XMPP the identity is an extension node of the presence-node. The 483 XML name space is "firebat:user:identity" ("Firebat" is the internal 484 project name of a client). The name space will be changed in the 485 future to follow XSF and IETF recommendations. 487 The example uses an OpenID as unique identity ID (id). Anything, that 488 uniquely identifies a user will do. 490 The identity URL (src) points to the identity XML document. 492 3.2.1 Identity URL 494 The identity URL points to the identity document (3.1 "Identity 495 Data"). 497 The only URL scheme currently defined is "http". 499 The identity URL is mandatory. 501 3.2.2 Identity Digest 503 The identity digest is a short (compared to the identity data) 504 textual identifier, which uniquely identifies a state of the identity 505 data. 507 The identity digest might be a version number or a message digest of 508 all item digests. 510 When users change their identity data, then they must take care, that 511 the identity digest changes and that their client communicates the 512 new identity digest. 514 The identity digest may be stored in the identity file as a digest- 515 attribute of the identity-node. 517 The identity digest is optional, but clients should send digest and 518 ID to enable caching of the identity data. Other clients may refuse 519 to fetch identity data supplied without digest and ID. 521 3.2.3 Identity ID 523 The identity ID is the unique character string. The ID and the digest 524 are used to cache the identity data. 526 The identity ID may be an email address, the hash of an email 527 address, a URL, or any other globally unique character string. 529 Clients use the ID to associate an identity URL with a user, even if 530 the identity URL changes. A user may change the identity URL (e.g. by 531 changing the identity provider), but may still be recognized by other 532 clients. 534 The identity digest is optional, but clients should send digest and 535 ID to enable caching of the identity data. Other clients may refuse 536 to fetch identity data supplied without digest and ID. 538 4. Requirements 540 This section lists the original requirements, which lead to the 541 identity storage format described in this document. 543 4.1 Data Format 545 The format should be extensible to other data types. 547 The format should be extensible to new features. 549 The format should support multiple independent items. 551 The format should support hierarchical storage. 553 The format should be able to include items directly or by external 554 reference. 556 The encoding should be simple so, that it can be written by users. 558 The encoding should be a very common data format. 560 The encoding should be able to embed other various types. 562 4.2 Caching and Updates 564 The format should enable item caching of individual items. 566 The format should enable cache updates for individual items. 568 Update notification should work with minimum overhead. 570 The data should be up to date very quickly if people meet. 572 4.3 Storage and Protocol 574 The storage should use a very common protocol, preferably HTTP, 575 because HTTP is also the document and VPI protocol. 577 The storage should be distributed. There should not be a single 578 storage server for user data. 580 The storage address should be a single address, e.g. a URL. 582 4.4 Ownership, Control, and Privacy 584 Users should completely control their appearance. 586 Users should be able to change the storage address quickly, if they 587 move to another provider, without loosing their identity. 589 Users should be able to control their appearance. 591 Anonymous access of user data should be possible. In addition the can 592 be personalized access to control the disclosure of information 593 selectively. 595 5. IANA requests 597 This memo includes no request to IANA. 599 6. Security Considerations 601 6.1 Identity Data 603 The identity data is public. Anyone can access the data. There should 604 be a selective disclosure which differentiates between requesting 605 users. 607 6.2 Identity ID 609 While the identity ID is primarily used for caching, it can be used 610 to identify users between visits. Clients may change identity ID, 611 digest, and URL from time to time. But frequent changes render 612 identity data caching useless. This would result in greatly increased 613 traffic. 615 Rather, users might accept the fact, that their virtual presence 616 actually makes them present to other users and that their peers may 617 remember meeting them. The positive effects of meeting people and 618 recognizing friends probably outweighs privacy implications, as they 619 do in the real world. 621 7. References 623 7.1 Informative References 625 [VPTN3] http://www.virtual-presence.org/notes/VPTN-3.txt 627 Author's Address 629 Heiner Wolf 630 Waterloostr. 26 631 22769 Hamburg 632 Germany 634 Email: wolf.heiner@gmail.com