Although it can minimize the overhead of third-party tags, it also makes it trivial for anyone with credentials to add costly tags.

In order to avoid the confused deputy problem, asubject must be careful to maintain the associationbetween each authority and its intended purpose. Using the key analogy, one could imagine immediatelyattaching a label to each key upon receiving it, wherethe label describes the purpose for which the key is tobe used. In order to know the purpose for a key, thesubject must understand the context in which the key is received; for example, labelling is not possible if keysmagically appear on the key ring without the subject’sknowledge.

Even if one can distinguish the keys, decidingto try all available keys puts one at risk of becoming aconfused deputy.

We would argue that the “true” capability model is the object-capability model, because all known major capability systems take the object-based approach (forexamples, see [1, 4, 9, 11, 16, 17, 19, 21]). In all ofthese systems, a capability is an object reference–not something that behaves like a key or ticket in the realworld. Definitive books on capability-based systems[6, 16] also describe these systems from the object-capability perspective, and explicitly characterize themas “object-based”.

The claim that capability systemsin general cannotenforce the *-Property appears to be based on themisunderstanding that capabilities and data are notdistinguishable.

Theonly capability Bob holds to a lower level is a readcapability, so the *-Property is enforced. The onlycapability Alice holds to a higher level is a writecapability, so the Simple Security Property is enforced

we examine three different models thathave been used to describe capabilities, and define a set of seven security properties that capture the distinctions among them