[cap-talk] Directory Patterns

[David Barbour]

On Wed, Apr 7, 2010 at 2:02 AM, John Carlson
<john.carlson3 at sbcglobal.net> wrote:
> However, one is still left with how to introduce participants to each
> other, with which requires a directory of some kind (phone book,
> same room, webpage, X.500, AD, ph, email, IRC, AIM, PKI, iChat,
> GoogleTalk, MSN, Skype, various groups, dating service etc. etc
>  -- SSL/TLS required).

We don't need any common directory. Many 'small' directories can
do the job. By favoring the 'many small directories', said directories
themselves are more readily secured. For example, one may have
many different registration and request capabilities even for one
small directory. Whichever cap is used to perform the registration
or request can attach unspoofable 'context' to it, to aid in policy
and decision making.

Usefully, directories may also be registered with one another,
in utterly non-hierarchical manners, creating a big old 'blob' of
securely composed directory cells. Such a blob has its own
immune system due to the potential to cut off cells that appear
to be misbehaving. (How long would you hang out with a friend
who kept insisting you give financial information to your cousin
in Nigeria, or suggesting your penis is too small?) Thus incentive
exists towards filtering out spam, or at least annotating it,
with hope that you won't ban the messenger!

I would expect on the order of a directory per human, plus one
for each organization thereof (groups, gaggles, company, club,
etc.). Additionally, processes and operating systems can use
directories to keep information about ambient authorities and
hardware resources. The total number is more a function of
management concern, than of directory size.

In addition to all this, plenty of caps would flow through
non-directory communications structures.

>
> And if you have a directory, you need some way to prevent
> spamming.  Hence, only one capability from the first party
> (potential spam) to request communication, and a reply
> capability to say communication is okay from the second
> party.  I believe some kind of identity is unavoidable.

I suspect that you believe that 'identity' is unavoidable *because*
you don't see any way to prevent repeated spamming other than
to filter based on a presumably expensive-to-forge identity. But
you don't need 'identity'. What you need is ability to filter repeat
requests. Any form of 'secure context' can offer this to you. In
many senses, identity is a specialized class of 'secure context'.

It is true that sealed values and offline certificates and such
can go a long way towards making a request more palatable
to its consumer, even if it came through untrusted venues. Those
are useful authority escalation patterns. Fortunately, one does
not need identity to utilize them.

>
> I am not sure why identity seems to be anathema in some
> capability circles (those that wish to remain anonymous?)

Identity cannot be delegated in a fine-grained manner, nor may
readily be the authorities associated with it. This both centralizes
burdens on the individual who controls the identity, and leads to
the 'confused deputy' issues.

Thus, we reject the use of identity for purpose of ***authority***.

Identity can still be a central locus for ***responsibility, reputation,
and blame***. Though, we don't really need 'human' identities for
these purposes: a simple 'unsealer' capability can service well in
that role.