*MACE-Dir Conference Call* September 30, 2002 *Participants* Keith Hazelton -- Wisconsin (chair) Rob Banz -- UMBC Tom Dopirak -- CMU Chad La Joie -- Virginia Tech Bob Morgan -- Washington Steve Olshansky -- Internet2 Bob Talda -- Cornell David Walker -- UCOP Steven Carmody -- Brown Nate Klingenstein -- Internet2 (scribe) *Discussion* NMI Release 2 Keith took the first part of the call to reach satisfaction with the documents that MACE-Dir and its derivate subgroups would be contributing to NMI-R2. Subsequently, he wanted to bring the list of documents to the MACE-Dir mailing list for a comprehensive blessing for public release. The documents reviewed on the call were seen as appropriate and cohesive. A few improvements were suggested, such as adding a change log to all documents and making a concerted effort towards avoiding placing references between documents to make them too heavily interdependent, given that consistent reference is difficult throughout a group of documents edited and published independently. [AI] There was a lack of consistent boilerplate language to preface documents, which Keith offered to write. Another challenge is performing as broad an external review as is possible and useful. SteveO suggested that if documents going into a more final state will be included in NMI-R2, there should be a more significant and broader airing of them prior to their inclusion. Keith argued that we've cast our nets as wide as possible given all the implicit restrictions, and gotten a fair amount of feedback. One option he suggested was searching out particular groups which may provide particularly important feedback and sending personal letters inviting their thorough review and comments. Inter-institutional Course Attribute The bulk of the call was spent evaluating what Keith called the group's "hopes and fears with regard to information about people's enrollment in courses in an inter-institutional setting." Steven briefed the group on some discussion that had already taken place on the MACE-Shib design calls, which looked at the idea of a Shibbolized version of WebAssign. The desired flow would be for a student to visit a course page at a university, click on the WebAssign link, and the attributes presented by Shibboleth would include something to indicate which course they were working on currently. The solution would need to allow for the distinct possibility that a student would be in multiple courses that use WebAssign in the same semester. Bob expressed his surprise that this is a problem, because WebAssign has been identifying UW NetIDs with classes all along, so there has to be some collection of manual and automatic means to provision these resources. Things can get ugly, however; OSU is part of OhioLINK, and individual professional schools can maintain different contracts from the core campus. Keith made the broader observation that "if you turn over a big rock, you see lots of big bugs. Turn over a little rock, you see lots of little bugs." The recognition is growing among identity providers and institutions that Shibboleth is opening up ways to structure these contracts with much better granularity, but the process may be painful. Scott Cantor from OSU made a comment on that call that, although these strings may look a lot like the opaque strings for eduPersonEntitlement, it was his sense that a different attribute should be used so that apples and oranges aren't mixed and it becomes possible to map backwards (transparency, as opposed to the opacity of eduPersonEntitlement) if need be. [AI] Steven offered to ask the participants in the pilots how necessary a specific course attribute really is. On the Wire? The way that course membership is represented in the directory is highly variant, based on the directory product, vendor, group type (e.g. static, dynamic), and general deployment style. Perhaps more challenging is the difference in course nomenclature and numbering between institutions; Physics 101 may not even exist at some institutions. Because of these inherent differences, there was a sense that it is much easier to define common ways to represent course attributes on the wire rather than in the directory. Shibboleth is capable of handling most of the possible implementations of this mapping, in that the origin can evaluate and create attributes arbitrarily and send either a bucket of attributes or a simple boolean that represents an origin-side evaluation of eligibility. It is widely expected that both approaches will be widely deployed, at least initially, since the resulting burden of work, privacy, and legality is significantly divergent. FERPA rules will likely play into this conversation as well, including the law of three: any attribute that is applied to a group of three people or less is considered personally identifying information. At the same time, there could be the aggregation and collection of course data generation methods. It can be presumed that there will only be so many widely-deployed flavors of course management, and that answers for one institution can be applied to others with relative ease. This could lead to something of a contrib directory for a course attribute generation system for Shibboleth, but is still well beyond what MACE-Dir does currently. Keith thought some people might be a bit nervous if MACE-Dir went in the direction of trying to define how things are supposed to look on the wire, and professing ambivalence about whatever the directory representation is. This represents an exponential scope jump which Keith tabled for the time being, but which he wanted to return to on a later call. Still, it is virtually impossible to design a generic set of recommendations on how to make a group that works across all products -- and with the stated goal of interoperability, there has to be a mapping at some point between repositories that allows for a common understanding. *Action Items* 1. Keith offered to write a boilerplate for the NMI-R2 documents. 2. Steven will ask the participants in the Shibboleth pilots how necessary a specific course attribute is.