*MACE-Dir Conference Call* August 5, 2002 *Participants* Keith Hazelton -- Wisconsin (chair) Rob Banz -- UMBC Tom Barton -- Memphis Brendan Bellina -- Notre Dame Scott Cantor -- Ohio State Renee Frost -- Michigan/Internet2 Jeremy Frumkin -- Arizona Michael Gettes -- Georgetown Bob Morgan -- Washington Steve Olshansky -- Internet2 Todd Piket -- Michigan Tech Bob Talda -- Cornell Nate Klingenstein -- Internet2 (scribe) *Discussion* SAGE Discussions continued about how to proceed with development of SAGE. Some of the conversation focused on the use of groups to handle RBAC, and the potential use cases for something like this tool. Tom stated that SAGE is primarily intended to help delegated management of groups be a feasible practice on campus. Figuring out where to draw the line between a tool like Grouper to perform advanced group math and a tool like SAGE, and how these tools would coexist/interoperate, is important going forward. [AI] Bob Talda will assist Tom in writing some preliminary scenarios for SAGE. Liberty Alliance 1.0 & Stitched Directories Michael described stitched directories as the first step towards beginning to perform the sort of functionality implied by inter-directory exchange (previously known as an affiliated directory). It describes a means to automate the exchange of identifiers as a way of beginning to deal with the problems of mapping information from directory to directory. Michael stressed the importance of grabbing this rather large problem at the right point, and, while keeping an eye on the ideal eventual functionality, designing towards it at the right angle. As part of the eventual ideal functionality, the Liberty Alliance specifications were offered as an interesting standard. The Liberty Alliance provides a way to create informational vectors from one identity to another using persistent pseudonyms. Once an identity has been mapped onto another, information can be exchanged in that direction; mutual exchanges are performed using different identifiers in each direction. This allows for unilateral cancellations of mappings and a degree of privacy and anonymity. Scott astutely noted, however, that Liberty Alliance doesn't only allow the user to establish these mappings between individual identities; it relies on the user's ability to do so. While the Liberty specifications could eventually perform a sort of SSO functionality, it initially relies on neither side needing to understand who the user is on the other side because the user independently identifies to each. The Liberty Alliance specs take advantage of this to provide a pair of indexical references between directories. There is no similar user-driven identification in most directory apps and certainly not in most directory exchanges. Attribute Metadata Another problem that some believe must be solved before inter-directory exchange becomes a viable technique is that of attribute metadata. When an attribute exists in a strictly intra-realm sense, there are a set of assumptions that can be made about information merely given its existence in the directory; its origins, level of assurance, freshness, etc. can be generally assumed in the intra-realm case. Some believe that a set of attribute metadata needs to be sent with each attribute in an inter-realm exchange because these assumptions can't be made in an inter-realm model. An entirely different set of attribute metadata would concern information surrounding the transportation of the attribute itself. Some see the need for a sort of audit trail of where the attribute has been and how it has been transmitted. There also would need to be some sort of means to assert to a third party that this attribute had been created by and certified as accurate by the original administrative domain. Attribute Administration, Overlap, and Representation Michael gave the scenario where a directory at one institution wants to populate the CN attribute of another institution's directory. What happens if another authority wants to populate this common field as well, and perhaps differently? This is another one of the problems that hasn't come up yet in the intra-realm case because there is presumed to be a measure of direct administrative control over information population. Some on the call expressed their opinion that this was a relatively safe assumption to make on an inter-realm basis, while others thought it was an unreasonable expectation. In addition to simply maintaining intra-realm assumptions, a few possible options were mentioned. One obvious solution from a directory standpoint would be to put a CN populated by an external Georgetown directory in georgetownCN, reserving the proper CN attribute and other important attributes for intra-realm use. This may be of limited utility to applications, however. A theoretically and politically interesting concept would be the ownership of attributes in remote directories. Allowing a source directory to own attributes in a target directory would hypothetically provide an authoritative source for the data, protecting against overwriting and giving a definitive origin to track down data from, potentially simplifying some of the other problems. This leads down a very slippery slope towards inter-realm access control rules on attributes and fuzzy logic regarding who can overrule whom, etc. The group also threw in the interesting twist of ownership of a particular attribute/value pair only, and not of an attribute itself. While perhaps more theoretically accurate, this would be of dubious value to applications. Rob thinks that if officePhoneNumber is populated by multiple sources, leading to multiple attribute/value pairs, then these should be in the same attribute when merged and returned to the application as a functional goal. Attribute Transport There was a fair amount of discussion about how these attributes would be shipped around. The prevailing view was that it made the most sense to send these attributes using SAML attribute assertions, which provide means to transmit metadata as well as attribute information in an extremely extensible manner. Michael also suggested a new eduPerson attribute to help handle some of the attribute ownership questions. eduPersonAttribute would be populated almost as a URN namespace, in the form example.edu:attributeName:attributeValue. Inter-realm directory exchange sources would all generate this attribute, using this eduPersonAttribute as a means to scope and track the origin of the data provided in a simple way. The recipient directory could then utilize and massage this data in whichever manner was necessary. What do Applications Need? Bob Morgan wanted to return the group to scenarios, so Michael described the NIH scenario, where one central repository wants to maintain accurate and up-to-date person data from many different institutional directories. Bob's opinion was that this was mostly an application issue, and that if this needed to be done, an application would be written to perform the function -- nothing fundamentally different at an architectural level. To Bob, most of the so-called affiliation should occur in the application itself rather than at the directory level. He sees the only real value of stitching to be to a few specific, dumb LDAP clients that are unable to perform these tasks themselves, and are unlikely to need to be able to do so. The key is running person repositories, which many people are currently doing, so Bob thinks the group might want to provide a best practices for identity management on campus in lieu of a stitched directories system. *Action Item* 1. Bob Talda will assist Tom in writing some preliminary scenarios for SAGE.