>>>>>> "Ivan" == Ivan Popov <pin_at_medic.chalmers.se> writes:
>
>     Ivan> You still manage authorization (of course) but can use
>     Ivan> existing authentication services transparently, for any
>     Ivan> service being offered to the end-user.
>
> Sure, but what good do these authentications do?  AFAICT the main
> purpose would be to track behavior so you can monitor the people you
> are authenticating.  If the downstream host is going to provide
> different privileges to different IDs authenticated by the same
> service, they effectively need to create accounts for them anyway.

It depends on what you call an "account".

In Un*x world authentication and authorization is confusingly mixed
together (like /etc/passwd containing both password hashes -
authentication - and list of allowed users - authorization),
and it may be the reason you use the word "account" which also
traditionally implies both of them...

> So authentication really is about protecting the authenticator, and
> (given the real-time tracking ability that computers give) has
> worrisome implications for privacy if you ask me.

Ok, I understand your worries. See, the model I propose
does not in any way enforce _one_central_ authority, it just gives
a service provider the freedom to choose which ones to trust and use.

The users may also choose which ones and for which purposes they use.
_May_be_ they will prefer a provider who maintains his own authentication
database and hence does not leak the privacy information...

> I would say SSH _is_ an authentication service that happens to also
> provide remote login and remote file access as typical applications.

Huh? How can I use ssh to verify authenticity of a client for some
other service than remote login? Say music distribution over http,
to name one...

SSH (once again as usual in *nix :) implements authentication means
(say public key check) _inside_ a remote login service.
It does not export the authentication via an API or via a feasible
protocol.

You could of course hack a "pam_ssh" module that would try to run
an ssh session against some host and report if it succeeded.
But then it would be essentially just exporting the authentication means
found at that host, via remote login protocol...
And that protocol is not really suited for the task.

> environment="CVSUSER=<xemacs-cvs-id>",
> command="cvs"
> <keyinfo>
> <real email address>

> Note that if you change the command to /bin/true, this is effectively
> pure authentication.

I see. You are maintaining your own authentication database,
again combined with authorization one.

Authentication database consists of the SSH public keys,
and the authorization information is expressed by the command,
which tells which operations are allowed for the owner of that key.

You are not using any authentication service, you are
maintaining your own key database. You cannot simply state
that "pin" is allowed to "cvs" but "stupidone" just "echo RTFM".
You have to keep the _keys_ for both.

The information that binds "pin" to a person has to be present somewhere,
now it is _you_ who keeps it.

In contrast, I can let people use my Coda realm, without keeping
their keys or photos. I am just listing "someone" as allowed to modify
certain files - and the Coda server checks if the person _is_ "someone"
by asking the Chalmers DCE cell.
I have no power over the DCE cell, but I trust it for my purposes.
It _is_ an authentication service.

Hope I made my point clear:

An "account" is a set of privileges.

Traditionally it is thought as containing a certain "authentication key",
which is in fact very misleading.

That tradition puts the burden of maintaining the authentication
keys database on the service provider (who manages the _privileges_).

In contrast, an "identity" is just a named "authentication key".

It can be associated with some privileges _in_some_context_,
forming an "account".

The main idea is to define a global name space for identities,
so that different kinds of authentication keys and databases
can coexist and be available for many contexts
- then we get the freedom to manage access rights independently of
authentication.

Coda can both profit from a consequent identity model
and as a side effect provide an unique authentication infrastructure
for other services.
As said, just one new RCP2 operation would be needed (and of course
some reasonable xor-replacement, too :)

My couple of cents,
--
Ivan