[cap-talk] can one use capabilities to stop spam without identity?

[John Carlson]

Capabilities use introduction to get two parties communicating.  This  
effectively stops spam.  But how can two parties who don't currently  
communicate with each other start communicating?  Apparently, a third  
party that the two parties know needs to introduce them.  But how  
does one of the two parties express an interest in communicating with  
the other party, and how does the third party (assuming that the  
third party is an automated system) make the determination that this  
communication can succeed?

I see a few of alternatives:

Both of the two parties express an interest in communicating with  
each other.   This means that, one,  they have already been  
communicating, and have ways of identifying each other separate from  
capabilities.  Thus this system is an identity (badge) based system-- 
I hear ACLs coming, run!

There is a directory somewhere of parties on the server, and one can  
request communication with any party in the directory.   This opens  
the floodgates to identity spam, but perhaps this can be choked off  
by an effective DoS defense, and blocking by individual parties.   
Each party can get a page that lists who is interested in  
communicating with them, and can select who they are introduced to.   
This also requires some kind
of identity based system in the directory.

In Jed's scenario, the readable part of the capability may be shown  
to the user, and they can select who can communicate with them.  When  
the
other party agrees, the signed capability is sent to the user.  But  
Jed's public keys make this system identity based as well, where the
public key/certificate is the identity.

Can anyone help me see another alternative that is pure capability  
friendly?  I keep getting stuck on this identity issue.  The only way
I can see through this is if the third party WANTS to introduce the  
two, which is weird for an automated system.

Thanks,

John