@cwebber Do all endpoints need to know about attenuated ocaps and their restrictions, or should there be some sort of attenuation service that forwards requests after checking whilte-listed operations?
Or would we need to pass round chunks of signed metadata that describe the caveats put on a capability?
@jack Hi! These are great questions. It depends on the kind of ocaps you're doing, first of all! Let me give you two versions:
- programming ocaps: an object/function has a reference to another object/function. They forward some calls but not all (eg forward only certain methods). No requirement of "shared terminology". http://mumble.net/~jar/pubs/secureos/secureos.html http://erights.org/elib/capability/ode/index.html
- certificate ocaps (eg zcap-ld): require shared understanding of terms https://w3c-ccg.github.io/zcap-ld/
@jack Now the former does not require "mutual understanding" of terms; whoever is the proxy knows what is and isn't allowed and simply forwards or doesn't. (However, "shortening" is an option so that server A both does not have to "proxy" to server B; this would require setting up an equivalent proxy back on server B again, which requires that server A and B can negotiate what that attenuation is.)
In the case of certificate ocaps, then there does require some mutual terminology understanding
@cwebber Aha! I hadn't seen the ZCAP-LD document before, that's helpful (and matches what I had in mind about shipping metadata around!).
What we're doing is based around linked data and a bunch of microservices using shared terminology, so that's certainly more relevant than the PL-style ocaps.
My home on the Fediverse.