CableBeachProposal - Revision history

MakoBot: Robot: Cosmetic changes

2012-03-04T04:44:24Z

Robot: Cosmetic changes

MakoBot: Robot: Cosmetic changes

2012-03-04T02:03:38Z

Robot: Cosmetic changes

MakoBot: Removed 'Template:' prefix from template includings and/or changed external-link into internal-link

2011-06-10T13:56:07Z

Removed 'Template:' prefix from template includings and/or changed external-link into internal-link

Ideia Boa at 10:53, 21 May 2009

2009-05-21T10:53:46Z

Jhurliman: Major update, cut the X.509 information out (will be a separate proposal)

2009-05-14T06:17:14Z

Major update, cut the X.509 information out (will be a separate proposal)

Jhurliman at 17:46, 30 April 2009

2009-04-30T17:46:09Z

Jhurliman: Brought the documentation up to speed with the latest diagrams

2009-04-30T17:26:25Z

Brought the documentation up to speed with the latest diagrams

Jhurliman at 18:54, 17 April 2009

2009-04-17T18:54:49Z

Jhurliman at 09:00, 17 April 2009

2009-04-17T09:00:16Z

Jhurliman at 23:34, 16 April 2009

2009-04-16T23:34:01Z

@@ Line 26: / Line 26: @@
 The following diagram shows an overview of the Cable Beach architecture divided up into trust domains. Everything operating inside of a trust domain has some implicit level of trust for all of the other members of the trust domain, although that level of trust will vary depending on the purpose of the trust domain and the policy put in place for that domain.
-[[Image:Cablebeach-trustoverview.png]]
+[[File:Cablebeach-trustoverview.png]]
 === World Domain ===

@@ Line 4: / Line 4: @@
 {{proposal}}
-=Cable Beach Proposal=
+= Cable Beach Proposal =
-==Motivation==
+== Motivation ==
 Many virtual worlds are being developed independently with a wide variety of different architectures and protocols. The current generation of virtual worlds are implemented as proprietary stacks of services, where each world is not only simulating virtual space but also providing identity services, content hosting, digital rights management, instant messaging, virtual economies, social networking elements such as groups, and many other services. We believe there are shortcomings with this approach. Specifically:
@@ Line 14: / Line 14: @@
 # Due to the walled garden nature of current worlds, third party services such as search and digital content creation tools have been almost entirely locked out of virtual worlds.
-==Vision==
+== Vision ==
 We envision virtual worlds modeled after the current World Wide Web, with millions of independent administrative domains. Content will be spread across millions of small, independent domains as well as aggregated on large domains supporting millions of users. A rich community of value added services and the free and open exchange of content will weave the network together, much as the Web 2.0 movement is tying the web together today. Every organization can choose what services they will run themselves, what services will be provided by third parties, and which third parties will provide services. Additionally, the content rights decisions are placed in the hands of the content hosts. With the proper authentication users are free to move assets to wherever they roam.
@@ Line 20: / Line 20: @@
 Data services will become as important as data hosting itself. Just as search engines and content portals have changed how we use the web, services that can plug into a common interface in asset hosting will change how we use virtual worlds. Auditing services can provide an approach to rights management and traffic analytics. Existing caching techniques and services that have been built for today's web content can be leveraged for delivery of rich virtual world content.
-==Overview==
+== Overview ==
 Cable Beach is a service based architecture. Every category of functionality in a virtual world is designated as a service. The services can be organized in any number of different ways and spread across different processes, different servers, or different trust domains. In fact, several services can collectively provide a rich experience with complex interactions while still operating completely independently of one another.
@@ Line 28: / Line 28: @@
 [[Image:Cablebeach-trustoverview.png]]
-===World Domain===
+=== World Domain ===
 All of the services responsible for simulating a virtual world fall under the umbrella of the world domain. The ultimate authority of this domain is the world service, which acts as both the gatekeeper for incoming clients and oversees all of the simulation nodes in the world. All clients wishing to connect to this world should connect through the world server, which will enforce global policy such as access lists. The trust requirements of the world domain are not defined by the architecture, but rather the policies of each world. In other words, the level of trust services in the world domain have for each other is entirely dependent on the world policies. Some worlds might choose a very tight controlled policy to facilitate the safety of online transactions, while other worlds might choose a very open membership policy. The mechanisms and policies used to establish trust between services inside the world domain is out of the scope of this architecture.
-===Identity===
+=== Identity ===
 Identity is not tied to a particular world. Instead, identity is treated as an independent service, allowing any client to attempt to login to any world. Which logins will actually be allowed are defined by policy of the world service. The closed world of fantasygameworld.com might provide its own identity server at users.fantasygameworld.com and only accept logins from identities at that domain. Another world might default to allowing logins from anywhere, but blacklist specific domains such as virtualspammers.com. The external identity service abstracts the security requirements for worlds away from the architectural design and allows a wide variety of policy decisions for clients to be enforced.
@@ Line 38: / Line 38: @@
 In the Cable Beach architecture, identity is more than just a URL identifier. A list of attributes are attached to each identity that provide the metadata necessary to simulate the presence of an identity in a virtual world. Attribute types are defined by URLs, similar to OpenID Attribute Exchange. Each attribute stores LLSD; the format of the LLSD is specific to the attribute. As an example, an identity might have first name and last name attributes of the string type. Some attributes are references to the URL of a service, such as inventory or messaging. Some attributes will naturally be closely tied to the identity itself, such as the avatar name. Other attributes may be specific to a particular world, such as a high score or a list of completed quests. World services may request any list of attributes from an identity service, as well as supplementing the list with additional avatar attributes stored in the world service.
-===Services===
+=== Services ===
 In addition to data attributes such as avatar name, some attributes store service URLs. When a client contacts a world service to log in, the world service compiles a list of required services and service capabilities that will be used during the client session in this world. While the communication between the world service and trusted services outside of the scope of this architecture, communication between the world service and untrusted services is well defined to ensure interoperability. The OAuth protocol is used to allow third party services to independently confirm the client identity and then confirm the list of required capabilities with the client. Once authentication and authorization have been confirmed, the world service uses the OAuth authorization token to retrieve temporary capability URLs for each requested capability.
@@ Line 44: / Line 44: @@
 Any number of services can be attached to an identity. Some services such as inventory might be very common across many worlds, while world-specific services such as a trophy server might apply to a very small subset of worlds or even a single world. For example, fantasygameworld.com may associate a trophy service with all incoming clients to track progress and achievements in that world. Inventory may be restricted to items only found in fantasygameworld.com by ignoring external inventory services and associating an internal inventory service with each identity. Future revisions may support multiple services for the same service type, such as accessing an internal and external inventory service simultaneously.
-==Prototype==
+== Prototype ==
 The prototype implementation of Cable Beach is designed in a modular way to support centralized and decentralized concepts simultaneously. For example, the WorldServer can also act as an identity service to provide a login path for XML-RPC requests (using username and password combination) from the current Second Life client. Client authentication can be skipped in the InventoryServer, making the assumption that the WorldServer and InventoryServer exist in the same trust domain and only the WorldServer has access to the InventoryServer OAuth endpoint. This gives existing virtual worlds the immediate benefit of a more flexible service architecture while remaining backward compatible with the current login flow. Client modifications are being developed to allow the existing Second Life viewer to participate in completely decentralized grids.

@@ Line 1: / Line 1: @@
 __NOTOC__
-{{Template:Quicklinks}}
+{{Quicklinks}}
 {{proposal}}

← Older revision		Revision as of 10:53, 21 May 2009
Line 1:		Line 1:
		+	__NOTOC__
		+	{{Template:Quicklinks}}
		+
	{{proposal}}		{{proposal}}

@@ Line 19: / Line 19: @@
 ==Overview==
-One sensible way to look at the Cable Beach architecture is by breaking it up into trust domains. Everything operating inside of a trust domain has some implicit level of trust for all of the other members of the trust domain, although that level of trust will vary depending on the purpose of the trust domain and the policy put in place for that domain.
+Cable Beach is a service based architecture. Every category of functionality in a virtual world is designated as a service. The services can be organized in any number of different ways and spread across different processes, different servers, or different trust domains. In fact, several services can collectively provide a rich experience with complex interactions while still operating completely independently of one another.
 [[Image:Cablebeach-trustoverview.png]]
@@ Line 25: / Line 27: @@
 ===World Domain===
-All of the services responsible for simulating a virtual world fall under the umbrella of the world domain. The ultimate authority of this domain is the world server, which acts as both the gatekeeper for incoming clients and oversees all of the simulation nodes in the world. The actual definition of trust is not defined by the architecture, but rather the policies of each world. In other words, the level of trust each simulator in the world has for other simulators in the world is entirely dependent on the world policies. Some worlds might choose a very tight controlled policy to facilitate the safety of online transactions, while other worlds might choose a very open membership policy. To create the notion of a trust domain across many different servers (potentially hosted by many different administrators), the world server acts as an X.509 root certificate authority. Certificates are issued to each simulator to grant world membership. These certificates can be later revoked; perhaps a member of the world has not paid their monthly dues, or has broken world policy. All clients wishing to connect to this world should connect through the world server, which will enforce global policy such as access lists.
+All of the services responsible for simulating a virtual world fall under the umbrella of the world domain. The ultimate authority of this domain is the world service, which acts as both the gatekeeper for incoming clients and oversees all of the simulation nodes in the world. All clients wishing to connect to this world should connect through the world server, which will enforce global policy such as access lists. The trust requirements of the world domain are not defined by the architecture, but rather the policies of each world. In other words, the level of trust services in the world domain have for each other is entirely dependent on the world policies. Some worlds might choose a very tight controlled policy to facilitate the safety of online transactions, while other worlds might choose a very open membership policy. The mechanisms and policies used to establish trust between services inside the world domain is out of the scope of this architecture.
 ===Identity===
-Identity is not tied to a particular world. Instead, federated identity allows any client to attempt to login to any world. Which logins will actually be allowed are defined by policy on the world server. The closed world of fantasygameworld.com might provide its own identity server at users.fantasygameworld.com and only accept logins from identities at that domain. Another world might default to allowing logins from anywhere, but blacklist specific domains such as virtualspammers.com. This abstracts the identity and security requirements for worlds away from the architectural design and allows a wide variety of policy decisions for clients to be enforced.
+Identity is not tied to a particular world. Instead, identity is treated as an independent service, allowing any client to attempt to login to any world. Which logins will actually be allowed are defined by policy of the world service. The closed world of fantasygameworld.com might provide its own identity server at users.fantasygameworld.com and only accept logins from identities at that domain. Another world might default to allowing logins from anywhere, but blacklist specific domains such as virtualspammers.com. The external identity service abstracts the security requirements for worlds away from the architectural design and allows a wide variety of policy decisions for clients to be enforced.
-−
-In the Cable Beach architecture, identity is more than just a URL identifier. A list of attributes are attached to each identity that provide the metadata necessary to simulate the presence of an identity in a virtual world. Attribute types are defined by URLs, just as they are defined in OpenID Attribute Exchange. Each attribute stores LLSD; the format of the LLSD is specific to the attribute. As an example, an identity might have first name and last name attributes of the string type. Some attributes are references to the URL of a service, such as inventory or messaging.
-−
-When a client contacts a world server to log in, the world server contacts the identity server for the given identity. OpenID maps nicely into this process to provide proof that the client owns the supplied identity. Once authentication has completed, the identity server must contact each service the requested identity links to and request one or more capabilities on behalf of the identity. The capability is a temporary, difficult to guess URL that can be given to clients or other services to provide some level of access to a service. The confirmation of identity ownership, list of attributes for the identity, and list of services and capabilities are all returned to the world server where the login requested initiated from.
-−
-===Other Services===
-−
-Any number of services can be attached to an identity. Some services such as inventory might be very common across many worlds, while world-specific services such as a trophy server might apply to a very small subset of worlds or even a single world. While the first point of association with services is from identities on an identity service, world servers may also associate services with identities. For example, fantasygameworld.com may associate a trophy service with all incoming clients to track progress and achievements in that world. Inventory may be restricted to items only found in fantasygameworld.com by ignoring external inventory services and associating an internal inventory service with each identity. Future revisions may support multiple services for the same service type, such as accessing an internal and external inventory service simultaneously.
-−
-==Roadmap==
-−
-A roadmap has been designed to provide a migration from the current OpenSim implementation of the Second Life® protocol to a decentralized service protocol. The first step will provide some of the services in a disaggregated virtual world and will improve the security of existing models such as OSGrid's decentralized hosting with centralized trust. The second step will remove any assumptions about tightly coupled services and present a true decentralized virtual world service platform. Step three will remove any leftover baggage by making service authentication and authorization client-centric, and potentially enable new use cases such as multiple inventory servers or content migration.
-−
-===Step 1: Login With Existing LL Client===
-----
-−
-[[Image:CableBeach_LL_Client_Login_3.png]]
-−
-# This step is the familiar XML-RPC login initiated from the Linden Lab client, passing a first name, last name, and md5 hash of the password. What is new here is that the login is sent directly to the world server, since identity servers are no longer tightly coupled to worlds.
-# The login is forwarded to a known identity server along with a list of requested services and the names of requested capabilities for each service. Note that because the client is providing a world server with sensitive information (md5 hash of the agent password) and it does not provide a URL for the identity server, this form of login requires the grid server and a known identity server to exist in the same trust domain.
-# The identity server holds profile information for each identity, including a list of URLs for various services. The identity server will try to match up requested service URLs with service URLs it knows about for the requested identity. For each match, a request is sent to the service URL to request the capabilities that the world server asked for. In the example above, only an inventory server is contacted. This request is trusted as coming from the given identity because it originates from the identity server for that identity.
-# Each service checks permissions for the requested capabilities against the given identity and returns temporary capability URLs back to the identity server.
-# The login request successfully returns back to the world server with information about the agent, the list of known services, and capabilities that were granted for each service.
-# The world server determines which simulator the client will start in. This might be the closest available location to a requested destination, the agent's home location in this world, or the default starting location for the world.
-# A request for the inventory skeleton is sent from the world server to the inventory server. This is required because the XML-RPC login response for the client expects a list of all inventory folders for the avatar. The request is sent to the temporary capability for get_inventory_skeleton, so no additional security checks need to be done when the request arrives at the inventory server.
-# A list of folders for the given identity is sent back to the world server.
-# The world server contacts the starting simulator to prepare a login. (Contact information for the simulator is received when the simulator first comes online and registers with the world server.) Information about the agent, the list of services for the agent, and the capabilities for each service are given to the simulator. In this model, the simulator will need all of the capabilities since it will act on behalf of the client. In future models, the simulator might only receive a subset of capabilities that it can be trusted with while the client uses the rest directly. The world server uses its certificate as a client certificate so the simulator can authenticate the request. The simulator checks the presented client certificate and confirms it as being signed by the world server.
-# Information about the simulator (IP address, port, UDP circuit code) is sent back to the grid server along with a success response.
-# Agent information, inventory information, and the simulator information are all returned to the client along with the success response.
-−
-===Step 2: OpenID Login With web_login_key===
-----
-−
-[[Image:CableBeach_OpenID_Client_Login_3.png]]
-−
-This is the same login flow as the first diagram, but the client passes an OpenID identity URL to the grid server instead of login credentials. An OpenID login process is initiated with the identity server where the client supplies login credentials directly to the identity server. This removes the restriction that the grid server and identity server must be in the same trust domain. Once the OpenID identity has been confirmed, an authenticate_openid message (similar to the authenticate_ll message) is sent from the world server to the identity server and the login continues as in the first diagram.
-===Step 3: Client-Centric World===
+In the Cable Beach architecture, identity is more than just a URL identifier. A list of attributes are attached to each identity that provide the metadata necessary to simulate the presence of an identity in a virtual world. Attribute types are defined by URLs, similar to OpenID Attribute Exchange. Each attribute stores LLSD; the format of the LLSD is specific to the attribute. As an example, an identity might have first name and last name attributes of the string type. Some attributes are references to the URL of a service, such as inventory or messaging. Some attributes will naturally be closely tied to the identity itself, such as the avatar name. Other attributes may be specific to a particular world, such as a high score or a list of completed quests. World services may request any list of attributes from an identity service, as well as supplementing the list with additional avatar attributes stored in the world service.
-----
-[TODO]
+===Services===
-==Use Cases==
+In addition to data attributes such as avatar name, some attributes store service URLs. When a client contacts a world service to log in, the world service compiles a list of required services and service capabilities that will be used during the client session in this world. While the communication between the world service and trusted services outside of the scope of this architecture, communication between the world service and untrusted services is well defined to ensure interoperability. The OAuth protocol is used to allow third party services to independently confirm the client identity and then confirm the list of required capabilities with the client. Once authentication and authorization have been confirmed, the world service uses the OAuth authorization token to retrieve temporary capability URLs for each requested capability.
-Several common virtual world operations are presented below. Teleporting between two regions in the same trust domain or between domains that have shared trust, teleporting between two untrusted domains, content publishing from digital content creation tools, and content migration between untrusted domains. [TODO]
+Any number of services can be attached to an identity. Some services such as inventory might be very common across many worlds, while world-specific services such as a trophy server might apply to a very small subset of worlds or even a single world. For example, fantasygameworld.com may associate a trophy service with all incoming clients to track progress and achievements in that world. Inventory may be restricted to items only found in fantasygameworld.com by ignoring external inventory services and associating an internal inventory service with each identity. Future revisions may support multiple services for the same service type, such as accessing an internal and external inventory service simultaneously.
-===Trusted Teleport===
+==Prototype==
-[[Image:CableBeach_Hypergrid_Trusted_Teleport_1.png]]
+The prototype implementation of Cable Beach is designed in a modular way to support centralized and decentralized concepts simultaneously. For example, the WorldServer can also act as an identity service to provide a login path for XML-RPC requests (using username and password combination) from the current Second Life client. Client authentication can be skipped in the InventoryServer, making the assumption that the WorldServer and InventoryServer exist in the same trust domain and only the WorldServer has access to the InventoryServer OAuth endpoint. This gives existing virtual worlds the immediate benefit of a more flexible service architecture while remaining backward compatible with the current login flow. Client modifications are being developed to allow the existing Second Life viewer to participate in completely decentralized grids.

@@ Line 7: / Line 7: @@
 Many virtual worlds are being developed independently with a wide variety of different architectures and protocols. The current generation of virtual worlds are implemented as proprietary stacks of services, where each world is not only simulating virtual space but also providing identity services, content hosting, digital rights management, instant messaging, virtual economies, social networking elements such as groups, and many other services. We believe there are shortcomings with this approach. Specifically:
-# The barrier to entry for creating and running a virtual world is too high. Even with popular platforms such as OpenSim, grid administrators are taking on a monumental task of overseeing many or all of the above services when only a simple world simulation is needed.
+# The barrier to entry for creating and running a virtual world is too high. Even with popular platforms such as OpenSim, virtual world administrators are taking on a monumental task of overseeing many or all of the above services when only a simple world simulation is needed.
 # The all-or-nothing approach of the current protocols prevents the development of a robust virtual world ecosystem, where many specialized services are provided. Today's large stakeholders in content hosting, content delivery acceleration, identity services, and social networking have no means of entry to the virtual worlds space.
 # Due to the walled garden nature of current worlds, third party services such as search and digital content creation tools have been almost entirely locked out of virtual worlds.
@@ Line 41: / Line 41: @@
 ==Roadmap==
-A roadmap has been designed to provide a migration from the current OpenSim implementation of the Second Life® protocol to a decentralized service protocol. The first step will provide some of the services in a disaggregated grid and will improve the security of existing models such as OSGrid's decentralized hosting with centralized trust. The second step will remove any assumptions about tightly coupled services and present a true decentralized virtual world service platform. Step three will remove any leftover baggage by making service authentication and authorization client-centric, and potentially enable new use cases such as multiple inventory servers or content migration.
+A roadmap has been designed to provide a migration from the current OpenSim implementation of the Second Life® protocol to a decentralized service protocol. The first step will provide some of the services in a disaggregated virtual world and will improve the security of existing models such as OSGrid's decentralized hosting with centralized trust. The second step will remove any assumptions about tightly coupled services and present a true decentralized virtual world service platform. Step three will remove any leftover baggage by making service authentication and authorization client-centric, and potentially enable new use cases such as multiple inventory servers or content migration.
 ===Step 1: Login With Existing LL Client===
 ----
-[[Image:CableBeach_LL_Client_Login_2.png]]
+[[Image:CableBeach_LL_Client_Login_3.png]]
-# This step is the familiar XML-RPC login initiated from the Linden Lab client, passing a first name, last name, and md5 hash of the password. What is new here is that the login is sent directly to the grid server for a grid, since identities are no longer tightly coupled to grids.
+# This step is the familiar XML-RPC login initiated from the Linden Lab client, passing a first name, last name, and md5 hash of the password. What is new here is that the login is sent directly to the world server, since identity servers are no longer tightly coupled to worlds.
-# The login is forwarded to a known identity server. Note that because the client is providing a grid server with sensitive information (md5 hash of the agent password), and it does not provide a URL for the identity server, this form of login requires the grid server and a known identity server to exist in the same trust domain.
+# The login is forwarded to a known identity server along with a list of requested services and the names of requested capabilities for each service. Note that because the client is providing a world server with sensitive information (md5 hash of the agent password) and it does not provide a URL for the identity server, this form of login requires the grid server and a known identity server to exist in the same trust domain.
-# The identity server holds profile information for each identity, which includes a list of URLs for various services. For each service, a temporary access token is requested.
+# The identity server holds profile information for each identity, including a list of URLs for various services. The identity server will try to match up requested service URLs with service URLs it knows about for the requested identity. For each match, a request is sent to the service URL to request the capabilities that the world server asked for. In the example above, only an inventory server is contacted. This request is trusted as coming from the given identity because it originates from the identity server for that identity.
-# Each service grants a temporary access token back to the identity server.
+# Each service checks permissions for the requested capabilities against the given identity and returns temporary capability URLs back to the identity server.
-# The login request successfully returns back to the grid server with information about the agent, the list of services, and access tokens for each service.
+# The login request successfully returns back to the world server with information about the agent, the list of known services, and capabilities that were granted for each service.
-# The grid server determines which simulator the client will start in. This may be the closest available location to a requested destination, the agent's home simulator in this grid, or the default starting location for the grid.
+# The world server determines which simulator the client will start in. This might be the closest available location to a requested destination, the agent's home location in this world, or the default starting location for the world.
-# The grid server contacts the starting simulator to prepare the login. Information about the agent, the list of services for the agent, and the access tokens for each service are given to the simulator. The grid server uses its certificate as a client certificate so the simulator can authenticate the request. The simulator checks the presented client certificate and confirms it as being signed by the grid server.
+# A request for the inventory skeleton is sent from the world server to the inventory server. This is required because the XML-RPC login response for the client expects a list of all inventory folders for the avatar. The request is sent to the temporary capability for get_inventory_skeleton, so no additional security checks need to be done when the request arrives at the inventory server.
-# The simulator contacts any services that need to be contacted before login completes. In this case, inventory information is requested from the inventory server.
+# A list of folders for the given identity is sent back to the world server.
-# The inventory server checks the given access token and confirms that it is valid and not expired.
+# The world server contacts the starting simulator to prepare a login. (Contact information for the simulator is received when the simulator first comes online and registers with the world server.) Information about the agent, the list of services for the agent, and the capabilities for each service are given to the simulator. In this model, the simulator will need all of the capabilities since it will act on behalf of the client. In future models, the simulator might only receive a subset of capabilities that it can be trusted with while the client uses the rest directly. The world server uses its certificate as a client certificate so the simulator can authenticate the request. The simulator checks the presented client certificate and confirms it as being signed by the world server.
-# The inventory server returns information about the agent's inventory.
+# Information about the simulator (IP address, port, UDP circuit code) is sent back to the grid server along with a success response.
-# Information about the simulator (IP address, port, UDP circuit code) and the inventory information is sent back to the grid server along with a success response.
 # Agent information, inventory information, and the simulator information are all returned to the client along with the success response.
@@ Line 70: / Line 69: @@
 ===Step 3: Client-Centric World===
 ----
 [TODO]