Implementations may realize the difficult-to-tamper property using one of the following arguments.
- Plausible arguments suggest and assume some computing security mechanism such as mail-box access control.
- Intractable arguments depend on mathematically difficult propositions such as one-way functions, digital signature algorithms, or encryption algorithms. These arguments can rely on the existence of tamper-resistant hardware within the system for their implementation design.
- Infeasible arguments depend on mathematically infeasible propositions such as solving a system of equations with more variables than equations. An example may be the use of mathematical objects such as Shamir's secret sharing schemes. These arguments can rely on the existence of tamper-resistant hardware within the syste for their implementation design. These systems may require the use of more than one secret to construct or reconstruct a capability with designation that the system can understand.
Some examples of unforgeable capabilities:
- Designations of objects in the E language. Those who hold these capabilities have the permission to invoke any method supported by the designated object.
- Designations of functions and procedures in Emily. Those who hold these capabilities have the permission to call designated functions or procedures.
Some examples of capabilities that are infeasible to forge:
- Designations of remote objects in E, such as captp://*email@example.com:55189/oa6vn5whhapylswhzesdlqh5ppmjkcrq. Those who hold these capabilities have the permission to invoke any method supported by the designated object.
- Password capabilities
- Private URLs where having the URL is necessary and sufficient to use the resource. Common examples are:
XXX What exactly do we mean by password capabilities here, such that a captp URL is not one?
XXX improve this section
See What is a Capability, Anyway? for a partisan explanation of what capabilities actually are.
See also Overview: Capability Computation