*MACE-Dir Conference Call* June 25, 2001 *Attendees* Keith Hazelton (chair) - Wisconsin Tom Barton - Memphis Renee Frost - Michigan/Internet2 Michael Gettes - Georgetown Ken Klingenstein - Colorado/Internet2 Ryan Muldoon - Wisconsin Todd Piket - MTU Nate Klingenstein (scribe) - Internet2 *Discussion* - DoDHE - DoDHE has recently made a great deal of progress. The technical parts of the directory are reaching completion. These components are now fairly well understood, and many of them have already been implemented, allowing for several test queries to have been run recently. The detailed DoDHE architecture has been posted on the Internet2 web site (http://middleware.internet2.edu/dodhe/), and Michael would appreciate any comments or evaluations. The far more difficult facet of DoDHE, common to an entity in the Shibboleth architecture known as Club Shib and to most other inter-realm applications on the horizon, is the political. These political challenges are detailed later in these minutes. Currently, DoDHE has several components of its engine functional. The main program used in this effort is a directory tool known as Metamerge. Several of the participants "know enough to begin to hurt ourselves and others" using Metamerge, building a bed of expertise that should prove invaluable as DoDHE aims for implementation. A config file has been written that runs raw LDIF output through Metamerge, filters out entries based on flag values (such as member of community, active, or person), and extracts all the pertinent eduPerson data for a new LDIF file. This information may then be sent to the DoDHE repository at Georgetown via the HTTP PUT protocol, but PUT is currently non-functional in the Metamerge system. Upon being contacted, Metamerge responded that this functionality should be implemented soon. Other possibilities such as mutually-authenticated SSH or other connections are still being considered. In testing, this configuration cleansed the Georgetown directory data from 98,000 entries to 18,000 visible entries, which is approximately the number of faculty and staff that is visible to anonymous viewers. These numbers will not always be precise due to people declining release of information under FERPA and users who have multiple public user IDs. Michael would wager that the number of entries will always exceed the number of members of an institution, but not to a great degree. A generic assembly line process is being designed to allow other institutions to painlessly build a similar query and relationship with DoDHE. The current web-searching interface is provided by a modified version of Netscape DSGW. The server-side part of DoDHE consists of a central deposit directory and another directory called DoDConfig that lists the organizations in DoDHE. The latter directory is formed of a part listing organizations and a part holding referrals which point to the location where directory information about that organization is stored. The central deposit directory stores the information for a school that does not want DoDHE to query it in real time, so the DoDConfig directory will point to an entry in the central deposit directory instead of the school's home LDAP system. To add a new institution to the directory, the name is first added to the list of organizations in DoDConfig. This directory is checked for missing referrals once a minute, and if an institution is found without a referral, this field is automatically populated. Slightly more configuration must take place to create the appropriate HTTP PUT mechanisms with username/password assigned to an institution so they can create their directory in the central deposit, but this is still relatively trivial. Michael is surprised by the number of components that are completed at this point and that the system is already functional. The search engine still needs to be rewritten and some parts of the system need to be tidied "under the covers", but there is a large amount done. There have also been several interesting discoveries along the way, such as realizations of differences in browsers and small kinks in the Metamerge software. Circulation of this new knowledge and of the promise and difficulties in the system could go a long way to begin to sell DoDHE and other inter-realm applications. - political difficulties - The outstanding question is: how does a school join DoDHE? Currently, most institutions do not have a system in place for inter-realm applications because these have been primarily small-scale in the past. This has led to solutions that do not scale but suffice for projects between a small number of schools. Now, however, as universities begin to join projects such as DoDHE and Shibboleth, it is extremely important to ensure that the school understands fully what it is doing and is able to participate well, for the sake of FERPA, consistent trust, and effective systems. Analogous to the inter-realm trust issues in the new applications themselves, when a request arrives to join DoDHE, how can one be sure that this request is authoritative and actually represents an institution, and that the institution can understand and provide the means necessary to join? There are makeshift solutions to this problem as well. An obvious way for a school to initiate joining an inter-realm club would be someone from that school submitting a request. This request could be forwarded to a CIO, EDUCAUSE representative, or similarly authoritative figure at the remote institution, but this could well be a bottomless pit chronologically as well as very difficult administratively. It would also be possible to denote these privileges in a directory, possibly in the eduPerson format. Still, this does little to educate the schools about wise practices regarding inter-realm trust, FERPA issues, and many of the vast number of quirks and difficulties these projects have uncovered as they've progressed through the inter-realm world. For the pilot phase of DoDHE, this may suffice due to the relatively small number of participants and the personal knowledge of the institutions. Ken believes that the general solution to these difficulties is simply to face them squarely and staunchly. In true dissemination and education about inter-realm issues, schools could begin to understand some of the common cautions and themes in these applications and design their own systems and solutions with a sense of understanding and participation. Although anything involving such difficult issues will undoubtedly prove contentious, a serious demonstration of the imminent possibilities once these problems are faced, an academic and open environment, and an effort to foster communication will serve to ease the difficulties, both immediately and in the longer term. Schools can work out their own internal considerations, then approach a broad inter-realm project with a firm comprehension of what they are entering into. To begin socializing and initiating the issue, Ken will schedule a BoF at Snowmass to begin this arduous process. He anticipates initial resistance, which is OK, but the pressing necessity of this implementation should prompt schools to seriously work to understand and participate in these efforts. - miscellany - MACE-Dir will soon start to discuss groups in much greater detail. It will consider static groups vs. dynamic groups, how groups should be implemented, how roles should be implemented, and how recommendations should be issued. There is nothing new in VidMid directory work, and video metadirectories follow the same concept as stitched directories. This entails a fundamental design decision on whether information should be plunked straight into eduPerson, or whether, as Michael thinks, this data belongs in an application-specific directory or schema which is magically stitched in. The continuing issues about synchronization of schema and data should be considered separately from the inter-realm problems. There is a need for a concise and clear statement of this problem space for a fruitful and productive conversation with whichever experts may arise on a directory advisory board. Bob Morgan's and Jeff Hodges's participation will be requested. The group also needs to be careful about the number of projects that are consuming the time of the participants and the calls. Many of these issues are on the horizon but don't loom immediately, suggesting wariness about what is coming but that no current panic is necessary. *Action Items* [AI] 25-June - Michael will write up a one-page summary detailing the challenges he is facing in creating DoDHE and documenting the interesting solutions he has already reached, such as caching improvisation and browser caveats. Ken plans to use this document to demonstrate the difficulty and usefulness of inter-realm work. [AI] 25-June - Ken will schedule a BoF at the Fall Snowmass conference to begin introducing CIOs and their ilk to inter-realm services. His feeling is that although resistance to inter-realm applications is inevitable, it is also surmountable if faced squarely. [AI] 25-June - Michael will develop an appropriate disclaimer for the DoDHE splash page; he will likely be asking the group for help with this task. [AI] 11-June - Keith will make a list of things to include in eduPerson 1.5.