*Participants*

Keith Hazelton -- Wisconsin (chair)
Tom Barton -- Memphis
Brendan Bellina -- Notre Dame
Scott Cantor -- OSU
Jeanette Fielden -- Internet2
Renee Frost -- Michigan/Internet2
Shelley Henderson -- USC
Bob Morgan -- Washington
Steve Olshansky -- Internet2
Barry Ribbeck -- UTHSC-H
Bob Talda -- Cornell
Ann West -- EDUCAUSE/Internet2
Nate Klingenstein -- Internet2 (scribe)

*Discussion*

Entitlements and Roles

Keith opened the call by describing the eduPerson attribute eduPersonEntitlement as previously being thought to represent the right to access a resource. This is now too narrow a view, in that it doesn't consider the access to a resource in a particular role. For example, while an entitlement might express the right to access a given resource, it doesn't distinguish between accessing it as a student or as a faculty member. Tom expressed his belief that this is clearly within the scope of MACE-Dir's work, as it deals with designing how information is stored.
The solution of passing an entitlement and an affiliation is incomplete, because there is no way to perform the algebra on two different attributes to come up with a single set of permissions. For example, expressing "access to resource B" and eduPersonAffiliation does not handle the case where one individual is a T.A. in one course, but a student in another. This is, as Scott put it, an "absolutely classic many-to-many case."
This sort of attribute -- "entitlement A in situation B" -- is very difficult to express in an LDAP directory. The various tricks used to stuff additional information into a single string don't suffice. It's clear that the Shibboleth AA is capable of addressing this; it can factor in a role, a target, and an identifier, and send them off in some sort of appropriate bundle to the target.
In the database world, there would be a table constructed with a courseID or other identifier routed in, and a role routed in, and would express through this union the concept of "this role, this course." There may be the need to include a persistant identifier here if it is a learning management system, for example, which would also have to be factored in. It is clear directories don't handle this functionality out-of-the-box.
Tom even suggested there may be some broader work to be done in the redefinition of the data model used by institutions. There may be discussions to be had in terms of standardizing the implementation of the storage of information in alternative situations and an appropriate parcelling of data according to the most appropriate system.

Strings vs. XML

Turning to another classic problem, the group started to wrestle with the appropriate form for the expression of complex attributes, e.g. ones including a scope or a role. Scott's "opening salvo is -- the limited extent that [he's] composed data into more complex XML has been met with resistance and disdain.... As inelegant as stuffing it all into a URI is, anything else is going to have its ugly points too." Though it is impossible to ensure adoption and there will be no standard, the specification of best practices here may serve to reduce pain.
While Shibboleth relies on the XML-based SAML standard for attribute assertions, it does not broadly take advantage of the expansible, structured nature of XML. There are only two attribute types Shibboleth supports out-of-the-box: simple, which is a plain string, and scoped, which includes a "Scope" attribute in the XML assertion. At some point with a web context, everything has to be stuffed back into a string anyway that can be mapped to a yes/no decision.
There is only one scoped attribute to date, eduPersonScopedAffiliation, which nobody has yet found useful for a single policy expression. Once a policy is written which reads, "this affiliation or this entitlement, you've just wasted your time on the affiliation," continued Scott. The primary use for this so far has been verification that the OpenSAML and Shibboleth code can handle this sort of assertion.
The simplest alternative, as has been put forth numerous times, is to simply use an @ symbol as, in Tom's words, "the relationship delimiter." The symbol is not reserved by RFC 2141, which defines the syntax of URN's. This suggests that if the first half of the string is a course entitlement, then the character denotes the following portion indicates the relationship of the individual to that course. This may need to be combined with a catalogue of how to break down entitlements; if there is a need to utilize pieces of a URN, there should be no assumption about how pieces can be treated given the informal nature if the definition.
This approach could lead to a serious increase in the number of entitlements necessary to create reasonable access control. It may also lead to the need to create an eduCourse object class to represent courses in the directory, a privilege Scott was happy to delegate to MACE-Dir.

localPerson Survey Results

Brendan has solicited comments from the original responders to the survey on the way their opinions and text were interpreted and written up, and is in the process of completing this. Pending the receipt of more edits from other survey responders, the document will be vetted with DirT before being included in the next NMI release.