Subject: generalized permission for controls

From: Ellen Stokes <[email-masked]>
Date: Tue, 24 Jul 2001 15:08:31 -0500

Folks,

Mark Davidson proposed a generalized permission for
controls in his note dated July 6 on ACM permissions.
------------------------------------------------------------------------------
ACI = rights "#" target "#" generalSubject

permission = "x" ; execute control
; permission u can only be used on controls

target = "[all]" / "[entry]" / (attribute *("," attribute)) /
"[controls]" / (controlType *("," controlType))

controlType is defined in RFC2251

Control use - can use control where aci is active (this
replaces the g permission in a more general way)
-------------------------------------------------------------------------------

The authors like this idea and are working on text to
incorporated this into the draft and move the
getEffectiveRights control (and permission) in line with
this proposal.

We'll be putting a synopsis of this out shortly to the list.

In the interim, any comments?

Ellen

---

From: Bruce Greenblatt <[email-masked]>
Date: Tue, 24 Jul 2001 22:01:50 -0700

I would like to see this kept out of the main draft, and moved forward as a 
separate item.  I think that the rationale that is applied here should be 
similar to what was applied in my "application defined permissions" 
draft.  In actuality, I think that this is really pretty much the same as 
the mechanism that I defined in the draft: 
http://search.ietf.org/internet-drafts/draft-greenblatt-ldap-perms-00.txt

Bruce

>controls in his note dated July 6 on ACM permissions.

==============================================
Bruce Greenblatt, Ph. D.
Directory Tools and Application Services, Inc.
http://www.directory-applications.com

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 24 Jul 2001 23:14:31 -0700

I would suggest this be left out of the specification
and instead addressed by generalizing permissions
to grant access based upon a categorization of the
type of the access (read,write,...) being made as
opposed to the operation/sub-operation used to access
the directory.

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 26 Jul 2001 08:52:09 -0700

At 07:57 AM 7/26/2001, robert byrne wrote:
>This is a bit curt for me :).  Can you elaborate ?

"assert" allows assertion of values (compare, search filters)
"read" allows reading of values (search read)
"write" allows update of values (add, delete, modify, moddn)

We've discussed this before...  arguments pro and con
are in the archives.

Kurt

---

From: robert byrne <[email-masked]>
Date: Thu, 26 Jul 2001 16:55:59 +0200

Bruce,

I think there are some important differences between this controlType
idea and Application Defined Permissions:

1. ADPs are informational only, the controlType would affect directory
operations that had controls attached.

2. ADPs are motivated by considerations (however worthy) from outside of
LDAP.  The controlType is trying to address an extensibility that is
built into LDAP, namely the ability to define controls that modify
operation semantics.

Rob.

---

From: robert byrne <[email-masked]>
Date: Thu, 26 Jul 2001 16:57:26 +0200

Kurt,

Rob.

---

From: Bruce Greenblatt <[email-masked]>
Date: Thu, 26 Jul 2001 09:33:05 -0700

Even so, the mechanism used to define the permission is (essentially) the 
same as for ADP.  I also note that the control will be embedded in an 
existing operation, which possibly has other controls.   The interaction 
between the ACI for the operation, the ACI for this control and the ACI for 
all of the other controls is not defined by this.  I believe the 
interaction to be potentially very complex, and best left for a separate 
document.

Bruce

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 26 Jul 2001 17:34:47 -0700

At 09:33 AM 7/26/2001, Bruce Greenblatt wrote [trimmed]:
>I also note that the control will be embedded in an existing operation, which possibly has other controls.   The interaction between the ACI for the operation, the ACI for this control and the ACI for all of the other controls is not defined by this.  I believe the interaction to be potentially very complex,

I concur with this statement.

>and best left for a separate document.

I suggest we re-engineer the ACM to be less tied to the specific
operation used to access the directory and more tied to the
kind of access operations provide to the directory.

Kurt