*MACE-Dir Conference Call* January 7, 2002 *Participants* Keith Hazelton -- Wisconsin(chair) Brendan Bellina -- Notre Dame Tom Barton -- Memphis Steven Carmody -- Brown Renee Frost -- Michigan/Internet2 Richard Jones -- Colorado Bob Morgan -- Washington Todd Piket -- MTU Ellen Vaughan -- Internet2 David Wasley -- UCOP Nate Klingenstein -- Internet2(scribe) *Discussion* Discussions in the last call about contact information led the group to believe it was important to include "blue pages" information in eduOrg which contained several important business points of entry. The entry point for conversation was an old e-mail of David's which proposed several attributes for public contact information. As an entry point to eduOrg itself, Keith mentioned making a "friendly amendment" to DoDHE to have pointers to eduOrg's in a fashion intelligent enough to allow users to access the information they needed. This could potentially include a search engine which could perform automatic queries for information in eduOrg's across schools. Contact Information The biggest discussion within the group was what form contact information attributes should take. An obvious choice would be to include an attribute for each item of contact information. Some felt that it overloaded the eduOrg object to include all of the contact data -- many of which were deemed important -- as separate attributes. The other option was to include a single contactInformation labelled URI attribute which would contain all the data. Bob mentioned that he had always found labelled URI's to be an odd thing, since it's a syntax, not something obvious like "Mail" or "Phone", stating only that there is a URI inside. More opinions were voiced. Tom thought that using this as a labelled URI was cleaner, with the ease of multivalued attributes. David's general preference was to have something which could be unambiguously searched for, which he felt could be much more easily accomplished if there were individual attributes with tighter definitions. There was also some question about how well labelled URI's are displayed in conventional browsers to evaluate how useful they would be. [AI] Todd offered to toss some URI's into his LDAP entry, and other group members offered to test it with a few common browsers. Sensitivity was also expressed for overloading the schema such that there would be thousands of sparsely populated and used attributes. Another concern of the group was the generality of the proposed attributes, citing that contact information such as registrar would make little sense for eduOrgUnit objects. Some universities also have multiple instances of the same office which would make population of a generic, searchable field in a meaningful way challenging. Each of these challenges would be better handled by the relatively more flexible labelled URI approach. Another suggestion was expressed of representing offices using the eduPerson object class, but David was averse to the "kludge" because it makes offices look like people. Todd thought it would be a fine approach, likening it to a phone book where both types of entries are in the same tool. The group felt in the end that the benefits of the labelled URI attribute format outweighed the problems and that, if no significant problems were presented with the display and use of this attribute format in common browsers, it was preferable. Naming and Usage These names were suggested for attributes, whether they were bundled inside a singled labelled URI or individual attributes in eduOrg, and are largely self-explanatory: eduOrgRegistrar, eduOrgITSecurity, eduOrgCampusPolice, eduOrgHumanResources, eduOrgPublicRelations, eduOrgBusinessServices, eduOrgDevelopmentOffice, eduOrgAlumniRelations, eduOrgAdmissions, eduOrgOperator and eduOrgLegalName. There was a suggestion to ask the information office at local schools which numbers were most frequently called, and which they would like to have automated versions of available; the group mentioned that athletics received more calls than most, as did the library. These would all be put inside a labelled URI attribute named "eduOrgFunctionalOffice", possibly having had eduOrg sheared off the front of them, which would contain these defaults and could also have additional defined attributes at institutional whim. David was concerned that a hypothetical East Wazoo State would see this and place an entire blue pages in the labelled URI, and more particularly about how a cross-institutional search engine such as DoDHE would represent and use all these data. The same issues about subdivisions and eduOrgUnits were raised again but the group unanimously agreed that, given the structure of things in higher ed, this would not be an issue to be solved in eduOrg 1.0. Shibboleth and eduPersonEnrolledCourse Shibboleth routinely turns up the need for an attribute to express the courses an eduPerson is involved in for access control management purposes in a standardized way. There are real pilots in formation which could use an attribute like this if it existed. This would be a multivalued attribute and the group would not worry about creating a controlled vocabulary, making it unique by use of URN's or some similar scheme if necessary. The group had several initial concerns. It was cited as extremely difficult to try to classify, codify, or otherwise standardize the naming or meanings of course names across institutions. Creating an access control list such that only students in a particular class could get access to a website would be difficult and require prior bilateral discussion, but broad definitions such as allowing students in a particular class from multiple institutions will prove implementationally challenging. There is no standard vocabulary suggested at present, but this might be engineered in the future. Another challenge with this attribute is that it would ideally not be generally visible, given that this is particularly sensitive information which could be used variably for bad ends. Instead of assuming or pushing this attribute as one that sites should populate, use, and make visible, the group suggested it might even be a general push towards protection of this information. Shibboleth also needs a method developed for population of an attribute element as defined by the XML schema postulated by SAML, which includes a name, namespace, and a value. Michael was worried that this would require parsing the value of the LDAP attribute, which he sarcastically called "always a lovely thing to do." Population of eduPersonEntitlement continued to puzzle people. [AI] In light of all this, Steven offered to orchestrate a significant discussion of attributes and Shibboleth. *Action Items* 1. Todd offered to toss some URI's into his LDAP entry, and other group members offered to test it with a few common browsers. 2. Steven offered to orchestrate a significant discussion of attributes and Shibboleth.