Why embed the caveat in the ocap?

[kephas]

I don't see the reason for ocaps to contain their policy.

In typical ocaps systems, an ocap is just a callable reference, so there should only be a need for the reference… If you want a limited capability, you create another reference, to an object that implements the limitation.

I could see the usefulness of a vocabulary of limitations, so when I have a ocap, I can ask its host system to handle me another capability.

{
    "@context": "https://example.org/ocap/v1",
    "id": "https://whatacar.example/a-fancy-car/proc/7a397d7b",
    "type": "Capability",
    "host": "https://whatacar.example/host"
}

If I want the revokable capability, I POST to https://whatacar.example/host something like:

{
    "@context": "https://example.org/ocap/v1",
    "type": "Capability",
    "prototype": {
        "class": "caretaker",
        "target": "https://whatacar.example/a-fancy-car/proc/7a397d7b"
    }
}

And I would get in return two capabilities, give the first to Bob and keep the second for me to invoke when I want to revoke the first.

{
    "@context": "https://example.org/ocap/v1",
    "created": {
        "proxyFacet": {
            "id": "https://whatacar.example/a-fancy-car/proc/cd6be9ca",
            "type": "Capability"
        },
        "revokerFacet": {
            "id": "https://whatacar.example/a-fancy-car/proc/f51e3f27",
            "type": "Capability"
        }
    }
}

Also, in the current scenario, Bob can prevent his capability from being revoked, or the car to notice that his capability has been revoked, by making the revocation unreachable (for example by DDoSing the social.example server).

[cwebber]

Heya @kephas! You're right in that "language-style" and "actor-style" ocaps, the way you'd build in caveats is to build caretaker proxy objects that live and redirect requests for you. In fact, you can still build a caretaker with ocap-ld that performs in the way you describe above, and ignore the caveat system.

However, this is a "certificate-style" ocap system, there are some reasons why you may wish to express policy publicly this way:

• You might not want to require that entities in the system have to "host and maintain" an intermediate caretaker. In ocap-ld, ocaps can be issued to participants that never host a web server at all, and those participants can further delegate their capabilities likewise to other participants who never host a server themselves.
• You may be building a system such as a blockchain where many entities are executing and verifying the behavior of the system. In fact, Veres One is built on top of ocap-ld in this way.
• It may be that you wish the receiving party to be able to "understand the enforced policy of the system". I think this will be less common, but the information will be there, and linked data means that this can be reasonable.

There are probably others, but those are the big ones I think.

Also note that ocap-ld's caveats system share a lot of similarities to the caveats in Macaroons (and certainly borrow the name from there), a bearer token system that is mostly ocap'ish. I think (but may not be right) that the Zebra Copy system @alanhkarp worked on did this too.

[cwebber]

Does that answer your question enough to close this @kephas ?

[alanhkarp]

Christopher Lemmer Webber notifications@github.com wrote:

I think (but may not be right) that the Zebra Copy system @alanhkarp https://github.com/alanhkarp worked on did this too.

Almost. Zebra Copy recognized two kinds of permissions in the capability. The first was methods on the target object, which was a white list, e.g., methods being authorized were explicitly listed. This part was enforced by the infrastructure. The second was related to parameters of the methods that had to be interpreted by the object itself. The theory, to use the term extremely loosely, was quite general, but all the examples were like caveats, in that they set limits on legal values. For example, a print service might have print_color(no_copies) and print_bw(no_copies). A Zebra Copy capability might list print_bw with a caveat no_copies < 10.

---

Alan Karp

On Wed, Aug 1, 2018 at 1:05 PM Christopher Lemmer Webber < notifications@github.com> wrote:

Heya @kephas https://github.com/kephas! You're right in that "language-style" and "actor-style" ocaps, the way you'd build in caveats is to build caretaker proxy objects that live and redirect requests for you. In fact, you can still build a caretaker with ocap-ld that performs in the way you describe above, and ignore the caveat system.

However, this is a "certificate-style" ocap system, there are some reasons why you may wish to express policy publicly this way:

• You might not want to require that entities in the system have to "host and maintain" an intermediate caretaker. In ocap-ld, ocaps can be issued to participants that never host a web server at all, and those participants can further delegate their capabilities likewise to other participants who never host a server themselves.
• You may be building a system such as a blockchain where many entities are executing and verifying the behavior of the system. In fact, Veres One is built on top of ocap-ld in this way.
• It may be that you wish the receiving party to be able to "understand the enforced policy of the system". I think this will be less common, but the information will be there, and linked data means that this can be reasonable.

There are probably others, but those are the big ones I think.

Also note that ocap-ld's caveats system share a lot of similarities to the caveats in Macaroons https://ai.google/research/pubs/pub41892 (and certainly borrow the name from there), a bearer token system that is mostly ocap'ish. I think (but may not be right) that the Zebra Copy system @alanhkarp https://github.com/alanhkarp worked on did this too.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c-ccg/ocap-ld/issues/11#issuecomment-409704262, or mute the thread https://github.com/notifications/unsubscribe-auth/AIoJ82yP5y6qYuvFj3FWYKK2LV4mHF-qks5uMgoUgaJpZM4Vpn9C .

[cwebber]

Cool... so it sounds like "caveats" just gives us a general, extensible version of such restrictions the way Zebra Copy had.

[kephas]

I see the use when mutliple parties may check the capability.

When there's only one, though, there is no need to host and maintain. Creating a caretaker should just be an option of the target capability's already existing host. If the latter can understand the cartaker caveat, it can create a caretaker capability.