MMOX Architecture Discussion
COM.lounge
Hanbrucher Str. 33
52064
Aachen
NRW
Germany
cs@comlounge.net
Virtual Worlds
Interoperability
MMOX
Social Networks
Requirements
MMOX pre-BOF
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
identifying problem spaces which are more general than the virtual
worlds field and also touch on problems found in today's social
networks.
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.
From the discussion on the MMOX mailing list it became clear that
there are several fields people want to work on
there is a big variety of virtual worlds out there which for now
at least will not be fully compatible
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.
As it was pointed out in the list we at least have the following
fields which are identified:
Federated/portable Identity
Distributed authorization
Service Discovery
data formats (e.g. LLSD)
world simulation protocols
presence protocols/services
Licensing/permissions/DRM
All these problems are not really overlapping each other but
might be seen next to each other or in different layers.
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.
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.
There are some problem fields of the list in which are not only relevant to virtual
worlds but also for e.g. social networks. These are especially
Federated/portable identity
Distributed Authorization
Service Discovery
Presence Protocols
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.
As describe in 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:
Portable Idenity
Distributed Authorization
Service Discovery
After that one can specify those individual services and data formats
which MAY be used while they MUST support the above specifications.
There are three problem fields which make sense to discuss
first.
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".
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. 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.
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 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 XRDShas 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
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.
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.
The client does service discovery on the virtual world URL to
check for available 3D protocols
The client receives a list of supported 3D protocols of that
virtual world and selects the best one
The client established a connection to the virtual world.
The virtual world performs service discovery on the user's
identity URL and finds an authentication service suitable for
it.
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.
The OpenID provider sends a success message back to the virtual
world which now knows that the user "owns" the URL.
The virtual world now checks for further services such as
profile information or friends list.
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
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.
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
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.
&RFC2119;
OAuth Core 1.0
Link-based Resource Descriptor Discovery
Extensible Resource Identifier (XRI) Resolution V2.0