[cap-talk] email

[Anupam Simlot]

Hello everyone,

This is probably a dumb idea. My ignorance is definitely
betrayed here. Forgive me if someone has already
proposed a similar or better idea. I came up with this
while trying to figure out exactly what waterken is.

E-mail is currently the most anarchic and abused part of
the wild wild west, err sorry, the internet. I'm sure
you're all aware of what's wrong with it so I won't
delve into that here. What I would like to propose is an
alternative, yet backwards compatible, system based on
the concept of ocaps.

In this system, messages are not one way but form a part
of a transaction to request the target to perform
certain operations. One such operation might be to read
some text. Another might be to request a mailing list to
delete a stored message.

One party would be represented to another by the
following:
   1. storage pools
       Where messages are stored until retrieved
       by the target of the message. They are
       represented in the traditional e-mail
       address format: ye.olde at email.adrs.
   2. public key
       For encrypting messages. While this serves
       as one's primary id, one can not do
       anything with it alone.
   2. capability ids
       Represent which operation the sender is
       allowed to request of the target. A
       capability may allow for anonymous
       requests even.

For example, let us say Alice wants to send her resume
to Bob whom she met at a job fair. At the fair, Alice
gave Bob the URL to her manifest file and Bob gave her
the URL to the company's manifest file (or may be just
his). A manifest file would include just enough
information for the first transaction between two
parties.* An exchange of manifest files is required if
the capabilities do not allow anonymous transactions.
Otherwise, only the target's manifest file is needed.
When Alice goes home, she'll import Bob's manifest into
her client. She would then instruct her client to send
her resume along with an introductory letter to Bob. The
client would assemble the instructions along with
information to respond to the request. This would be
encrypted with Alice's private key. The encrypted text
along with Alice's public key would be encrypted with
Bob's public key (taken from the manifest). This is then
sent as a MIME attachment to the appropriate storage
pool (via SMTP, etc.). Bob's client would then extract
the resume and letter and post them in HR's database.
Finally the client would construct a reply to Alice
(based on the information in her message) informing her
of the success of the transaction.

I understand object capabilities would not place
restrictions on the identity of the requester but this
is useful for combating certain attacks. Since messages
include the sender's identity, this an open option for
clients.

Additionally, this system would be akin to edge
addressing where a capability would represent the party
who uses them. If the party abuses their authority, such
as by sending spam, the capabilities can be revoked.
(New capabilities can be reissued if the abuse was due
to a system compromise rather than a malicious
attack).

There is probably more to say regarding pseudo-anonymity
and decentralization.

* There is nothing inherent in manifest files that
require them to provide only information for first
transactions. I imagine them to be a useful vehicle
for transmission of capabilities and identity.

I hope most of that made some sense. :/\)

---