Extending the car key metaphor

This commit is contained in:
Christopher Lemmer Webber 2019-07-21 11:09:05 -04:00
parent 72edb72241
commit 7377c2137f
No known key found for this signature in database
GPG Key ID: 4BC025925FF8F4D3

View File

@ -717,6 +717,7 @@ In this case, if the message was nice, Alice might refund Bob one
or both stamps. or both stamps.
She might even decide to hand him the authority to send messages to She might even decide to hand him the authority to send messages to
her in the future, for free. her in the future, for free.
But say Bob is a spammer and is sending a Viagra ad; Alice can keep But say Bob is a spammer and is sending a Viagra ad; Alice can keep
the stamps. the stamps.
Now Bob has to "pay" Alice to be spammed (and depending on how we 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 this system, we can provide the
/maximum amount of consent that is possible to represent/ /maximum amount of consent that is possible to represent/
in a system. 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. we have now.
This document does not specify particular mechanisms but opens up 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 * How to build it
** Object capabilities (ocaps) ** 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. *** Extending the car key metaphor
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.
We previously gave an example of object capabilities as being like a We equated this to car keys before; the car doesn't care who you
car key: possessing them is what gives you access, rather than who you are, it only cares that you turn it on using the car key.
are being what gives you access (the car doesn't need to scan your face; (Note: though capabilities can also be built on top of cryptographic
if you have the key, you can drive). keys, we're strictly talking about car keys for the moment.)
Like a car key, you can also hand ocaps to other people and they can
use them (delegation). 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 *** Ocaps as capability URLs
That's all good and well, but real-world metaphors
*** Ocaps as bearcaps *** Ocaps as bearcaps
*** Ocaps meet ActivityPub objects/actors *** Ocaps meet ActivityPub objects/actors
** Delegation, attenuation, revocation, composition, accountability
# and composition?
** True names, public profiles, private profiles ** True names, public profiles, private profiles