[E-Lang] Ownership certificates via capabilities?

[Ben Laurie]

hal@finney.org wrote:
> This is where an E solution seems to have problems.  The trivial method
> would be to give each player a bundle of capabilities to every other
> player in the world, that represents a given card.  So if Alice has the
> Gremlins card, she gets a capability to Bob that lets her "play Gremlins",
> a capability to Carol that lets her "play Gremlins", and so on, for
> every player in the world.  This bundle would represent the Gremlins card.
> When she then went to play against someone, she could use the appropriate
> capability for that person, and the game could proceed.
> 
> With cryptography we can efficiently create a sort of "meta-capability"
> that can be accepted by anyone.  Anyone can verify the PK signature and
> know that the game manufacturer has issued the card.  But I don't think
> E has a notion like this.
> 
> If the players knew in advance whom they were going to play against
> off-line, the bundle method could actually work and perhaps even be
> practical; they could just get the capabilities they need beforehand.
> And even if not, the bundle solution still works in principle.  So I no
> longer think that it can't be done in capabilities, and more specifically
> that it can't be done in E.

Well ... this is:

a) too horrible to contemplate

b) doesn't work if I haven't been online since you bought your cards: I
won't have the capabilities to you that allow me to play cards at you.

However, I'm slightly puzzled by the whole question: why would I want to
enforce offline capabilities in this way? Surely if we want to play a
game, we should manufacture the card capabilities _on the spot_ and not
mess around with the issuer of the damn things (after all, the only
reason to do that is to protect his revenue stream, and why would I want
to do that?)?

Also, the more I think about it, the less the idea of an "offline
capability" means anything to me - it is inherent that I must be able to
present the capability to its issuer, and _that_ is inherently online
(w.r.t. the issuer of the capability). What makes more sense to me is to
use capabilities to enforce rules that are to do with token exchange -
so if we go back to the card game, Bob and Carol have some tokens
(presumably signed by the issuer) which they show each other - they then
create capabilities that correspond to the ability to play the cards (in
the backwards way Hal described above) - _then_ the game can proceed.

And if the game involves exchange, then there has to be an (online)
mutually trusted third party that holds the linkage to the current owner
(I think), and some more complication in the setup. One of the nice
things about using capabilities to do this is that mutually trusted
third party should be possible to write in a pretty small piece of code
for many situations (the complicated stuff going on in the issuer(s),
which the "exchanger" talks to). This last is _definitely_ a referfence
to MarkM's slides :-)

Or am I talking out of my hat?

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

ApacheCon 2001! http://ApacheCon.com/