Hello!

Warning: relevant mostly for developers.
Comes to Coda at the end, thus either ignore the whole or be patient :)

Looking at the identification solution in the "real world".

Each country is issuing travel passports for its citizens.
Other countries do (or do not) trust the corresponding passports,
depending on the country. So you _can_ be sure a person _is_ who
he claims to be, even if you are a Swedish officer dealing with a French
visitor...

In that sense all national passports are "global identities".
We lack such ones in the computer world.

Of course I can decide that I trust someone's NIS database,
or some DCE cell. Still I have two vital problems:
 - how do I verify identities against those databases?
   (verification protocol has to be spoof-protected and not need
   any special contract between myself and the database owner.
   E.g. with DCE I have to register my host principal in the database
   before I can reliably verify someone's password in the corresponding
   cell - normally not allowed to...)
 - how do I name identities if they can come from different databases
   with different naming conventions?
   (compare, an international country code together with a passport number
   is guaranteed to be unique across the world.
   In contrast, there is no registry over password databases :) nor any
   guarantee that names from different databases will look in a similar
   way, you may have <uid number> in one of them, "firstname.lastname" in
   another and "a=XX,b=YY,c=ZZ" in a third one...)

So I'd love to have a global identities namespace. Then all I need is to
use those global identities in my ACLs for any service,
say the list of those allowed to login to a host,
or -------------"--------------- read a file on Coda.
Thus solving the _authorization_ step, which is the main goal of
authentication.

I see the most practical approach in setting up a "new" globally available
service, which would use existing (big, maintained and very useful)
user databases like NIS domains, Kerberos realms, DCE cells and similar.

As soon as my authentication authorities are exported in a global fashion,
they become useful for all who trust my security procedures.
Then instead of applying for an identity (name and password) at say CMU,
I'd simply ask for allowing login+ftp+... access for my Chalmers account.

Given there'd be a corresponding pam module capable of verifying global
identities, it's done. All pam-ifiable services in the whole world will be
cooperative at least as much as their administrators. More is impossible
to ask for :)

Now to Coda. There is some experimental code (I am running it for a
couple of months) making a Coda realm capable of using several
kinds of user authentication databases.
Moreover it maps them into a globally unique namespace like
johnsmith/krb5-cs_at_codarealm.somewhe.re

It is possible to fetch a corresponding Coda token for that
identity and Coda realm, even if you do not have any special relation
to that realm - as long as you know the identity's password.

So far so good.

Still, we cannot use that identity in our "ACLs" for login,
print, anything outside /coda/codarealm.somewhe.re/....
as we have to know for sure the fetched token did come from
the codarealm's server, not from a spoofed one!

Fortunately, there is a possibility to fetch a token from a Coda realm,
being protected by public key authentication. Such token could be used to
verify any other token - and reliably prove its validity - if there'd be
a "verify token" RPC2 operation supported by the auth2 daemon...

It is a rather small change, not breaking in any way the main
functionality, but making Coda tokens globally useful as a means of
proving one's identity.

Some day Coda could possible allow "foreign identities" in its groups
and ACLs, making cross-realm cooperation a lot easier and
mostly eliminating the need to authenticate oneself against multiple
realms.

Right now, the immediate effect would be making Coda (the only?) really
global authentication framework. I suppose, that has never been a target
of the project :) but that would be useful both for us system
administrators and for Coda development, raising the interest and
awareness about it.

I am convinced the developers should take a discussion on this matter
as we have a lot to gain and a lot to loose if we don't make a right step.

Yours,
--
Ivan