Internet Engineering Task Force Heiner Wolf
Internet-Draft virtual-presence.org
Intended status: Informational March 2009
Expires: September 5, 2009
Virtual Presence Identity
draft-wolf-vp-identity-00
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 2, 2007.
Copyright Notice
Copyright (c) 2007 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Note
This protocol is proposed as input to the MMOX BoF and WG which is
currently being chartered. It shows, that the main point of
interoperability, namely the instantiation of avatars can be achieved
with a very simple yet powerful protocol. It shall serve as a working
showcase of light weight interoperation and as a reference point for
Wolf Expires September 5, 2009 [Page 1]
Internet-Draft VP Identity March 2009
the discussion.
The protocol is Web/HTTP based, actually the transport is HTTP, the
container format is XML and avatar data can use any MIME type. The
architecture is inherently distributed by using basically XML to
organize asset URLs.
The protocol has been used by Weblin for 2 years with 3 Mio. users
and 25.000 concurrent clients. The primary purpose of the protocol is
to enable "simulators" to instantiate ("rez") avatars of users they
meet in a virtual world. The protocol has been designed for
interoperability, specifically to be able to use avatars from closed
virtual worlds on the Web. But it is equally suited to bridge from
one world to another. Actually, the Web is regarded as just one
virtual world with many regions, which are commonly called Web sites.
The protocol also offers a solution for the "foreign updates"
problem, where the avatar changes in one world and the change should
be displayed instantly in another world. Say your WoW avatar walks in
SL and an effect times out. That should be visible in SL with minimum
delay but also without maintaining long lists of subscriptions. The
protocol has a lean way to communicate changes.
The protocol addresses the "the low hanging fruit" of simulator
interoperability. But it is easily extensible, e.g. to virtual goods
("dragon heads"). It supports variants of avatar models if multiple
formats are required. It provides trust using XML Signature (not
specified here, but in use at Weblin). OAuth is the canonical choice
for access authentication and selective disclosure of identity data.
It is assumed here, that the task of the MMOX WG will be restricted
to interoperability between simulators and asset services, and that
it will not include the communication between display and simulator.
There are so many different models how worlds structure their
communication between display and simulator. In Weblin the world
simulation runs in the client. In many 3D worlds the simulator is
regarded as a "server" which forwards scene changes to the display.
Games like WoW do much more simulation in the client than Second
Life. In the near future there will be simulation including rendering
in the cloud with only thin displays. For this reason the MMOX WG
should only work on simulator interoperability and keep the display-
simulator communication out of the scope.
This document is identical to [VPTN3]. It has been reformatted and
annotated for IETF submission. The document uses the term "virtual
presence client" to refer to an entity, which interprets avatar data
in order to instantiate avatars. This means any simulator, be it in a
grid, in a cloud, or in a client.
Wolf Expires September 5, 2009 [Page 2]
Internet-Draft VP Identity March 2009
Abstract
A virtual presence client needs information to display people who
meet. It needs a name, an image, maybe an animated avatar, and more.
This document describes the storage and exchange of public user
identity data. The virtual presence identity data format is optimized
for VP applications, where many people need the public data of their
peers, some only once, some repeatedly, where changes happen
frequently and must be propagated quickly with minimum bandwidth.
Table of Contents
1. Introduction...................................................3
2. Concepts.......................................................4
2.1 Identity Data..............................................4
2.2 Identity Update............................................5
3. Specification..................................................5
3.1 Identity Data..............................................5
3.1.1 External Data..........................................6
3.1.2 Inline Data............................................6
3.1.3 Item Content Type......................................6
3.1.4 Item Order.............................................6
3.1.5 Item Encoding..........................................7
3.1.6 Item Digest............................................7
3.1.7 Properties.............................................7
3.1.8 Nickname...............................................8
3.1.9 Avatar.................................................9
3.1.10 Identity Digest.......................................9
3.2 Identity Update...........................................10
3.2.1 Identity URL..........................................10
3.2.2 Identity Digest.......................................11
3.2.3 Identity ID...........................................11
4. Requirements..................................................11
4.1 Data Format...............................................11
4.2 Caching and Updates.......................................12
4.3 Storage and Protocol......................................12
4.4 Ownership, Control, and Privacy...........................12
5. IANA requests.................................................12
6. Security Considerations.......................................12
6.1 Identity Data.............................................12
6.2 Identity ID...............................................13
7. References....................................................13
7.1 Informative References....................................13
1. Introduction
Any time users meet, they need at least a name to display their peer.
Graphical client software needs more. It shows an image or an avatar.
Clients also need other data for various purposes, e.g. availability
Wolf Expires September 5, 2009 [Page 3]
Internet-Draft VP Identity March 2009
status, reputation, social status, a unique identifier, friends,
inventory, communication addresses, and probably more data types in
the future, than we can imagine now.
The data must be available to any peer. It must be available quickly.
It should be cached to be re-used later, when people meet again. It
must be updated quickly, if it changes, even if the change happens
while there is no association between the clients. The data must
always be up to date with a minimum use of bandwidth, because there
are many users to meet and many changes to process.
Clients could subscribe for updates to be notified when user data
changes. This would keep there local cache always up to date.
Subscriptions are a perfect solution for instant messaging clients,
where clients always show the latest information of peers on the
roster (buddy list).
But in a VP application, client software needs the information only,
if people meet. If user data changes, while users do not see each
other, the change can go unnoticed. Actually it should not be
propagated, because it will not be displayed anyway. The client
software needs the latest information only if users meet. But then it
the data must be available quickly with low overhead.
2. Concepts
This section describes the concepts of VP user data exchange.
Basically, the VP user data exchange makes sure, that users see each
other exactly like they want to be seen by their peers.
Users completely control their appearance. Users decide where they
store their data. All the data, that makes up the appearance on other
people's screens is summarized as the public "identity" of the user.
2.1 Identity Data
The identity usually has a nickname, an image, maybe a homepage URL,
or communication addresses. It may contain or reference an electronic
business card like a XMPP vCard. It may have an animated 3D model as
avatar. It may even include a reference to a social network rating
system.
It is up to the user to provide the data in the identity (identity
provider). And it is up to the user who receives the identity data to
display it (identity consumer). Clients are free to display the
information they want to display.
Users can change their data any time. They can change the nickname,
update the image, and any other item.
Wolf Expires September 5, 2009 [Page 4]
Internet-Draft VP Identity March 2009
2.2 Identity Update
A simple way to communicate changes is a version number. The receiver
stores the version number with the data. A new version number means,
that the data changed. A unique digest of the data is very similar,
but more general. The only requirement is, that the digest changes
when the data changes. Actually a version number is a special kind of
digest.
When users meet, then their clients exchange an identifier, which
indicates the state of their user data. The identifier is a version
number or a digest, or any other short text sequence, which
identifies the state of the user data. If users change their data,
e.g. the avatar image or a nickname, then they have to make sure,
that their client communicates a different digest.
3. Specification
3.1 Identity Data
The identity is an XML document.
The top level identity-node contains multiple item-nodes.
Item-nodes either carry the item data as inner text or they reference
external data.
In addition, item-nodes may have these attributes:
- id: a unique identifier of the item inside the identity
- contenttype: indicates how to use the item, e.g. "avatar"
- mimetype: data type, e.g. "image/gif"
- order: a number, which indicates the display preference, if there
are multiple items of the same contenttype
- size: size of the item in bytes
- encoding: encoding of the node text, if any
- digest: a version identifier, which indicates the version of the
item
- src: a URL, which points to the data.
Example:
-
]]>
3.1.1 External Data
External data is referenced by the src-attribute. The attribute value
is a URL.
If the src-attribute is present, then the mimetype-attribute and the
size-attribute may be used as hints, but the real values of data size
and MIME-type are determined by the response when fetching the actual
data.
3.1.2 Inline Data
If there is no src-attribute, then the item data is the inner text of
the item-node.
The item data must be valid XML text. An optional encoding-attributes
allows for base64-encoding of binary data.
3.1.3 Item Content Type
The contenttype-attribute indicates how the item is to be used. The
client is free to ignore the attribute, but it helps to identify
which item is to be shown as static image, which item contains the
nickname, etc.
Possible values of the contenttype-attribute:
- "avatar": an static avatar image
- "properties": a list of key-value pairs
- ...
3.1.4 Item Order
An identity may contain multiple items of the same content type.
There might be an "avatar"-item with mimetype="avatar/gif" and
another one with mimetype="avatar/flash". Both need the appropriate
Wolf Expires September 5, 2009 [Page 6]
Internet-Draft VP Identity March 2009
decoder software.
If a client has only one of the required avatar decoders, then it
will usually select the item, that can be displayed rather than
displaying none. But a client which has both decoders may use the
order-attribute to determine which avatar is preferred by the user
who provided the identity.
3.1.5 Item Encoding
Binary data must be encoded, if it is inline (inner text of the item-
node).
Possible values of the encoding-attribute:
- "plain": not encoded (default)
- "base64": the data is base64 encoded. A decoder should dismiss
embedded line breaks ("\r" and/or "\n"), tabs and white space.
- "URL": URL encoding with "&" and "=" separators, and %HH encoding
of characters not allowed in HTTP-URLs.
3.1.6 Item Digest
Each item-node has a digest-attribute. The value of the digest-
attribute must change, if the item data changes.
3.1.7 Properties
The "properties"-item contains short textual values. The item data is
a list of key-value pairs.
The "properties"-item may have mimetype="text/xml".
Example:
Note: inline data must be inside a CDATA section.
Example:
-
Wolf Expires September 5, 2009 [Page 7]
Internet-Draft VP Identity March 2009
]]>
Property keys currently used include:
- Nickname: a short label which may replace the nickname supplied by
the chat protocol
- Gender: predefined values are "female", "male", "dontknow",
"donttell", any other value allowed
- NicknameLink: a URL to be opened if people click the nickname
- Birthdate: free form date
- Profession: free form text
- Zodiaksign: predefined values are "Capricorn", "Aquarius", "Pisces
", "Aries", "Taurus", "Gemini", "Cancer", "Leo", "Virgo", "Libra",
"Scorpio", "Sagittarius", any other value allowed
- Eyecolor: free form text
- Country: ISO country code
- Languages: comma separated list of ISO country codes (e.g. "en")
or language codes (e.g. "en_UK")
- Hobbies: free form text
- Interests: free form tags which describe private and professional
interests
- Statement: short text message to the world
- Homepage: URL
All keys are optional.
Note: there are many free form text properties. They are meant for
users, not for the machine. Standardized tags and/or a
categorizations for hobbies, interests, profession, eye color, etc.
may be defined separately using other keys or other identity content
types.
Note: the "properties"-item may have a mimetype="text/plain". In this
case the data is a line-feed separated list of key=value pairs. This
variant is deprecated.
Example:
Nickname=Tassadar
Gender=male
3.1.8 Nickname
The nickname is very important, because clients will usually display
Wolf Expires September 5, 2009 [Page 8]
Internet-Draft VP Identity March 2009
a nickname and an image. Since all chat protocols support the
nickname natively, a nickname is always available.
The nickname of the identity may override the nickname supplied by
the chat protocol.
The nickname is part of the item of contenttype="properties".
The nickname is not globally unique.
The nickname should not exceed 50 characters.
3.1.9 Avatar
An item-node of contenttype="avatar" contains the data to show an
avatar image. The avatar may be of any type. There may be animated
avatars
There may be multiple "avatar"-items.
At least one of the "avatar"-items should be an image. The "avatar"-
image should be mimetype="image/gif", "image/jpeg", or "image/png".
The dimensions should be should not exceed 100x100 pixel. The data
size should not exceed 10 kB. All graphical clients should be able to
display this "avatar"-image.
Note: clients may discover an alternate avatar-item of
contenttype="avatar2". The "avatar2"-item has the same properties as
the "avatar"-item.
3.1.10 Identity Digest
The identity digest is communicated to other clients.
The identity digest must change, if any of the items changes or if
the list of items changes, e.g. if an item is added or removed.
The identity digest may be added to the identity-node as digest-
attribute. This is not required by identity consumers. It makes the
identity self-contained and simplifies identity-updates for identity
providers.
Example:
...
Note: the identity digest can be computed as a hash (message digest,
e.g. MD5) of a concatenation of all item digests. 100 bytes should be
enough. It should not exceed 1 kB.
Wolf Expires September 5, 2009 [Page 9]
Internet-Draft VP Identity March 2009
3.2 Identity Update
Clients communicate the identity of their users. They exchange the
address of the identity file, the current identity digest, and a
unique user ID. The details depend on the chat protocol.
Clients send and consume the identity triple:
- identity URL
- identity digest
- identity ID
A client, which receives such an identity-triple checks the identity
digest of the user identified by the identity ID. If the digest is
different from the one, that has been received earlier, then the
client fetches the identity file using the identity URL.
After receiving the identity file, The client checks the item digest
of all items for changes and fetches external item data, if required.
XMPP Example:
... (other child-nodes)
In XMPP the identity is an extension node of the presence-node. The
XML name space is "firebat:user:identity" ("Firebat" is the internal
project name of a client). The name space will be changed in the
future to follow XSF and IETF recommendations.
The example uses an OpenID as unique identity ID (id). Anything, that
uniquely identifies a user will do.
The identity URL (src) points to the identity XML document.
3.2.1 Identity URL
The identity URL points to the identity document (3.1 "Identity
Data").
The only URL scheme currently defined is "http".
The identity URL is mandatory.
Wolf Expires September 5, 2009 [Page 10]
Internet-Draft VP Identity March 2009
3.2.2 Identity Digest
The identity digest is a short (compared to the identity data)
textual identifier, which uniquely identifies a state of the identity
data.
The identity digest might be a version number or a message digest of
all item digests.
When users change their identity data, then they must take care, that
the identity digest changes and that their client communicates the
new identity digest.
The identity digest may be stored in the identity file as a digest-
attribute of the identity-node.
The identity digest is optional, but clients should send digest and
ID to enable caching of the identity data. Other clients may refuse
to fetch identity data supplied without digest and ID.
3.2.3 Identity ID
The identity ID is the unique character string. The ID and the digest
are used to cache the identity data.
The identity ID may be an email address, the hash of an email
address, a URL, or any other globally unique character string.
Clients use the ID to associate an identity URL with a user, even if
the identity URL changes. A user may change the identity URL (e.g. by
changing the identity provider), but may still be recognized by other
clients.
The identity digest is optional, but clients should send digest and
ID to enable caching of the identity data. Other clients may refuse
to fetch identity data supplied without digest and ID.
4. Requirements
This section lists the original requirements, which lead to the
identity storage format described in this document.
4.1 Data Format
The format should be extensible to other data types.
The format should be extensible to new features.
The format should support multiple independent items.
The format should support hierarchical storage.
Wolf Expires September 5, 2009 [Page 11]
Internet-Draft VP Identity March 2009
The format should be able to include items directly or by external
reference.
The encoding should be simple so, that it can be written by users.
The encoding should be a very common data format.
The encoding should be able to embed other various types.
4.2 Caching and Updates
The format should enable item caching of individual items.
The format should enable cache updates for individual items.
Update notification should work with minimum overhead.
The data should be up to date very quickly if people meet.
4.3 Storage and Protocol
The storage should use a very common protocol, preferably HTTP,
because HTTP is also the document and VPI protocol.
The storage should be distributed. There should not be a single
storage server for user data.
The storage address should be a single address, e.g. a URL.
4.4 Ownership, Control, and Privacy
Users should completely control their appearance.
Users should be able to change the storage address quickly, if they
move to another provider, without loosing their identity.
Users should be able to control their appearance.
Anonymous access of user data should be possible. In addition the can
be personalized access to control the disclosure of information
selectively.
5. IANA requests
This memo includes no request to IANA.
6. Security Considerations
6.1 Identity Data
The identity data is public. Anyone can access the data. There should
be a selective disclosure which differentiates between requesting
Wolf Expires September 5, 2009 [Page 12]
Internet-Draft VP Identity March 2009
users.
6.2 Identity ID
While the identity ID is primarily used for caching, it can be used
to identify users between visits. Clients may change identity ID,
digest, and URL from time to time. But frequent changes render
identity data caching useless. This would result in greatly increased
traffic.
Rather, users might accept the fact, that their virtual presence
actually makes them present to other users and that their peers may
remember meeting them. The positive effects of meeting people and
recognizing friends probably outweighs privacy implications, as they
do in the real world.
7. References
7.1 Informative References
[VPTN3] http://www.virtual-presence.org/notes/VPTN-3.txt
Author's Address
Heiner Wolf
Waterloostr. 26
22769 Hamburg
Germany
Email: wolf.heiner@gmail.com
Wolf Expires September 5, 2009 [Page 13]