*MACE-Dir Conference Call*
March 17, 2003

*Participants*

Keith Hazelton -- Wisconsin (chair)
Rob Banz -- UMBC
Tom Barton -- Memphis
Brendan Bellina -- Notre Dame
Steven Carmody -- Brown
Renee Frost -- Michigan/Internet2
Mike Grady -- Indiana
Ken Klingenstein -- Colorado/Internet2
Steve Olshansky -- Internet2
Todd Piket -- Michigan Tech
Bob Talda -- Cornell
Nate Klingenstein -- Internet2 (scribe)

*Discussion*

eduPersonScopedAffiliation

	The actual implementation of Shibboleth up through version 0.7 had 
been shipping using an incorrect syntax for eduPersonAffiliation.  In 
essence, the domain had been appended to the attribute because "member" 
is difficult to utilize meaningfully in access controls without the 
associated domain.  In order to become more compliant with the proper 
usage of eduPerson, Shibboleth v0.8 has been shipped using an attribute 
eduPersonScopedAffiliation with a value of affiliation@domain.
	There were two questions identified on the call for MACE-Dir, each of 
which has been faced before.  The first is the scope to which 
MACE-Dir's concerns extend; is MACE-Dir worried about on-the-wire 
interrealm things that utilize directories, or the content of the 
directory itself alone?  This may have implications for the 
recommendations MACE-Dir makes and the sort of advice it is willing to 
give.
	The second and more pressing question is what the intent of eduPerson 
is, and whether it is more specifically addressed toward interrealm 
uses or intrarealm uses.  While a strictly controlled vocabulary is 
useful for ensuring interoperability across realms and has proved very 
successful so far, a large number of campuses have seen the need for 
other affiliations or values which may seem more appropriate for 
eduPerson.
	A common complaint has been the need to check in multiple places for a 
principal's affiliation due to the need for a broader vocabulary than 
eduPerson offers.  Some solutions, such as placing any campus-specific 
information in eduPersonEntitlement, may not address this potential 
problem.  This led into a discussion about whether or not it may be 
appropriate to expand the vocabulary of eduPerson to encompass some 
attributes and values which may be primarily useful in intrarealm 
cases.

brownEduPersonAffiliation

	Steven reported a scenario that many people echoed on the call as 
being commonplace among campuses.  He had to create brownEduPerson, 
which has now grown to some 12 attributes, to reflect information and 
values unique to the Brown environment, but now feels that many of 
these attributes belong in eduPerson -- not because there is a real 
interrealm need for these attributes, but in order to promote 
commonality between implementations.
	Many of these same issues were visited when eduPersonEntitlement 
was created, essentially granting campuses a "playground" attribute in 
which to dump agreement-specific information.  One reason this 
wide-open attribute was created is that it is very difficult to capture 
some information such as applicant, because definitions of this status 
vary so widely from one campus to the next, with significant 
contractual obligations in place.  However, there may still be grounds 
for some expansion if there is enough commonality in place.

Open Attributes

	One rule followed when creating eduPerson was to avoid adding "other" 
to the controlled vocabulary at all costs.  The group discussed a few 
of the ways to expand eduPersonAffiliation without degrading the 
usefulness and meaning of the attribute.  However, there was some 
discussion about the necessity of even doing so: the X.521 space has 
traditionally utilized auxiliary object classes to expand the set of 
attributes of superclasses.  This option always remains open to 
eduPerson adopters.  There isn't much precedent for intelligent 
clients and browsers to utilize this sort of approach, however.
	Rob observed that if the attribute were simply opened up, it becomes 
impossible to later further expand the syntax, because there may be a 
value collision.  He suggested as an alternative to add a "local:" 
prefix to attributes which are site-created.  This would both allow 
further expansion of the vocabulary, and allow sites that received 
"local:*" values in interrealm transactions to either ignore 
or treat appropriately the information.