[cap-talk] Capabilities as Rights

Ian G iang at systemics.com
Thu Mar 24 20:53:18 EST 2005

Nick Szabo wrote:
>>At higher levels, in particular circumstances, you may indeed have some basis 
>>for expecting that the object in question is what the requestor thinks it is. 
>>But now we're talking at a whole 'nother level of abstraction.
> Thus it's a bad idea to term any particular layer a "Rights Layer".   

I believe that Mark and Nick are referring to my FC7 layer
model, which places Rights at layer 3.  Mark in fact applied
the term Rights to layer 3, which was so much better than what
I had there before that I've forgotten it!

    ( Ref: http://iang.org/papers/fc7.html )

Rising to Nick's challenge, I think the Rights layer expresses
something different to that which Nick is criticizing, and
also to some extent that which Jed is trying to nail down.

What the Rights layer attempts to do is to craft a technological
framework that is ideally suited to the construction of a
technical Rights system.  For this reason it includes Caps,
Nyms, ACLs, and noddy passwords, without prejudice to the
poverty of some of these ideas.  (Same thread as whether the
definition of Caps should include bad design ideas - I vote
yes on that one.)

What the layer doesn't do is give you Rights.  Better, it says
to the next layer up, if you wanted to construct Rights, this
is our best shot at giving you the tools to do that.  But, the
actual Rights - the notion of property or access or money - is
crafted out of this by the higher layer(s) using the primitives
in the Rights layer.

To clarify, therefore, I am suggesting that Capabilities does
not "give you Rights."  It instead says, to do Rights, this is
the best way to do them.  We've given you the best framework,
now each right in and of itself, and what you do with it, is
up to you to create and use.  Enjoy!

This is an API model in a sense.  The API doesn't give you the
thing, but it makes it easy to construct, and indeed it is so
tuned to that, it's known as the 'thing API.'

 > Furthermore, much important enforcement of rights can occur at a parallel or
 > lower layer (e.g. in cryptographic libraries, in multi-node institutions
 > such as secure property titles, and so on), or without capabilities entirely.

Which all fits.  The Rights layer uses the lower two layers to
deliver its 'API'.  Although to be fair, what you perceive as
Rights comes at a much higher layer than what I termed Rights in
the layered model, so in your terms, that layer is "technological
rights, hence capabilities" and to get to your idea of rights,
we'd have to go up and include governance (institutions,
contracts, dispute resolution) and value (concepts of how each
right responds in the market place).  Perhaps, I'm guessing here.

Like any model, if you get too close and stare too long, it
disappears ;)  It's meant to be a managerial and architectural
broad brush framework to help get the big picture squared up,
not a challenge to each of the layers or techniques themselves.

 >>I'd think an object has an *ability* to send and receive
 >>messages.  I'm somewhat at a loss to see what calling
 >>these things 'rights' gives us.
 > There's a meta-goal here, that markm and I and presumably many
 > other people on this list share, of creating analogs of legal
 > rights online, then protecting these metaphorical rights with
 > computer protocols instead of traditional legal remedies.   This is
 > the core of my smart contracts idea and markm's "computer security
 > as the future of law."

Yes.  That's what FC7 seeks to achieve, and that's what things
that claim to be FC apps do achieve.  Of course, whether there
are better models is always open to question.

( Messages are a
   layer 2 device, demanded by the layer 3 concept known as
   Capabilities, in delivering its ideal of Rights.  Calling
   messages as rights, or saying a subject (?) has a right
   to send a message brings the term into the wrong place,
   I feel.   IMHO!  )

( is there a URL for markm's "computer security as the
   future of law." ?? )

News and views on what matters in finance+crypto:

More information about the cap-talk mailing list