Hello Stephan,

thanks for the feedback!

> But think about it.  A Coda token _is_ already a global identity in
> the geographical sense.  It allows you to enter and travel within a
> Coda realm according to your identity.

The token is useful only in connection with the
"file service of the realm that issued the token"
and meaningless for anything else (like login, print, ftp, ...)

(Think you'd need a passport issued by _Sweden_ to be able to enter
Sweden. Moreover, valid only for making credit-card purchases in certain
shops, but not in the others, and neither valid for entering discos!.. :)

As a side note, some countries put identification information (like
a photo) in their visas, going that direction - to use their own
"authentication authorities", not trusting the passport issuer.
It is like asking to enter two passwords... :)

> Also note that national passports are _not_ identities in the sense
> that a computer login is an identity.  If you fake my passport, you
> can travel from one country to another as me, but you will have a hard
> time accessing my bank accounts or giving grades to my students.  By

I consider three entities being present in each authentication act.

- the service provider
- the identity name (a character string as a common special case)
- the authentication authority who can distinguish between
  holders of the identity and vice versa

(a) For a beginning of a login

- login process (running /bin/login) as service provider
- a character string as an identity name
- NIS server as an authentication authority, supplying the password hash
  to verify the corresponding password against

--- login process is convinced about me being that name, by NIS

(b) For a Unix process started by login program

- kernel as a service provider
- a numeric uid and several gids as the identities' names
- login program as the authentication authority
  as it knows for sure that process really is to be those uid/gids

--- kernel is definitely convinced about the process being that uid/gids,
    by login

(c) For a bank transaction

- kernel clerk as a service provider
- my first name, last name and account number as the identity name
- bank notes about what my signature looks like as the authentication
  authority

--- the clerk is convinced about me being the person who owns
    the money, by comparing my signature to a securely kept sample

(d) For a border pass check

- the officer as the service provider
- my name and citizenship as the identity name
- my home country population registry, via a reasonably protected excerpt
  (the physically present passport) as the authentication authority

--- the officer is convinced about my name and citizenship,
    by my home country's population registry

Note that all of the above examples are pure authentication,
with the purpose to be used at a later step, for authorization:

a - check if "pin" is allowed to run a process on the given host
a - check which uid and gids he is allowed to be

b - check if the process can open or modify a file
b - check if a process may use as much memory or processor time

c - check if I am allowed to move money, limited by the account rules
c - check if I may access my son's account

d - check if I am listed as a terrorist... and then may not enter
d - check if the citizens of my country may enter

> contrast, in most cases once you are authenticated on a system, you
> get "all the honors and privileges appertaining to the degree" as my

Do you really see a contrast between the examples above ?
I hope they illustrate what I was thinking about.

I'd like to give, say, a login process at site A an identity name
ensured by site B, so that the login program would
painlessly and securely verify my proof via B -
independently of what A and B are.
Independently also of whether it is login, print, file or other service,
of course.

It is possible only with purely global identities namespace, and with a
corresponding protocol suit and software.
Coda tokens are surprisingly suitable for the purpose.

Going back to Coda, think we'd work together on a project :)
Then you could just add "pin/dce_at_chalmers.se" to some Coda group
or ACLs to let me access the project files in your realm.
No need to create an account for me, send me a password and so on.
(of course, then you'd have to trust Chalmers DCE security -
hope you would :)

> very careful about analogies to "real world" constructs like passports
> when talking about authentication on computer systems.

Still I think I am careful :)

Regards,
--
Ivan