[cap-talk] Capabilities - the rub, identity

[John Carlson]

>>
>> "account capability"?  Where did an "account capability" come into
>> the picture?  Are you referring to some sort of identity?
>>
>
>> From the description, it sounds like he's referring to what you would
> call a directory. His "2-factor capability" is then simply the  
> directory
> capability + the index/name into the directory.
>
> Sandro

I'm not so sure it's like a directory, unless the directory is like a  
class
with instances in it.  I am just saying the object reference has two  
pieces
to it, like a YURL might.  I'm not saying they have to be distinct  
pieces
of the YURL, just that there's some algorithm to pull out the account
if the kernel requires it.  It might be transparent to the user.  It  
might
be a signature or an encrypted piece of text, similar to managing  
domains,
section 13.

Maybe we should try to clairify the difference between capabilities
and public key encryption, since Jed has married them in my brain.

My understanding is that the capability is what is encrypted or signed.
encrypting or signing something doesn't alone give you any authority.

Thus the 2-factor capability is the marriage between your public key
identity and the normal capability.  They must go together to allow
the system to work.

The capability must be signed by the system for it to be used as a  
capability.
The system will only honor capabilities that are signed by an account
holder, and that account must be in the system's public key ring- AN  
ACL!

I'm getting tired of treating capabilities separately from ACLS when  
they
can be clearly used together.  Read Jed's paper!

Argh!  No wonder everyone's frustrated with capability people!

John