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.
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.