4 ms·

There's a paper called "Capability Myths Demolished" that addresses this. There's an online version here[0], see "revoking access". Personally I'm fascinated b

There's a paper called "Capability Myths Demolished" that addresses this. There's an online version here[0], see "revoking access". Personally I'm fascinated by ocap systems and am always looking for ways to employ them. There are some interesting "modern" applications (aside from a couple of research kernels) like CapnProto and Pony language. Macaroons come close but are more of a hybrid approach to authorization. (They don't out of the box prevent confused deputy or anything) [0]: http://www.erights.org/elib/capability/duals/myths.html http://www.erights.org/elib/capability/duals/myths.html

bascule 11y ago
Yes, Capability Myths Demolished describes the "revocable forwarder" pattern, which uses a proxy to delegate access in a revokable manner. Macaroons on the other hand are nice because they don't need a proxy to solve this problem: the authorizer can issue a short-lived "discharge Macaroon" to authorize access, then the client can get to the target resource directly without the need to use a proxy. To revoke access: just refuse to issue subsequent discharge Macaroons when the current discharge expires.
- kentonv 11y ago
  A common optimization in a capability system is to allow a remote client to create a new revokable membrane living on the same machine as the target object, thus avoiding introducing a new network hop due to the proxy. Said client receives a separate capability to revoke the new wrapper, which it can exercise later. Or, the client might supply the object host with some other instructions on when revocation should occur. Macaroons can probably be seen as an implementation of this.