Russ Allbery <[EMAIL PROTECTED]> writes:
>> I mean, you can self-sign a certificate and give a paper copy to
>> somebody at a conference -- all without having to lease a server that's
>> "always-on".
> In that case, the person to whom you're handing the certificate and who is
> verifying that you are who you say you are is the authentication service.
Yes. One facet of what I'm getting at is that users should be able to
use face-to-face interaction as an authentication mechanism if their
AFS admins wish to allow that in their cell. Right now there is a
technological barrier to this policy option.
> What it sounds to me like you're saying is that you want to grant access
> to your AFS cell (authorize) people for whom you have no traditional
> authentication provider.
Exactly! Especially in the case where traditional implies "on-line
available 24x7x365".
> But you're still going to be doing authentication (and therefore
> identity management, since you want your authentication system to
> satisfy certain identity binding requirements which will require at
> least some form of identity management).
I agree. I think the really tough hurdle I'm trying to get over here
in this thread is if OpenAFS is willing to accept use-cases where the
task above is delegated outside the sphere of the "AFS software suite"
(OpenAFS, Kerberos, and various extensions to Kerberos).
In particular, this use-case works much better if support for it is
ubiquitous ("on by default") in the client (but of course "off by
default" on the servers). This way users from "integrated" cells can
participate in "non-integrated" cells while still keeping the admins
of their home cell happy.
- a
--
PGP/GPG: 5C9F F366 C9CF 2145 E770 B1B8 EFB1 462D A146 C380
_______________________________________________
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info
