User:Dale Innis/Asset handling in OGP
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.
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.
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.
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.
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.
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.
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.