From 5693f0fda17f4e7d31e6e46d3623244fd536f25b Mon Sep 17 00:00:00 2001 From: Bob Mottram Date: Sun, 7 Jul 2019 18:51:03 +0100 Subject: [PATCH] Note about ocap enforcement --- README.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/README.md b/README.md index 0e149e1a..937b1344 100644 --- a/README.md +++ b/README.md @@ -128,6 +128,8 @@ When posts are subsequently sent from the following instance (server-to-server) Subsequently **Bob** could change the stored capabilities for **Alice** in their database, giving the new object a different id. This could be sent back to **Alice**, perhaps as another **follow Accept** activity with attached capabilities. This could then change the way in which **Alice** can interact with **Bob**, for example by adding or removing the ability to like or reply to posts. +Object capabilities can be strictly enforced by adding the **--ocap** option when running the daemon. The only activities which it is not enforced upon are **Follow** and **Accept**. Anyone can create a follow request or accept updated capabilities. + ## Object capabilities adversaries If **Eve** subsequently learns what the capabilities id is for **Alice** by somehow intercepting the traffic (eg. suppose she works for *Eveflare*) then she can't gain the capabilities of Alice due to the *scope* parameter against which the actors of incoming posts are checked.