[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

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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   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.


   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

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   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

   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

   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

   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

   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

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

              Hammer-Lahav, E., "Link-based Resource Descriptor

   [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
   Hanbrucher Str. 33
   Aachen, NRW  52064

   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/