AuthzIDs or DNs, but not both

["Kurt D. Zeilenga" <kurt@boolean.net>]

It appears to me that the authzIds-are-not-necessarily-DNs
notion will cause a ripple of change through the protocol and
information model.  The introduction of authzid
representation [AuthMeth] will lead to creatorsAuthzid,
modifiersAuthzid, memberAuthzid, and many other use of DNs
to be replaced with something that can contain both an
authzId.  I believe the addition of authzIds will
unnecessarily complicate the protocol and information model.

It may be appropriate to consider other alternatives which
would not have a ripple changes through the protocol and
information model.  In particular, I suggest we consider
introducing a DNs-may-be-authzid notion.  Such a notion
(which one could argue that this already exists) would allowed
us to leverage existing protocol and information model.

I suggest we formalize a mechanism for mapping non-DN
authorization identifiers onto DNs and allow BOTH clients
and servers to use these DNs-can-be-authorzids DNs
whereever DNs are used today.

I would suggest that either new attribute type, authzid,
be introduced (or that uid be reused).  The authzid (uid)
attribute type may contain any authorization id and be
used as a naming component of a DN.  The authzid "u: kdz"
would be mapped to the DN "authzid=kdz". This authzid DN,
like any other DN, could be used where ever a DN can be
used today.  Besides use with new SASL mechanisms, it can
be used with simple bind.  It can also be used with other
operations and controls.  The server can also store this
DN whereever it might need to.  The server may make the
entry associated with these DNs inaccessible by clients
if it so chooses, that is, it can pick and choose which
operations it allows upon such DNs (as it can do with
any DN).  Some servers may only allow binding with such
DNs, however, some servers may allow a variety of other
operations upon the entry named by these DNs.

I have experiment with extensions to simple bind which
allowed clients to specify DN like "uid=kdz" and the server
would map these onto another namespace (in my case, a
"fully qualified" DN).  However, from this operational
experience, I believe such an approach can be generalized
to support specification of non-Directory
authorization/authentication principals.

Kurt



----
Kurt D. Zeilenga		<kurt@boolean.net>
Net Boolean Incorporated	<http://www.boolean.net/>