*MACE-Dir Conference Call* February 18, 2002 *Participants* Keith Hazelton -- Wisconsin(chair) Rob Banz -- UMBC Tom Barton -- Memphis Brendan Bellina -- Notre Dame Scott Cantor -- OSU Todd Piket -- Michigan Tech Ellen Vaughan -- Internet2 Nate Klingenstein -- Internet2(scribe) *Discussion* Prior to the call, Keith circulated draft specifications for eduPersonEntitlement and eduPersonExtension, citing this as a good way to achieve closure on difficult issues. eduPersonEntitlement Brendan expressed his surprise that the spec would recommend differently on the issue of whether to use URN's based on inter- or intra-realm use of the fields. Keith mentioned he suspected we have significantly less influence over those instances, and there may sometimes be significant legacy reasons at some institutions to avoid that approach for intra-realm applications. When Scott was asked as a representation of the current app developer community which could use the fields, he noted that all Shibboleth really needs is a container for URI's. He couldn't offer more detail yet but mentioned more specific needs could evolve as Shibboleth nears deployment. The primary advantage cited by the group of URN's over URL's in this instance is that there is a line of authority in the URN; that is, if there is a conflict of some sort or a complaint about something, it is significantly easier to trace down a relevant authority using URN's than the relatively anonymous URL. The group decided to not prohibit any part of a URI, but to offer the preference towards URN's. Whether MACE would be willing to allocate URN:MACE:J-STOR or not remains to be seen. The other consideration the group will need to look at is whether these attributes should ever be considered parsable. Current eduPersonEntitlement definitions don't allow for a mapping, but is merely intended to be a unique reference to a specific entitlement known to both the asserter and recipient. The group noted that this may be one of the more difficult attributes, citing the asserter, resource, and contract to all be potentially variable. How to implement contracts in this format is as yet unclear. eduPersonExtension eduPersonExtension is intended to be relatively lightweight and easy to "play" with, for the purposes of testing various ideas. In Keith's preliminary proposal, a potential player would need to register with MACE initially. Alternatively, this restriction could be removed, so the group asked itself: is it lighter weight to go through MACE or alter the schemas of five sites to try out some idea? It was mentioned that once an arc is registered with MACE, anyone can play all they please with it. Registration is also useful to allow for things to graduate into true eduPerson attributes more efficiently. Entitlements, Resources, Users and Groups Scott keenly pointed out that the only significant difference between eduPersonExtension and eduPersonEntitlement is a semantic one. He said that it is logically equivalent to cite a set of people who are eligible under a certain contract to access a given resource or cite a set of people who are eligible to be members of a certain group. Being in a group is really an entitlement in and of itself, or, vice-versa, the set of people holding an entitlement are a group. The group mentioned that the difference between the two is almost analogous to an implementational decision for an enterprise directory between forward-referenced or top-down defined groups. The group didn't see a reason why either attribute should seem potentially different from the other from a relying party's point of view. This turns the discrepancy into something relatively unimportant for inter-realm considerations. Keith then suggested merging both attributes into eduPersonEntitlement, with a caption about why these were folded together. This approach helps to maintain the uniqueness of an entitlement, and to Scott, eduPersonEntitlement itself is something of a playground. [AI] Keith offered to send something to the group explaining why eduPersonEntitlement and eduPersonExtension were combined. Affiliated Directories vs. Metadirectories Keith started this portion of the call by asking, "in a really vague way, what do we mean by an affiliated directory? I'm interested in sharpening our sense of distinction between metadirectory work; such as, moving things from one directory to another, a repository, or something else." Most of the previous scenarios the group had operated on have been interactions between intra-campus directory services. [AI] Rob volunteered to write a document describing a potential understanding of affiliated directories to help define the problem space. Some of the suggestions on how to proceed included investigating how the authentication between directories could occur, creating standards for how data should get refreshed, what sort of mechanisms there need to be governing how often refreshes occur, etc. The distinction between metadirectories and affiliated directories was somewhat blurred, as well. The group thought that Shibboleth could give an example of how to handle metadata attribute architecture, such as who can see which information, who can modify information, etc. The group also brainstormed over what metadata would eventually be passed around, suggesting mechanisms and data integrity were two basic articles. A distinct and separate role for metadirectories was still carefully observed. eduOrg Keith wanted to check with the group whether any better name for the multivalued labelled URI attribute for eduOrg were suggested rather than a simple eduOrgOffice. This raised a series of questions about eduOrg. It was re-decided that the listed offices were not intended to be a controlled vocabulary. In addition to this, the group wanted to explicitly state that if an office can map to one of the default attributes, that should be used. This sort of standardization would prove extremely useful when compiling applications which autonomously utilize this blue-pages information. This sort of standardization can prove difficult and anglo-centric, however. Brendan thought it okay to standardize attribute name even across cultures, but frowned on restricting the values of the attribute which would need to be done for a multivalued URI entry. [AI] Brendan was asked to propose some way to better accommodate these concerns in eduOrg's eduOrgOffice attribute. Briefly, it was discussed whether the campus account management information could be included with the iTSecurity URI, but the group quickly decided that this would be overloading the attribute and recommended creating a new eduOrg attribute or including this as part of another object in the eduOrg standard document, outside of the eduOrg object class itself. *Action Items* 1. Keith offered to send something to the group explaining why eduPersonEntitlement and eduPersonExtension were combined. 2. Rob volunteered to write a document describing a potential understanding of affiliated directories to help define the problem space. 3. Brendan was asked to propose some way to better accommodate these concerns in eduOrg's eduOrgOffice attribute.