Difference between revisions of "User:Dale Innis/Asset handling in OGP"

From Second Life Wiki
Jump to navigation Jump to search
m (→‎See also: typo in category name sigh)
 
Line 102: Line 102:


[[Category:AW Groupies]]
[[Category:AW Groupies]]
[[Category:AW Groupies User Pages]]
[[Category:Grid Interoperability]]
[[Category:Grid Interoperability]]

Latest revision as of 08:30, 1 October 2008

Gathering together the numerous discussion threads and Wiki pages on the subject of OGP's handling of assets, with the intent of identifying the requirements for the data that needs to flow through OGP to enable all the stakeholders to be satisfied.

Note that this document is currently utterly unofficial; it is intended to evolve to represent a consensus, or to be replaced by a different page containing a consensus, but at the moment it isn't that.

Stakeholders

The stakeholders are those outlined in the OGP Trust Model document. When talking about assets, the most obvious stakeholders are content creators and end users; but if there are specifically asset-related interests that the other stakeholders have, we should write those down also.

Use cases

The most obviously relevant use cases on the OGP Trust Model Use Cases page are those involving assets and inventory.

Identity and authentication

It is often important to be able to determine who another party is claiming to be, and to verify that they really are who they claim to be. Until it turns out otherwise, we will assume that the identity and authentication mechanisms that are in the OGP in general (used for login and AV teleport, for instance) will also be used in asset-related parts of the protocol.

Authorization

Once another entity has been authenticated, so we know their true identity, we then need to determine what that entity is allowed to do. As suggested in the Trust Model, we can either do this online (i.e. have some way of negotiating with the entity and/or a third party in order to decide what to allow it do to), or offline (i.e. just have some local configuration data, which is obtained and maintained outside of the protocol, that we can consult, that gives us the list of things that an entity with a given identity, or in possession of a given capability, is and isn't allowed to do).

Although we may wish to leave extensibility points in the protocol that would allow minimal-pain extensions to online methods, for simplicity we will assume offline authorization for the first version of the protocol: when an entity A receives a request to do X from an entity B, perhaps accompanied by one or more capabilities C, the question of how A decides whether or not B-which-has-C is allowed to do X is entirely up to A, and out of scope for the protocol.

What is in scope for the protocol is deciding which information X needs to contain (and perhaps what sorts of capabilities B might be able to pass to A) in order for A to be able to make the decision. That is, we don't care how A makes the decision, but we do need to ensure that A gets all the information that A might be reasonably expected to require in order to make it.

Motivating scenarios

Consider a set of Agent Domains and a set of Region Domains, all vaguely Second-Life-like and/or OpenSim-like, where the agent domains have a bunch of agents that have inventories, and the region domains have a bunch of regions that contain objects. When an agent wants to teleport to a region belonging to a different RD, do some things there, return to the "native" RD, and do somethings there, various stakeholders will have asset-related concerns. There are other scenarios in the Trust Model Use Cases document, but we'll start with simple TP-with-inventory.

Requirements

To start with, we'll assume that each of the domains would like to enforce, as completely as is feasible, a system in which:

  • No asset can travel outside of the domain of its creation unless the asset creator (or equivalent rights-holder, and we probably need a page just on that subject somewhere at some point) has given permission for that traveling, either implicitly or explicitly (need to spell out various cases of implicit and explicit permission, although it will probably turn out not to be relevant to the technical details of the protocol), and
  • No asset A can travel to a region domain R unless R supports at least the permissions that are set on A, where "supports at least" means that if the permissions set on A in its native domain prevent a certain action being taken on it in that domain, then the permissions that will be set on A in the destination domain once it arrives will also prevent that action being taken on it in the destination domain. (Do we need to consider more complex multi-hop cases, or does the integrity of the links imply the integrity of the chain?)
  • When an end user who has an asset A in her inventory travels to another domain, and asset A's creator has given permission for that traveling, and the destination domain does support at least the permissions on A, then the end user's experience of owning and using A in the destination domain should be as close to her experience of owning and using it in the "native" domain as the functional compatibilities between the two domains permit.
  • Similarly, when an end user who has an asset A in her inventory travels to another domain, and asset A's creator has given permission for that traveling, and the destination domain does support at least the permissions on A, then the asset should be protected at least as restrictively as it would have been on A (that is, the destination domain should not only support the permissions in general, it should also enforce them on this particular asset).

In-protocol domain information

Based on the above, it seems that the key protocol information required for proper asset protection in at least the motivating scenarios is:

  • Identification and authentication of the destination region (handled as described above),
  • Determination of whether or not the asset is allowed to travel to the destination region (information which can be kept in the representation of the asset itself, since a domain only needs to make this determination if it has a copy of the object in hand),
  • Determination of the permissions on the object (similarly part of the asset metadata),
  • Determination of the permissions supported by the destination region (which can be handled off line and out-of-protocol, although it may be good to allow an easy path to inline negotiation in later versions of the spec),
  • Determination of the compatibility between the asset's permissions and the permissions supported by the target grid (which can again be done entirely within the sending grid, without further inter-grid discussion),
  • If the determination is positive, sending the asset metadata and data to the destination domain.

So in the simplest case, it turns out that OGP in fact needs to transmit very little information relevant to the trust and authorization aspects of asset handling! The domains involved can do most of the calculations themselves. A simple exchange might look like:

  1. User, using viewer, TPs to a "foreign" region domain RDx, and tries to rez an item I from inventory there (or tries to wear a skin or piece of non-prim clothing, or whatever).
  2. Viewer passes the action to the user's Agent Domain (is that architecturally correct?); the AD checks the asset metadata to make sure that I is allowed to travel to RDx, and to obtain the current permissions P that apply to I.
  3. If I is not allowed to travel to RDx, an error goes back to the viewer, which reports failure to the user ("That asset may not be rezzed in this region", say).
  4. Otherwise, AD looks up in its own tables to see what permissions RDx supports, and compares them to the permissions P. If they are incompatible, again an error goes back to the user.
  5. Otherwise, AD transmits the asset data and metadata for I (see below) to RDx, updating its own internal database of the agent's inventory appropriately.

In this simple exchange, the only asset-related OGP message is the one that actually transfers the asset if all of the tests succeed! All of the authorization and trust decisions are made in the sending AD, without requiring any OGP exchanges with the destination domain.

If we go one step more along the road of on-line information here, the exchange might look something like this:

  1. User, using viewer, TPs to a "foreign" region domain RDx, and tries to rez an item I from inventory there (or tries to wear a skin or piece of non-prim clothing, or whatever).
  2. Viewer passes the action to the user's Agent Domain (is that architecturally correct?); the AD checks the asset metadata to make sure that I is allowed to travel to RDx, and to obtain the current permissions P that apply to I.
  3. If I is not allowed to travel to RDx, an error goes back to the viewer, which reports failure to the user ("That asset may not be rezzed in this region", say).
  4. Otherwise, AD sends a message to RDx asking what permissions it supports, and compares the reply to the permissions P. If they are incompatible, again an error goes back to the user.
  5. Otherwise, AD transmits the asset data and metadata for I (see below) to RDx, updating its own internal database of the agent's inventory appropriately.

In this exchange, the AD asks the RD what permissions it supports, and uses that result, rather than requiring an existing table, maintained off-protocol, with that information. (In this model presumably if some RD can't be trusted to tell the truth about what permissions it supports, the AD wouldn't be talking to it at all.)

Asset metadata

Although it might be tempting, asset metadata (name, properties, the fact that a given object is in a given user's inventory) probably has to be treated as part of the asset, and protected just as carefully. While content creators who are worried only about copyright violations probably don't care about metadata (you can't steal a skin if all that you have is its metadata), content creators (or other rights owners) who are worried about confidentiality (e.g. a corporate domain that doesn't want company confidential information to go to other domains) will want to restrict metadata as well, since just knowing the names of the confidential objects in the CEO's inventory could be an advantage to an industrial spy.

Is there in fact any time that asset metadata would flow from the AD to an RD, except in the company of the agent data itself? Only the metadata is required for inventory, but is inventory always just a conversation between the AD and the client? If the only time that metadata flows to the RD is at rez time, when the agent data itself also flows, then there may be no need to think about metadata separately at all.

Asset data

Once a domain has determined that it is in fact okay for a particular asset to travel to a particular destination RD, OGP must provide a way for the asset itself (that is, all the data required to create the asset as faithfully as feasible on the destination domain) to travel.

Many different virtual words are going to have different ways of representing and storing objects and assets. Some will be cross-compatible, many others will not. In the process of determining whether or not two different domains have a compatible asset format in common for a given asset, it may make sense to allow on-line negotiation, rather than requiring every domain to know in advance or out-of-protocol what format(s) another domain supports.

(Online negotiation here may make more sense than in the authorization-establishment case, because it's more reasonable to believe what a domain says about it's own asset formats than what it says about its own authorization to do an action.)

At a minimum, OGP should provide a way for two domains to:

  • establish that they have at least one format in common for describing a given asset,
  • agreeing on one of those formats, and
  • actually transferring the data

Assuming that we start with just one or two formats or format-families, there will probably not be much rocket-science there.

Transitive travel

One of the more complex sets of asset use-cases involves transitive travel: an asset created in one domain travels to another, and is left there in a state where it can then travel to yet others. For instance if a transferable inventory item is given by its creator to someone visiting from another domain, and that person (that agent) then travels to yet a third domain and attempts to give it to someone else. Or someone goes to a foreign domain and leaves something on public land with an "allow anyone to copy" flag set, and someone then takes a copy and travels to a third domain.

There are at least two sets of issues here:

  • Mechanics: when the transitively-traveling asset attempts to enter the third domain, should the second domain contact the originating domain to verify that the asset is allowed to do so? Or should there be sufficient information in the object data for it to make this determination itself? For simplicity we will assume the latter (which requires a sufficiently flexible representation of allowed domains in the asset metadata), but if we ultimately decide on the former OGP will have to include messages to allow this verification
  • Trust and risk: when transitive travel is possible, the originating domain (and therefore the content creator) is trusting domains that it allows assets to flow to in two senses rather than just one: not only is it trusting them to handle them well itself, it is also trusting them to honor the creator's intent about what other domains the assets should be allowed to flow to (and so on outward transitively). The alternative is to require that (say) all assets become non-transferable as soon as they leave their native domain; but that would be really annoying for the end user (who is obviously a very important stakeholder here).

See also