*MACE-Dir Conference Call*
November 12, 2001

*Participants*

Keith Hazelton -- Wisconsin(chair)
Tom Barton -- Memphis
Tom Dopirak -- CMU
Michael Gettes -- Georgetown
Ken Klingenstein -- Colorado/Internet2
Ellen Vaughan -- Internet2
Nate Klingenstein -- Internet2(scribe)

*Discussion*

eduPerson playGround, Third Edition

        The third attempt at making an eduPerson playground focused now on
the URN-based approach which Bob Morgan recommended on the last call.  The
group thought eligibility was a slightly misleading term, and asked to
replace it with entitlement, which it felt was more accurate.  The two new
attribute definitions -- eduPersonExtEntitlement and eduPersonExtGroup --
were still the two discussed in this call, despite some reservations that
other attributes might be appropriate.  There was also a desire among a
number of the group's members to place the newly added attributes in
eduPersonExt where they can be considered experimental until they
"graduate" to the status of being full attributes.  This would both provide
a trial period to ensure that the attributes the group selected were useful
in implementation and would serve to bolster the viability and meaning of
the eduPersonExt set of attributes.
        Michael added a measure of implementational experience with the
eduPersonExtEntitlement attribute in the form of his own gUServiceEligible,
which currently contains only one attribute called Calendar.  This allows
certain people to go to a webpage, request the calendaring service, and get
it.  The element of business logic in this needs to be handled between the
application and the directory; while the directory can assert this
eligibility, there must always be a business process responsible for
setting the eligibility bit in the directory properly.  This also raised an
outstanding issue of whether eduPerson is intended only for
inter-institutional purposes, since the appropriation of
eduPersonExtEntitlement for gUServiceEligible and similar things would lead
to a glut of values this field could be populated with.  As another
prominent outstanding issue, the group isn't certain whether to consider
extending the controlled vocabulary of eduPersonAffiliation to include
other possibilities.

playGround Privacy

        If all eligibilities are supposed to be stored in the single
eduPersonExtEntitlement field, then how can privacy be protected when an
application tries to retrieve the attribute to check an eligibility,
especially if this is an inter-realm process?  The directory-based solution
to this seems to be limiting the attribute's visibility to the attribute
authority or similar object in the realm only, and then relying on this
machine to distribute information within the multivalued list
appropriately.  There was no other readily apparent means to protect this
attribute properly, which couples it very closely with implementations such
as Shibboleth.  The group had additional FERPA concerns that information
that might be okay to release would become more sensitive if it were
released in a large glut, increasing the need for proper protection for an
attribute like this.
        If the value of the eduPersonExtGroup field contains both the name
of the group asserted as well as the yes/no, how can students choose to
protect their privacy based on the value of the attribute instead of the
name of the attribute itself?  Some populations of this attribute might be
considered sensitive while others might not be to the same person, meaning
any sort of user interface which allows control over the release of this
attribute needs to take into account the value of the attribute itself as
well as the name.  This is another tricky question which the group also had
to delegate primarily to the attribute authority, since the directory can't
do much in this space.

Namespace

        It was agreed that requesting a URN would be the best way to
proceed to make the namespaces in the eduPersonExtEligibility and
eduPersonExtGroup attributes globally unique; this is fully discussed in
previous MACE-Dir minutes.  The group began to flesh in the details of the
request that will be made for the issuance of the namespace, including a
formal description of the usage of the namespace, the rules under which
names in the namespace may be issued, and the governing body which would
control the URN.  Keith thought the process was manageable and possible,
and he is willing to take a fast-track action item to produce the formal
requesting document if the group agrees on registration of a URN.
        There were several possible groups that could be asked to manage
the namespace.  The first, obvious choice was MACE, which has the benefit
of being a real, live, functioning body for which the members on the call
had a certain amount of voice, and one which has no obvious religious
alignments; nobody was certain that MACE wanted to get into the
nitty-gritty details of namespace management, however.  NMI was another
possibility mentioned, but in the interest of expediency this might not be
the best choice, since it will likely be crucial to have the namespace in
place within six months.  EDUCAUSE and Internet2 were also mentioned as
possibilities, with EDUCAUSE having an advantage in being likely the most
long-lived of the mentioned groups.  Only the base-level governing body's
URN name(NID) would have to be registered; anything else within that
namespace can be assigned by the group(namespace specific string, or NSS)
according to the rules put forth in its RFC.  The group still plans to
leverage the DNS system as a way of ensuring uniqueness beyond the NID.
        As far as the specific means by which the governing body would
issue NSS's if an RFC were received, the group agreed there should be no
need to register anything if it were used only in the eduPersonExt
playGround buckets.  The degree to which beyond this it should be regulated
is contentious, however, with several group members noting that it is
important to have a definite set of rules for use of the NID to encourage
its issuance.  The job is also not to enforce, but instead to limit
confusion and conflict with the understanding that the trade-off for
registration is additional inter-realm flexibility without the need for
additional object classes.
        The idea was raised of adding a second set of qualifiers after the
initial NID, such as :DNS, :EDU or :SHIBBOLETH.  These would serve to
restrict some namespaces further while allowing more of a free reign in the
more playground ones.  There are multiple such community names that could
be included, and the group was generally in favor of this more "flat and
bushy" approach to namespace management.