Robert Watson writes:
> The problem is really that in an ideal world we would support all of these
> authentication mechanisms, and then have some policy description language
> that told us what authentication to accept, deny for various identities,
> and how to map all of the various types of identities to ones that Coda
> understands.

A neat idea, but it might prove very hard to do in practice.

I'm usually happiest with systems that are reasonably simple. A
general mechanism like that sounds ideal, and would be an interesting
research project, but what would it do to people who wanted to
actually use it?

Still, I understand the reason you wouldn't want to lock in to a
single mechanism. After all, what if you pick the wrong one?

Maybe what you ought to do is outline the kinds of authentication and
authorization that Coda needs, and figure out how the other mechanisms 
map into this. Perhaps then it would be more obvious what your needs are.

> I will reread the SPKI drafts and get back to you with my thoughts on
> adding support to Coda.  Coda, as an off-shoot of AFS, does seem to follow
> the tradition of centralized, closed servers -- it would be interesting to
> see how SPKI could fit into this architecture.

SPKI would probably fit reasonably well, depending on how you used
it. Purely off the cuff (and not with deep thought on this yet), I
would *not* envision the use of long lived certificates, but rather an
authentication server that handed out certificates that lasted a
fairly short period, with said credentials being used in a manner not
entirely unlike the way that a Kerberos TGT gets used, except without
the KDC or other complexities in the protocol.

> In a sense, my currently implementations of various authentication
> schemes map foreign identities to local names, where the existence
> of mapping rules forms a sort of authorization model for providing
> "Coda Tokens" to the entity in question, allowing them to
> authenticate as the coda local name when contacting servers.  Maybe
> we should be looking at some other models?

As a quite serious offer, I'd like to help you explore possibilities
here. There is some cool research to be done, and now that Coda 
is moving into a more public model, it might be an interesting thing
to collaborate on this.

Perry