However, it is much harder to map "name" to "cn, sn".
Why can't this be a UI thing? Why does it have to be
declarative in the ACL syntax itself. It will be nice if it
can be supported but I don't see a big reason ...
thanks,
/prasanta
hahnt@us.ibm.com wrote:
Jim,Good question!
I know that implementing access control such that attribute inheritance were taken into account would definitely be harder, but I feel that attribute inheritance SHOULD be considered during access control checks.
Thus, if some entity is granted read and write privileges to 'name', then they should be allowed the same privileges to 'cn', 'sn', and 'cn;lang-en'. (unless overidden by another permission that disallows such access).
Regards,
Tim HahnInternet: hahnt@us.ibm.com
Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)
phone: 607.752.6388 tie-line: 8/852.6388
fax: 607.752.3681To: <ietf-ldapext@netscape.com>
cc: "Duane Buss" <DBuss@novell.com>
Subject: Considering Attribute Subtypes during ACL evaluation
Are attribute subtypes considered when calculating access control information? In other words, if I have read permission to the "name" attribute, does that automatically give me read permission to sn, cn, givenName, etc?
I can't find any coverage of this in X.511 or the latest ACL draft. Due to the lack of anyone talking about it, my assumption is that, no, permissions do not flow down attribute inheritance chains, they must be explicitly stated for each attribute.
Of course with LDAP, this brings up the question of whether they apply to attribute type options. It seems to make sense, under most circumstances, to apply them in this case. Oh, what a world - what a world.