MACE-Dir call
March 13, 2006

*Participants*
Keith Hazelton, U. Wisconsin - Madison (chair)
Joy Veronneau, Cornell U.
Tom Barton, U. Chicago
Mark Jones, UTHSC-H
Bob Morgan, U. Washington
Brendan Bellina, USC
Steve Olshansky, Internet2
Jessica Bibbee, Internet2 (scribe)

New *Action Items*
[AI] {Bob} will email the list with an informative sentence regarding an additional spec.
[AI] {Keith} will propose next steps for a requirements document around expression of permissions.

Carry-over *Action Items*
[AI] {Keith} will invite Leif Johansson to Internet2 Member Meeting and the MACE dinner. (27-Feb-06)
[AI] {Keith} will ask Bruce Barton to send his ref work to the MACE-Directory Group. (27-Feb-06)
[AI] {Walter} will send a URL to the list with Nexus code and documentation, as it is made available. (27-Feb-06)
[AI] {Walter and Tom} will collaborate on the development of a domain model.
[AI] {Steven} will write-up use cases on requirements for provisioning systems, and send to {Walter}.

*Discussion*
The eduPerson (200602) and SAML Attribute Profile documents have reached a state of last call before being handed to the MACE Working Group for approval. No major changes have been made, beyond typos.

{Tom} raised some concerned over where to house entitlement values – should it be in the eduPerson spec or in another document within the MACE space? {Keith} suggested that there should be a way to make a list official and have it documented, though he was not interested in having them included in the eduPerson document. {Bob} suggested having a separate document to pattern the conventions of how to construct values and when or when not to use them. [AI] {Bob} will email the list with an informative sentence regarding an additional spec.

{Tom} is working on the details that {Minh Nguyen} will code for the JNDI provisioning connector. This code will put Signet privilege and group information appropriately into LDAP directories, in a way that is easily recognizable and usable in a native LDAP form. The question is how to map the data most efficiently and conveniently. {Tom} and {Brendan} presented 2 varying methods for getting information from Signet/Grouper into other applications:

{Tom} suggested a "pass by value" approach, where for each subject that is assigned a limit, and for each limit declared in that permission, you would attach a subentry to that subject appearance in LDAP expressing that permission limit. The identifier of that subentry would then be a combination of subsystemID, permissionID, and limitID, which would uniquely define the permission assigned to that subject. An example of values for those identifiers would be library, purchase, and books – where the subject in this instance is limited to purchasing books for the library. Note that there may be a set of values for the limitID to choose from.

{Brendan} suggested a "pass by reference" approach, where the permission subentry is associated with the group, rather than the individual subject – thereby reducing the number of subentries. This approach necessitates the handling of groups, and is therefore less flexible. However, if changes are made to the subsystemID, permissionID, or limitID, it would only necessitate a change to be reflected in the group entry – not to the DN of each subject entry, thus greatly reducing the number of changes.

Both approaches agree that information needs to be accessible such that it is accessible by LDAP. In terms of adding subentries to groups in either approach, both offer the same scalability. Given that you use groups, as opposed to using only subject subentries, there are additional dimensions of groups management and maintenance to consider. If a group is moved, the associated subentries would have to be moved with it. This would necessitate an information management infrastructure to be in place. The actual naming of the groups is not so critical, as there would exist at least one group per permission.

Another difference to explore is how searching would be accomplished in either approach.

There are three main perspectives that these two approaches should aim to serve: 1) person trying to get Signet/Grouper into directory interface (Application developer), 2) Person managing the directory, and 3) Person trying to retrieve the information. This discussion led to a possible need for a Sources of Requirements document. Actual trials with both methods will be the only way to establish which is preferable. Next steps are to work up the code and see it in operation. [AI] {Keith} will propose next steps for a requirements document around expression of permissions.

How would populating the isMemberOf attribute add effectiveness? This would add ease to performing queries, though it would not be necessitated. It would also require maintenance of the binding between the EduPermission group object and subject (that has been assigned the privilege.)

The next MACE-Dir WG conference call will be on Monday, March 27, 2006 at 4:30pm ET.