*MACE-Dir Conference Call*
November 24, 2003

*Participants*

Keith Hazelton -- Wisconsin (chair)
Tom Barton -- Chicago
Brendan Bellina -- Notre Dame
Renee Frost -- Michigan/Internet2
Mike Grady -- Illinois
Paul Hill -- MIT
Steve Olshansky -- Internet2
Bob Morgan -- Washington
Barry Ribbeck -- UTHSC-H
Bob Talda -- Cornell
Ann West -- EDUCAUSE/Internet2
Nate Klingenstein -- Internet2 (scribe)

*Discussion*

There is an ongoing survey of experiences that institutions have had 
in working with different vendors to directory-enable and integrate 
their applications.  All are encouraged to submit more experiences to 
help develop a document that can aid future vendor interactions.

eduPersonTargetedID & LDAP

The realization struck the group that eduPersonTargetedID as it is 
defined really can't be put in an LDAP directory.  It has multiple 
components to it and depends on other variables.  The temporary measure 
that the Shibboleth project has undertaken is to define an attribute 
using a Java class which is essentially a three-part hash of the 
username, the target's name, and a "random salt."  That sort of 
construct is not readily expressed in LDAP and may not belong in the 
directory at all.

However, Bob Morgan reasoned that it still is a part of eduPerson.  
There is "no need to create a new bucket for that other thing just 
because it's a little different; this is where we define stuff useful 
for higher ed and potentially elsewhere."  The actual storage and 
transport of the attribute should not be a discriminating factor in 
deciding what should or should not be part of eduPerson.

Tom's concern is that the inclusion of non-LDAP attributes in 
eduPerson breaks the LDIF model, where a campus can simply feed the 
appropriate eduPerson LDIF to its directory and implement eduPerson.  
Keith suggested including it in the LDIF, but say, "nobody actually 
expects you to put any values in there."  He also asked if anyone could 
come up with a more "egregious" example of an eduPerson attribute that 
couldn't be stored in a directory at all.

Questions remain whether the spec should say that eduPersonTargetedID 
should not be stored in your directory under any circumstances, and if 
it isn't stored there, does MACE-Dir define where it should be stored?  
The biggest requirement on an attribute like this is that it appear 
properly in SAML assertions, and the mapping from LDAP-style attributes 
to SAML-style attributes involves a transformation from the standard 
field name to a federation-defined URN.

eduPerson 200312

Keith revised the draft again, and a couple more modifications were 
suggested on the phone call.  #38's attribute definition read "Unique 
Identifier, defined in NONE."  This will be fixed.  There was also a 
lot of confusion surrounding the X.500 unique identifier, 
inetOrgPerson, and uniqueIdentifier; apparently, uniqueIdentifier is 
in X.520 and not an alias for the X.500 version.

The fact that eduPersonTargetedID and potentially future attributes 
will not be LDAP implies a significant evolution of eduPerson's 
specifications.  A container document that includes all things 
eduPerson will be the foundation of the specification with a set of 
documents beneath it, one of which might describe how to map some parts 
of eduPerson to SAML attributes.  Another would describe the certain 
parts of eduPerson more appropriate for the LDAP directory.

This magnitude of revision cannot be made quickly and there are still 
compelling reasons, such as eduPersonScopedAffiliation and NMI Release 4,
to release eduPerson 200312 as it stands.  This new format and the 
extension beyond the directory should be implemented quickly thereafter 
and released, perhaps as eduPerson 200401 or 200402.