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