Virtual World Model

From OpenSimulator

(Difference between revisions)
Jump to: navigation, search
Line 1: Line 1:
 
What follows are working definitions for the model of virtual worlds supported by OpenSim. They are intended to clarify terminology, and to sharpen the requirements with respect to security of users' data and world assets. Please use the [[Talk:Virtual_World_Model|Discussion]] tab to comment on these definitions.
 
What follows are working definitions for the model of virtual worlds supported by OpenSim. They are intended to clarify terminology, and to sharpen the requirements with respect to security of users' data and world assets. Please use the [[Talk:Virtual_World_Model|Discussion]] tab to comment on these definitions.
  
'''Simulator Trust Domain''': One or more simulators that completely trust each other, operated by one single authority. Trust means that these simulators can safely exchange messages and share data with each other. Specifically, trusting simulators can engage in exchanges that enable useful features, such as server-side teleports, that are unsafe when done between non-trusting simulators.
+
'''Simulator Trust Domain''': One or more simulators that completely trust each other, operated by one single  
Trust domains can be extended to include simulators in other trust domains, but in these extensions trust is neither commutative nor transitive. [[Talk:Virtual_World_Model|discuss here]]
+
authority. Trust means that these simulators can safely exchange messages and share data with each other.  
 +
Specifically, trusting simulators can engage in exchanges that enable useful features, such as server-side  
 +
teleports, that are unsafe when done between non-trusting simulators. Trust domains can be extended to include  
 +
simulators in other trust domains, but in these extensions trust is neither commutative nor transitive.  
 +
[[Talk:Virtual_World_Model|discuss here]]
  
'''Resource Services''': A set of zero or more services serving resources for simulators. Resources include: assets, user accounts, and assorted services like map, lookup, social networking, forums, etc.  
+
'''Resource Services''': A set of zero or more services serving resources for simulators. Resources include:
 +
assets, user accounts, and assorted services like map, lookup, social networking, forums, etc.  
  
'''Grid''': One or more simulators that share resources via resource services. At the very minimum, the simulators in a grid share assets, but many more services are possible (see above). A Grid includes one or more simulator trust domains. Normally one would expect one grid to be one single trust domain, but that doesn't necessarily need to happen. The Linden Lab Grid, although one single trust domain at the moment, might support several trust domains in the future, where different groups of simulators are controlled by different authorities at the level of the simulator code, but still share the central resources. OSGrid and trust domains...[[Talk:Virtual_World_Model|discuss here]].  Given that a Grid may include more than one simulator trust domain, there can be untrusted connections within the same grid. In deploying security schemes, this needs to be taken into account.
+
'''Grid''': One or more simulators that share resources via resource services. At the very minimum, the  
 +
simulators in a grid share assets, but many more services are possible (see above). A Grid includes one or  
 +
more simulator trust domains. Normally one would expect one grid to be one single trust domain, but that  
 +
doesn't necessarily need to happen. The Linden Lab Grid, although one single trust domain at the moment, might  
 +
support several trust domains in the future, where different groups of simulators are controlled by different  
 +
authorities at the level of the simulator code, but still share the central resources. OSGrid and trust  
 +
domains...[[Talk:Virtual_World_Model|discuss here]].  Given that a Grid may include more than one simulator  
 +
trust domain, there can be untrusted connections within the same grid. In deploying security schemes, this  
 +
needs to be taken into account.
  
'''Hypergrid''': The interconnection of grids. Hypergrid simulator connections are necessarily untrusted, so security schemes need to take that into account. Besides safe simulator connectivity between grids, the Hypergrid addresses the interoperability of resource services -- that is, the ability for: user accounts in one user service being recognized in other grids; assets in one asset service being transferred to other grids; social networking services being bridged, etc. The Hypergrid architecture enables, but does not impose, the emergence of independent Hypergrid-wide resource services such as User Services, Asset Storage, Social Networking, Search, etc. that serve several grids and are not be coupled with any one grid in particular.
+
'''Hypergrid''': The interconnection of grids. Hypergrid simulator connections are necessarily untrusted, so  
 +
security schemes need to take that into account. Besides safe simulator connectivity between grids, the  
 +
Hypergrid addresses the interoperability of resource services -- that is, the ability for: user accounts in  
 +
one user service being recognized in other grids; assets in one asset service being transferred to other  
 +
grids; social networking services being bridged, etc. The Hypergrid architecture enables, but does not impose,  
 +
the emergence of independent Hypergrid-wide resource services such as User Services, Asset Storage, Social  
 +
Networking, Search, etc. that serve several grids and are not be coupled with any one grid in particular.
  
'''Walled-Garden Grid''': A grid that only handles resources directly managed by its own resource services. It does not recognize or allow users and assets from other grids, and it does not allow the export of its own users and assets.
+
'''Walled-Garden Grid''': A grid that only handles resources directly managed by its own resource services. It  
 +
does not recognize or allow users and assets from other grids, and it does not allow the export of its own  
 +
users and assets.
  
  

Revision as of 16:07, 20 April 2009

What follows are working definitions for the model of virtual worlds supported by OpenSim. They are intended to clarify terminology, and to sharpen the requirements with respect to security of users' data and world assets. Please use the Discussion tab to comment on these definitions.

Simulator Trust Domain: One or more simulators that completely trust each other, operated by one single 
authority. Trust means that these simulators can safely exchange messages and share data with each other. 
Specifically, trusting simulators can engage in exchanges that enable useful features, such as server-side 
teleports, that are unsafe when done between non-trusting simulators. Trust domains can be extended to include 
simulators in other trust domains, but in these extensions trust is neither commutative nor transitive. 
discuss here
Resource Services: A set of zero or more services serving resources for simulators. Resources include:
assets, user accounts, and assorted services like map, lookup, social networking, forums, etc. 
Grid: One or more simulators that share resources via resource services. At the very minimum, the 
simulators in a grid share assets, but many more services are possible (see above). A Grid includes one or 
more simulator trust domains. Normally one would expect one grid to be one single trust domain, but that 
doesn't necessarily need to happen. The Linden Lab Grid, although one single trust domain at the moment, might 
support several trust domains in the future, where different groups of simulators are controlled by different 
authorities at the level of the simulator code, but still share the central resources. OSGrid and trust 
domains...discuss here.  Given that a Grid may include more than one simulator 
trust domain, there can be untrusted connections within the same grid. In deploying security schemes, this 
needs to be taken into account.
Hypergrid: The interconnection of grids. Hypergrid simulator connections are necessarily untrusted, so 
security schemes need to take that into account. Besides safe simulator connectivity between grids, the 
Hypergrid addresses the interoperability of resource services -- that is, the ability for: user accounts in 
one user service being recognized in other grids; assets in one asset service being transferred to other 
grids; social networking services being bridged, etc. The Hypergrid architecture enables, but does not impose, 
the emergence of independent Hypergrid-wide resource services such as User Services, Asset Storage, Social 
Networking, Search, etc. that serve several grids and are not be coupled with any one grid in particular.
Walled-Garden Grid: A grid that only handles resources directly managed by its own resource services. It 
does not recognize or allow users and assets from other grids, and it does not allow the export of its own 
users and assets.


Additional notes:

  • Tentatively, I'm unifying the concept of Grid with the concept of Virtual World.
  • A "Standalone", which should be read as "Standalone Grid" (term credit to Michael Cortez), is a grid-in-a-box. It's one process that single-handily performs simulation and resource management. Just like any other grid, a Standalone grid may be hypergrided or may operate as a walled garden.
  • Simulator trust domains have ultimate freedom to implement any feature they want among themselves, including transferring user agents (user permitting), sharing private data, etc.
  • Grids may exist without any services but asset services. [Note: could there be a grid without assets?!]
  • Hypergrided Grids may treat all users equally or may treat their own users in special ways.
  • Grids may provide visitors with additional resources that are only available while the users visit that grid, and become unavailable once the visitor goes elsewhere (aka grid-specific inventory).

More notes (Melanie's email, edited by Diva):

Users should be in control of their own inventory and its associated assets, independent of a single grid. This means:

  • users can select where their data is stored. This may be an ISP, a web hoster, a grid or their own PC (bandwidth permitting). No simulator has authority over that storage.
  • Regions hold COPIES of the assets needed to render whatever is currently in world. Normally, this will be "by value", e.g. the sim will have a full and valid copy of the data and be able to supply everything needed to render its content independent of any outside servers.
  • Grids are one or more trust domains, they are groups of regions sharing asset and user services. The access the same servers for their data and anything within one region can be moved to any other region without the need to copy assets. Regions within a trust domain are able to destroy storage needed by other regions to render data, but cannot access user inventories unless authorized, and with very limited scope. Typically, but not mandatory, all sims in one gridwill be owned and operated by a single individual/organization.
  • User services authenticate user for access to a trust domain. They may require username/password, X.509 certificates, oAuth, openID or any other form of authentication, or none. They may decree that, if you don't authenticate, your access may be limited to observation only, or in any other way they, as the trust domain controller, see fit.
  • Sim asset services are the storage at the heart of a grid, sims in a grid share these asset services. That is distinct from user asset services, which are out of scope for regions.
  • Optionally, user asset services may pass an object to a region "by reference". This assumes a basic level of trust with the region, which is advised to not keep a copy, but request the current data from the user asset service each time it is needed. This required continuous authorization for that item, which will be limited to specific sims, Therefore, such items can't leave the sim, they cannot be given or sold, but only be taken by the owner. This is useful for allowing the update of scripts in-place, e.g. for applications like sloodle, which may want to update all inworld terminals all at once. It it a marked departure from the Linden way of doing things.
Personal tools
General
About This Wiki