*MACE-Dir Conference Call*
March 4, 2002

*Participants*

Keith Hazelton -- Wisconsin(chair)
Rob Banz -- UMBC
Tom Barton -- Memphis
Brendan Bellina -- Notre Dame
Steven Carmody -- Brown
Renee Frost -- Michigan/Internet2
Michael Gettes -- Georgetown
Paul Hill -- MIT
Richard Jones -- Colorado
John Kennedy -- Internet2
Bob Morgan -- Washington
Todd Piket -- MTU
Ellen Vaughan -- Internet2
Nate Klingenstein -- Internet2(scribe)

*Discussion*

Affiliated Directories

         The group opened the discussion on affiliated directories by 
reassessing the types of scenarios in which this capacity would be used. 
Rob contributed a completely generalized, ideal description of the ideal 
affiliated directory, but several more immediate scenarios may help to 
drive progress towards that eventual goal.
         Bob suggested using an address book as an example of one 
situation where affiliated directories would have quick and useful 
application.  He imagined that eventually updates of the information 
regarding individuals in an address book could automatically be 
repopulated by an affiliated directory.  This is a sort of subscription 
to events in others' directories and is a push mechanism.
         Another example put forth by the group involves maintenance of 
directories of PI's or grant writers by government agencies.  These 
institutions are more likely to trust institutional directories than 
their own sources, given the challenge of keeping so many data recent. 
Creation of a persistent process to either push or pull a set of 
selected data from an institutional directory to the central 
administrative directory would simplify the process.
         There are many questions surrounding this scenario; if a 
researcher were switching universities, how would this be reflected and 
propagated in databases?  How can certain data be identified as more 
recent or accurate? If there are multiple entries for something like 
phone number, which is chosen?  Perhaps most pressing is the issue of 
matching identities.  The group resolved to hold another mini-conference 
call to discuss scenarios in greater detail, and [AI] Bob will try to 
find time to develop a couple starter scenarios from which the group can 
work.

Identity Matching

         Before a metadirectory or affiliated directory can be useful, 
it's imperative that the principals of queries and attributes be made 
unique and be matched to one another in disparate directories.  Problems 
often arise both with duplicate identities for single individuals and 
with improper or inaccurate mappings of data files regarding individuals 
to one another.
         There are a few current approaches to minimizing the scale of 
this problem.  One method is to implement a federated administration, 
allowing a directory to refer to a remote entity with a remote 
identifier, but Bob pointed out that this really only defers the 
problem, not solving the question of whether two identities are, in 
fact, the same person.  Some of the more distant suggestions were to use 
MD5 hashes of social security numbers as unique references to people for 
directory entries and implementation of a broad, end-user PKI, but this 
is a politically sensitive and slow-moving space.

eduPersonRDN

         A subject with many opinions, the group tried to address the 
ways that one entity can or should point to another entry in another 
repository. This sort of pointer needs to be globally unique, and Keith 
expressed an interest in retaining the left-hand side of the attribute's 
location and, if possible, some of the geography of the tree.  A normal 
DN often can't be used for these purposes because some of the more 
significant components of the DC naming might not correspond to 
eduPerson or any other common standard schema.
         eduPersonRDN is intended to be a non-indexed attribute to help 
make the DN more portable.  This value can be anything, not just a 
number.  It is intended to allow the directory designer to avoid 
overloading the CN or any other common attribute which are normally used 
and are generally indexed.  It would not be required in any way, but 
would provide the ability for eduPerson implementors to make DN's more 
portable if it were desired.
         The more profound question is whether the group really believes  
using DN's as the way to refer to things is a good practice.  The debate 
is really almost moot at this point, given that DN's are a very commonly 
used approach to this problem, and it will be important to support this 
ability anyway.
         The necessity for such an attribute was also discussed, with 
the most immediate need in practice being porting entries from the 
University of Colorado's institutional directories into DoDHE, which 
would have been greatly facilitated by such an attribute.  Keith 
wondered how often it would be that a whole entry would be ported around 
anyway, but the group concluded that even if the immediate use cases are 
not pressing, the existence of the attribute allows for many interesting 
opportunities in the future.

*Action Items*

   1.  Bob will try to find time to develop a couple starter scenarios 
from which the group can work.