Re: increasing complexity - draft-ietf-ldapext-acl-model-08.txt

[Mark Davidson <markd@pwd.hp.com>]

I've been looking into the ACM recently and seeing some 
comments on -08 here are my thoughts.

> - instead of defining permissions which parallel LDAP
>   operations, define permissions based upon the type
>   of access being made.  That is, "write" permission
>   would be needed by subject to update a particular
>   target irregardless of what operation was used to
>   to request the update.

There do seem to be a lot of possible permissions now.
Either reducing them as Kurt suggests or perhaps grouping
them so that a client (or admin interface) writer could
simplify the interface would be good.

> - return to one ACI attribute and handle entry/subtree
>   semantics via target scope in the value.  This scope
>   would be more easily extended to support non-entry
>   and non-subtree scopes (such as one-level, children,
>   etc.).

The entry/subtree split is very useful for finding ACIs
that control more than one entry, which is very useful
for caching. Also it is quite a simple scheme, I would like
to keep it as it is.

> - remove all mention of ldapACIsubentry from the I-D and
>   generalize the out-of-scope statement to "prescriptive
>   ACIs and scoping via subenties is beyond the scope of
>   this document".

It took some time to understand what the draft was doing
with ldapACIsubentry, and I still do not see much of
a use for it.

> - remove ipAddress and DNS subjects as they require special
>   semantics (as well as for the security considerations
>   separately noted).

I would quite like to see these optional, but understand that
they are already in use.
 
> - remove authnLevel.  Don't add integrity/confidentiality
>   factors.

I liked the new 'buckets', the use of none, weak, limited and
strong would make an administrator think more about security,
while also allowing an implementation to assign specific levels
to specific mechanisms. authnLevel is security information that
the server has, and if it is used, it should be used all the time
as in -08.
 
> - don't require recursive expansion of roles and groups
>   (implementation complexity).

I can see that this is a problem in implementation, but recursive
expansion is what you would expect if you added one group to
another group.

Mark