I'm also a fan of Macaroons for this purpose, which I was disappointed to see weren't being used here. But for an example of using macaroons as capabilities in practice, see: http://hackingdistributed.com/2014/11/23/macaroons-in-hyperd...
App-to-app sharing is a different matter. We are working on allowing an app to receive a capability to access another app, and it should of course be able to delegate that capability to other apps. (Delegation is even more important between apps than it is between users, because we want to be able to write small, modular apps that work together rather than monolithic apps.)
At this level, Sandstorm sharing is based on Cap'n-Proto-style capabilities. Cap'n Proto has concepts similar to macaroons but takes a different approach in that we prefer that all sharing must happen "live" so that the server can keep track of who has what.
When you have an open Cap'n Proto RPC connection and have received a capability (object reference) over that connection, that's called a "live ref". Cap'n Proto allows live refs to be passed from machine to machine (delegated) in RPC messages. But if the connection dies, all live refs are lost. So, to keep it long term, you want to convert it to a "study ref", which is a byte string you can save to disk.
A sturdy ref, however, can only be restored to a live ref by the same entity who saved it, where "entity" is some course-grained authenticatable identity. The idea here is that if a hacker manages to obtain a raw copy of your database, you don't want to have to revoke every sturdy ref contained therein. A course authentication component prevents them from doing anything with any of those tokens.
Macaroons are also a byte string that grant access to a resource, with a format that allows you to attenuate the capability offline. That is, if I have a macaroon allowing read-write access to a document, I can create a new macaroon that gives only read access, and then pass that to someone else, all without consulting the document's server.
For Sandstorm, we actually don't quite want that, because we want the document owner to be able to see how their document has been shared. So, to share a sturdy ref, we require you to restore it to a live ref and delegate that. The recipient can save a new sturdy ref tied to them.
That said, Sandstorm is doing some pretty impressive mappings of capabilities to web applications. Really interesting work!
I've looked at Capnproto in the past but did not read through the documentation thoroughly enough to see the bits about capabilities (or the link to the pdf version of the same myths article I linked above!)
>For Sandstorm, we actually don't quite want that, because we want the document owner to be able to see how their document has been shared. So, to share a sturdy ref, we require you to restore it to a live ref and delegate that. The recipient can save a new sturdy ref tied to them.
@bascule alluded to this, but this can actually be very nicely modeled with macaroons! The idea would be to create a capability-granting macaroon but attach a "third party caveat" that asserts the grantee must be able to prove they are the "authenticatable identity". You end up with the same properties as the live/sturdy refs, if I understand properly.
Mostly it's just cool to see different implementations of capability-based access control.