Extending the car key metaphor

README.org

@@ -717,6 +717,7 @@ In this case, if the message was nice, Alice might refund Bob one
 or both stamps.
 She might even decide to hand him the authority to send messages to
 her in the future, for free.
+
 But say Bob is a spammer and is sending a Viagra ad; Alice can keep
 the stamps.
 Now Bob has to "pay" Alice to be spammed (and depending on how we
@@ -735,7 +736,7 @@ While we do not claim that we can fully model a system of consent in
 this system, we can provide the
 /maximum amount of consent that is possible to represent/
 in a system.
-Hopefully that is far enough; it would certainly be better than wha
+Hopefully that is far enough; it would certainly be better than what
 we have now.
 
 This document does not specify particular mechanisms but opens up
@@ -768,32 +769,79 @@ there is a lot we can make better.
 * How to build it
 ** Object capabilities (ocaps)
 
-*** But really, what is the ocap paradigm, I'm confused
+The foundation of our system will be object capabilities
+(ocaps).
+In order to "give" access to someone, we actually hand them a
+capability.
+Ocaps are authority-by-possession: holding onto them is what gives
+you the power to invoke (use) them.
+If you don't have a reference to an ocap, you can't invoke it.
 
-So far we've spoken of object capabilities only at a high level.
-Regrettably, I'm going to continue that for this subsection, but I
-promise to get into the implementation details in the next section.
-For the moment, I'm going to continue the high-level, long-spun
-ocap introductory narrative of ocaps as car keys.
+*** Extending the car key metaphor
 
-We previously gave an example of object capabilities as being like a
-car key: possessing them is what gives you access, rather than who you
-are being what gives you access (the car doesn't need to scan your face;
-if you have the key, you can drive).
-Like a car key, you can also hand ocaps to other people and they can
-use them (delegation).
+We equated this to car keys before; the car doesn't care who you
+are, it only cares that you turn it on using the car key.
+(Note: though capabilities can also be built on top of cryptographic
+keys, we're strictly talking about car keys for the moment.)
+
+We can extend the car-key metaphor further, and find out there are
+some interesting things we could do:
+
+ - *delegation*: We could hand the car key to a friend.
+   We could even make a copy for a trusted friend or loved one.
+ - *attenuation*: We could hand out a car key that is more limited
+   than the more powerful one we have.
+   For example, if we go somewhere with full-service-parking, we can
+   construct and hand the valet a "valet key" that only permits
+   driving five miles and won't open the glove box or trunk.
+   Sorry kid, you're not getting a joy ride this time.
+ - *revocation*: Let's say that Alice wants to allow her roommate
+   Bob to drive her car, but she also wants to be able to take away
+   that right if Bob misuses it or if they stop being roommates.
+   Alice can make a new car key that has a wire inside of it;
+   Alice holds onto a device where if she presses the button, the
+   key "self destructs" (ie the wire melts).
+   Now Alice can stop Bob from being able to drive the car if she
+   wants to (and if she does, it'll also disable access to anyone
+   else Bob has delegated a key to).
+ - *accountability*: Alice has multiple roommates, and while she would
+   like to allow them all to drive her car, the next time someone
+   spills a drink in the car and doesn't clean it up, she wants to know
+   who to blame by seeing who drove the car last.
+   Alice can achieve this via *composition*: she installs a separate
+   "logging" panel into the dashboard of her car, to which she has the
+   capability to view the logs.
+   Next, for the keys that she hands her roommates, she composes together
+   access to drive the car with the logging service and associates each
+   key with her roommate's name.
+   Now each time one of her roommates uses one of these keys, the logging
+   console (which only Alice has access to) takes note of the associated
+   name, so Alice can check who left a mess last.
+   
+You may have noticed that as we went further in the examples, the
+ability to construct such rich capabilities on the fly seemed less
+aligned with the physical car key metaphor (not that it wouldn't be
+possible, but certainly not with such ease, and certainly not with any
+cars that exist today).
+And yet ocap systems easily do give us this power.
+We will take advantage of this power to construct the systems we want
+and need.
+
+*** Principle of Least Authority meets normal code flow
 
-[... continue with valet and revocation car key metaphors here?]
 
 *** Ocaps as capability URLs
 
-
+That's all good and well, but real-world metaphors
 
 *** Ocaps as bearcaps
 
-
 *** Ocaps meet ActivityPub objects/actors
 
+** Delegation, attenuation, revocation, composition, accountability
+
+# and composition?
+
 
 ** True names, public profiles, private profiles