Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Why embed the caveat in the ocap? #11

Open
kephas opened this issue Jul 31, 2018 · 5 comments
Open

Why embed the caveat in the ocap? #11

kephas opened this issue Jul 31, 2018 · 5 comments

Comments

@kephas
Copy link

kephas commented Jul 31, 2018

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
Copy link
Contributor

cwebber commented Aug 1, 2018

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
Copy link
Contributor

cwebber commented Aug 1, 2018

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

@alanhkarp
Copy link

alanhkarp commented Aug 1, 2018 via email

@cwebber
Copy link
Contributor

cwebber commented Aug 1, 2018

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

@kephas
Copy link
Author

kephas commented Aug 22, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants