[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]
Versions: 00
MMOX pre-BOF C. Scholz
Internet-Draft COM.lounge
Intended status: Informational March 04, 2009
Expires: September 5, 2009
MMOX Architecture Discussion
draft-cscholz-mmox-architecture-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 5, 2009.
Copyright Notice
Copyright (c) 2009 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.
Abstract
This document tries to summarize the different problem areas in the
MMOX field and proposed an approach to build interoperability from
the bottom up starting with a flexible foundation. It also aims at
Scholz Expires September 5, 2009 [Page 1]
Internet-Draft MMOX Architecture March 2009
identifying problem spaces which are more general than the virtual
worlds field and also touch on problems found in today's social
networks.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. The individual problem fields . . . . . . . . . . . . . . . 3
1.2. Full or partial compatibility . . . . . . . . . . . . . . . 3
1.3. Problems broader than the MMOX space . . . . . . . . . . . 4
2. Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Three initial problem fields . . . . . . . . . . . . . . . 5
2.1.1. Portable Identity . . . . . . . . . . . . . . . . . . . 5
2.1.2. Distributed Authorization . . . . . . . . . . . . . . . 5
2.1.3. Service Discovery . . . . . . . . . . . . . . . . . . . 5
2.2. An example workflow . . . . . . . . . . . . . . . . . . . . 6
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Normative References . . . . . . . . . . . . . . . . . . . 7
5.2. Informative References . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8
Scholz Expires September 5, 2009 [Page 2]
Internet-Draft MMOX Architecture March 2009
1. Introduction
From the discussion on the MMOX mailing list it became clear that
o there are several fields people want to work on
o there is a big variety of virtual worlds out there which for now
at least will not be fully compatible
o that many problems discussed are broader than just the area of
massively multi-player worlds.
In order to come to a usable work result a way needs to be found to
make those worlds at least as compatible as possible or to give them
means to negotiate their capabilities.
Moreover the problems which cross the boundaries to e.g. social
networks should be solved in a more general way and with
participation of the respective communities.
1.1. The individual problem fields
As it was pointed out in the list we at least have the following
fields which are identified:
o Federated/portable Identity
o Distributed authorization
o Service Discovery
o data formats (e.g. LLSD)
o world simulation protocols
o presence protocols/services
o Licensing/permissions/DRM
All these problems are not really overlapping each other but might be
seen next to each other or in different layers.
1.2. Full or partial compatibility
There are a lot of virtual worlds vendors out there and most of them
have a different approach on how they handle 3D simulation, how they
transfer data and so on. There is eventually not much in common and
most vendors won't be willing to change their entire system for now.
Scholz Expires September 5, 2009 [Page 3]
Internet-Draft MMOX Architecture March 2009
In order to nevertheless reach some interoperability we need to find
a way to negotiate capabilities between those worlds and define if
maybe a gateway can translate from one world to another or if some
features might simply not be available.
1.3. Problems broader than the MMOX space
There are some problem fields of the list in Section 1.1 which are
not only relevant to virtual worlds but also for e.g. social
networks. These are especially
o Federated/portable identity
o Distributed Authorization
o Service Discovery
o Presence Protocols
o Licensing/permissions/DRM
It's clear from that list that only really the 3D related services
are specific to the MMOX field. That is because one can see virtual
worlds as just specialized social networks easily.
The question is now how we can proceed with these problems to find a
solution which also integrates with other parties such as the social
networking area.
2. Proposal
As describe in Section 1.2 we have a lot of existing protocols and
data formats to consider. Because of this a full standardization in
only one standard is not very likely for now. What can be done
though is to start to build a foundation on which services, be they
existing social networks or virtual worlds, can interoperate to a
certain level. A foundation might at least enable the following
things:
o Portable Idenity
o Distributed Authorization
o Service Discovery
After that one can specify those individual services and data formats
which MAY be used while they MUST support the above specifications.
Scholz Expires September 5, 2009 [Page 4]
Internet-Draft MMOX Architecture March 2009
2.1. Three initial problem fields
There are three problem fields which make sense to discuss first.
2.1.1. Portable Identity
Portable Identity means that a user does not have to register on
every new service but she can simply login on all networks/worlds
supporting the specification coming out of the MMOX WG. There is
also a lot of prior art, most prominent example probable being
OpenID. As OpenID is gaining a lot of momentum in the social
networking scene it makes sense to define it as "MUST implement".
2.1.2. Distributed Authorization
In a decentralized world not only one service holds all the data of a
user but there might be many services which all hold partial data.
Examples of such data sets can be profile, friends connection, group
memberships, assets such as photos or 3D objects and much more. Also
service providers can provide several services as e.g. world
simulation, Instant Messaging services and so on.
All these services need to protect their resources though and MUST
NOT give access to unauthorized sources. Thus the user needs to
authorize these services to a new third party service for it to have
access to them.
This again is a topic discussed not only for virtual worlds but also
for social networks or for HTTP in general. Here one solution
gaining momentum and also being chartered as an IETF WG is
OAuth[OAUTH]. It allows a service A to access resources of service B
on behalf of the user. The user needs to authorize access but can at
any point also withdraw that authorization.
The problem which still needs to be solved is mass authorization
though as OAuth relies on redirects to a service and back to the
consumer which is very user unfriendly if there is more than one
service to authorize.
2.1.3. Service Discovery
Whenever you want to access a service you need to know it's URL (if
HTTP is used). Moreoever you want to check what services a certain
virtual world supports. In order to do that a means for Service
Disovery need to be found. This means that a client which wants to
do service discovery accesses a well known URL as e.g. the main
domain name and performs a process which in the end results in a list
of services distinguished by a type. The client can then check which
Scholz Expires September 5, 2009 [Page 5]
Internet-Draft MMOX Architecture March 2009
service types and versions of those it supports and can start with
service authorization on those.
The same is true for user centric services such as profiles, friends
lists and so on. Here the endpoint from which to discover a user's
services is a URL which identifies the user such as an OpenID. In
fact OpenID uses YADIS which is nothing else than a service disovery
on the OpenID URL to check which identification methods are
supported.
Right now the field of service discovery is a bit in flux. As the
document format and the way of discovering the location of that
document so far XRDS [XRDS]has been used but work is under way to
separate the discovery mechanism from the actual format as well as
coming up with a new format for describing services. An Internet
Draft regarding service discovery can be found at [DISCOVER]
2.2. An example workflow
In order to demonstrate how those three areas can work together here
is an example.
The goal here is that a user wants to login to a certain virtual
world.
1. The user enters his unique identification URL into the
respective field in a client. He also enters the URL of the
virtual world he wants to enter.
2. The client does service discovery on the virtual world URL to
check for available 3D protocols
3. The client receives a list of supported 3D protocols of that
virtual world and selects the best one
4. The client established a connection to the virtual world.
5. The virtual world performs service discovery on the user's
identity URL and finds an authentication service suitable for
it.
6. The virtual world instantiates an auhentication for the user.
In case of OpenID it means to redirect the user to his OpenID
provider where he authenticates.
7. The OpenID provider sends a success message back to the virtual
world which now knows that the user "owns" the URL.
Scholz Expires September 5, 2009 [Page 6]
Internet-Draft MMOX Architecture March 2009
8. The virtual world now checks for further services such as
profile information or friends list.
9. For each service the user is asked if he wants to use it (if not
essential) and will then be redirected to that service to
authorize access for that virtual world
10. The virtual world retrieves access tokens that way and can then
access a user's protected resources such as profile or friends
list by using that token.
This is only a small example and it has still many shortcomings in
e.g. the authorization of each individual service. If this is solved
it is extensible though and further standardization might work on
defining those wire level protocols which are needed for simulating a
3D world or transferring objects in a secure way.
3. IANA Considerations
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
4. Security Considerations
This document proposes a process for authentication and authorization
which need to be secure. We rely on the work being done in the
respective protocols in that field, namely OpenID and OAuth.
5. References
5.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
5.2. Informative References
[DISCOVER]
Hammer-Lahav, E., "Link-based Resource Descriptor
Discovery".
[OAUTH] Hammer-Lahav, E., "OAuth Core 1.0".
Scholz Expires September 5, 2009 [Page 7]
Internet-Draft MMOX Architecture March 2009
[XRDS] Wachob, G., Chasen, L., Tan, W., and S. Churchill,
"Extensible Resource Identifier (XRI) Resolution V2.0".
Author's Address
Christian Scholz
COM.lounge
Hanbrucher Str. 33
Aachen, NRW 52064
Germany
Email: cs@comlounge.net
Scholz Expires September 5, 2009 [Page 8]
Html markup produced by rfcmarkup 1.129c, available from
https://tools.ietf.org/tools/rfcmarkup/