This paper will explore the connection between terms and concepts such as rights, duties, assignment, and delegation as they are used in computer security and law. Computer security has borrowed these terms, along with many other means and ends, from law. We will shed light on the delegation-of-authority problem, "design by contract", and related issues using more refined or appropriate legal analogies.
Indeed, computer security can be seen as an attempt to create a self-enforcing subset of law in and for cyberspace. Security concepts such as access control lists (ACLs) and capabilities try to create a language of mechanism-enforced rights of access to services and information while limiting assignment or delegation. More recent ideas such as digital rights management (DRM), distributed capabilities, cryptography (broadly defined), smart contracts, and so on try to do this in a distributed context.
Computer security would benefit both from borrowing more legal ideas, and from clarifying the meaning of those already borrowed. To this end, this article introduces certain concepts and terminology from the Anglo-American common law, comparing and contrasting these to computer security.
Law as security is based on physical or financial remedies -- ejectment from land, specific performance of a transfer of land or goods, monetary damages, an injunction to not use property in a certain way, and so on, ultimately backed up by the threat of force against identified and tracked individuals and their property. Computer security, in contrast, relies on self-enforcing mechanisms and logging combined with out-of-band remedies (reputation, human intervention to remove access, or recourse to the legal system). Self-enforcing mechanisms, when they can work, are far more efficient and far less dangerous to society than legal remedies, but they allow for coverage of a far narrower range of conflicts among computer users than the law covers among traditional kinds of disputes. Remedies are the lowest layer of a security protocol, with the rules defining access and relationships layered on top of them.
When one assigns rights, the assignment simultaneously (from the point of view of a judge looking back at the transaction) extinguishes the right in the assignor and creates it in the assignee. When one delegates a duty, however, the delegator doesn't get off the hook. The delegator becomes a surety for breach of contract by the delagatee. If the delagatee doesn't perform, the delegator is put back on the hook for the performance. When computer security lumps together rights and duties into authorities, it loses the crucial idea of the original obligor as a surety for subsequent obligors. This is necessary for an authority that includes a duty not just a right. For example, an e-mail client may have the authority to use an e-mail server. But this authority can imply both a (non-legal) right and a (non-legal) duty -- the right to send e-mail, and the duty to not send spam. When a computer security analyst worries about delegation of authority, he is usually worried about the abuse of that authority. The issue is clarified by thinking about that abuse as a violation of a duty to not abuse the authority. One can then look to legal patterns for solutions. For example, following contract law, one could hold the original holder of an authority accountable for any subsequent abuse of that authority -- i.e. upstream holders of an authority are sureties for downstream holders. On the other hand, if there is no significant threat of harm (e.g. for the authority to use a megabyte of disk space), and thus a right but no duty (the obligee can use the disk space for whatever he wants, with no way to overload the system), the problem is merely one of assigning a right, and is far easier -- the computer security mechanism need not keep track of the intermediate authority holders or indeed even keep track of the identity of holders at all. A scarce object architecture would facilitate the construction of online services where abuse is not a worry -- transmuting difficult delegation problems into easy assignment problems by architecting the service to present itself as "scarce" like physical objects.
An easement can be in gross, meaning that the obligee is a named person. An in gross obligee can assign his right as if it were a contractual right. However, the duty runs with the servient property i.e. the duty lies with the possessor of the servient property. If Alice agrees to let CableComm string cable across her land, CableComm can by default assign this right to DigitalData, EveElectric, or whoever. However, since the duty runs with the property, the only way Alice can delegate the duty is to transfer possession of the property. The new possessor now owes the duty to allow the current obligee to string the cable.
If, however, the easement is appurtenant, both the obligee and the obligor are the current possessors of the appurtenant properties. For example, Alice agrees to give her neighbor Bob a permanent right-of-way to drive on a road through her land to get to the public highway. Alice and Bob may sell or devise their properties, and so on, but the easement always is a duty of the current possessor of the servient property to the current possessor of the dominant property. The current possessor of the dominant property cannot assign the right without selling or devising the property the right and the property are inseparable. Ditto for the duty of the possessor of the servient property.
A license is a revocable easement. You use these every day -- you gain an implied license when you enter a restaurant to eat, or a grocery store to shop, for example.
Object-oriented programming has a concept called "design by contract" where a set of tests, called pre-conditions and post-conditions, must be passed for the contract between a client and server object to be satisfied. In capability security, one speaks of authority to call an object as a capability, and by analogy a right. A more accurate legal analog for distributed object security may be an easement or license between objects, rather than a contract between persons. The servient vs. dominant duality maps nicely to server vs. client. The passing of an exclusive capability corresponds to the assignment of an in gross easement or license. The passing of a non-exclusive license or easement is seen to be something that is very uncommon and troublesome in the law (outside of copyright law, where, unlike for physical property and persons, use does not exhaust the resource).