Capsicum revocable (proxy) file descriptors

I was wondering what design choices other developers would have when
designing a new file descriptor type for access revocation purposes in
a capability system.

The standard practice to revoke capabilities is to create a new
capability in a domain the user has control over and can revoke at any
later time[1]. For Capsicum, we can't quite do that.

If a new file descriptor type were to be designed just to forward
requests (which the creator could revoke later), what design concerns
should be taken into consideration?

[1] http://wiki.erights.org/wiki/Walnut/Secure_Distributed_Computing/Capability_Patterns#Revocable_Capabilities