*MACE-Dir Conference Call*
August 19, 2002

*Participants*

Keith Hazelton -- Wisconsin (chair)
Rob Banz -- UMBC
Brendan Bellina -- Notre Dame
Renee Frost -- Michigan/Internet2
Jeremy Frumkin -- Arizona
Michael Gettes -- Georgetown
Bob Morgan -- Washington
Steve Olshansky -- Internet2
Bob Talda -- Cornell
David Walker -- UCOP
Nate Klingenstein -- Internet2 (scribe)

*Discussion*

Affiliation -- Application or Middleware?

         Keith opened the call by asking whether affiliation should 
be a process that takes place at the application or at the directory.  
Disagreeing with the phrasing of the question, Bob Morgan wanted to 
clarify his views on affiliation, in that the one application scenario 
that was presented on the August 5 call would be application-specific.  
He didn't see the performance of affiliation at the application or 
directory level as mutually exclusive, and suggested that each 
functionality would be desired by some applications. Providing 
information should be flexible enough to support either approach, 
ideally.
         It was his view, however, that directories should generally 
appear to applications as "monolithic" -- that is, a directory should 
be an authoritative, single repository if possible.  This view is tempered 
with the reality that there will usually be distinct directories in 
existence that provide distinct information about the same principal. 
For example, on a campus, there may be a person object maintained by 
central IT, while a medical directory contains much more information 
about the individual.  The aggregation of this information will be 
necessary for some applications.
         If the application itself can be expected to perform the 
affiliation, this is generally a simpler model from an implementation 
standpoint. On the other hand, if we envision the world as eventually 
having affiliation performed on a routine basis, then it would be good 
to build at least some support for this functionality into the 
infrastructure itself.  This would likely entail some means of building 
this representation into the directory, and a unique identifier or 
something similar to demonstrate to the application the origin of the 
information if the application so requests.  As a net sum, Bob suggested 
that if the group thinks at least some of the affiliation could be 
performed by the application, then a standards-based way to perform a 
little help from the infrastructure and directory could be in order. 
Bob believes that this is a more flexible, powerful, and useful model 
than strictly differentiating between middleware and the application.

Scenarios

         Drawing on the wisdom that Bob Morgan offered the group, 
Brendan attempted to posit a set of scenarios that would be a real-world 
analogy to the way an affiliated directory might work alongside an 
application.  If Brendan needs assistance getting his computer to work, 
he can ask someone at his local department, who will refer him to Joe, 
Bob, and Mary, and with the knowledge accumulated in conversations with 
them, he can probably get enough information to get up and running.  To 
avoid forcing Brendan to do this in the real world, however, help desks 
have been invented to provide a central point of reference.
         Bob suggested that, in real life, both methods of aggregation are 
performed, and the application (Brendan) chooses the best way.  Brendan 
reasoned that it's "incumbent on us directory types to approximate the 
institution-level help desk as much as possible."  A logical extension 
would be reasonable to include inter-institutional help desks for 
information that is well-organized and persistent.  However, there will 
inevitably be situations where nobody has the time, money, etc. to staff 
a help desk for certain resources, so it shouldn't be impossible for the 
application to call around itself if necessary.  This suggests the 
question is less about the application than about the resource the 
application needs to draw upon.

So, Where Does This Leave Us?

         There have been a few efforts at the more basic ways to provide 
this lesser degree of assistance to applications.  One of the 
traditional ideas in the field is the X.509 knowledge reference, but 
nobody in the group was really familiar with precisely how this is 
intended to function, and it has not seen wide implementation.  There 
would likely be some more work to be done to dust them off and make them 
usable in practice in modern-day implementations.
         Bob cited a draft that has been kicking around the IETF for the 
better part of a really long time which discusses ways to locate LDAP 
directories using DNS SRV records.  The IESG had a large number of valid 
questions regarding how these mappings could be reliably made which 
don't look to be resolved at any point in the near future.  It's also 
not well-defined how to turn a DN into something useful for DNS. 
         Having data stored in a distributed fashion is probably a good thing 
in the end, reasoned Rob, citing data freshness and policy reasons among 
a large number of benefits.  It was unclear that there was any sort of 
narrowing of the set of architectural options beyond this, though.  It's 
no longer a question of picking one of the two options to move forward 
with, in the group's eyes, as much as setting both options in motion as 
feasible alternatives and providing enough information to applications 
that they can make wise choices.
         However, this is a step beyond just recommending the appropriate use 
of metadirectories, and will require some real work to make it happen. There's 
quite a bit of magic that isn't in place yet, and providing for both 
functionalities will only broaden the scope of any implementation. 
Specifically, inter-realm identity matching has not been solved.  Without 
necessarily having an individual do it, i.e. the Liberty Alliance model, 
there needs to be some way to either map objects intelligently or design 
a new system of references.
         Michael described the stitched directories document as the 5,000m 
look at the problem.  From there, broader extensions or more detailed 
functionality could be built on top of it.  Usage of heavily-modified 
border directories, a special application or similar extensive 
functionality in the infrastructure itself might be more difficult to do 
while maintaining a sufficient amount of flexibility for a wide range of 
applications.