Subject: Thoughts on the sasl plain authzid

From: Sam Hartman <[email-masked]>
Date: Sun, 27 Feb 2005 19:19:25 -0500

I find it helpful to think of things from a type matching standpoint.

The authcid is a mechanism-specific type and the authzid is an
application specific type.

If you have a mechanism mucking with authzid or an application mucknig
with authcid, then you are building the non-general knowledge into
either your mechanism or your application.  For a particular
implmentation that's OK, but we've decided in 2222bis that we will not
require that generally.  So if you are doing something that would
require all applications to know about an authcid or all
implementations of a mechanism to know about an authzid for a
particular application then you are going against 2222bis.  I think
the current text in plain probably crosses this line.

But somewhere you need a mapping from authcid_t to authzid_t to do the
default authzid logic.  How is that possible in a general framework?

I think that a general framework will need to have a
mechanism-independent form of authcids completely internal to the
framework.  So, the mechanism maps from authcid to frameworkid and
exports the frameworkid.  Then the application maps from frameworkid
to authzid.

In practice you'll probably do authorizations in terms of frameworkids
(particularly if they happen to be Windows sids or some general
concept like that) and so you'll only map authzids to frameworkids
when an explicit authzid is carried from the user to the server.

These are my thoughts at least for now.

--Sam