*MACE-Dir Conference Call*
October 15, 2001

*Participants*

Keith Hazelton -- Wisconsin(chair)
Tom Barton -- Memphis
Steven Carmody -- Brown
Renee Frost -- Michigan/Internet2
Michael Gettes -- Georgetown
Eric Norman -- Wisconsin
Todd Piket -- Michigan Tech
David Wasley -- UCOP
Ellen Vaughan -- Internet2
Nate Klingenstein -- Internet2(scribe)

*Discussion*

eduOrg

        A new object class has been proposed recently as the need for it
has become increasingly more evident with such inter-realm projects as
Shibboleth and DoDHE.  This object class would be built on top of
current x.521 object classes, much as eduPerson was built on the x.500
standards. Standardization and extension of the basic X.521 object classes will
allow for better inter-realm trust, resource discovery, and many other
potential uses.  The development of eduOrg will be similar to that of eduPerson,
where object classes will be defined top-down based initially on
outstanding standards -- x.521 and x.520, in this instance -- and
maintaining compatibility with these standards whenever possible.  The
group will first consider all existing attributes and whether these
attributes are appropriate for eduOrg, and then will move on to defining
any necessary additional attributes.
        One of the most significant issues raised initially is precisely
which X.521 object classes eduOrg will extend.  In Michael's words, "in
x.500's infinite wisdom, they came up with the org object class and the
orgUnit object class."  The org object class is intended to refer to an
organization, and then orgUnit is meant to refer to groups subordinate
to the org.  The eduOrg object class could extend either, hypothetically;
the only difference between org and orgUnit is that org has orgDN and
orgUnit has orgUnitDN, and from there on the object classes are identical in
content.  eduOrg, if aimed at the organizational level, could
potentially include some attributes which would be inappropriate at the orgUnit
level. Michael felt it important to not eliminate the ability to define policy
and similar eduOrg properties at a finer grain.  This was resolved by being
marked "Outstanding Issue #1," and it was concluded for now that all
attributes developed for eduOrg should be done such that they would make
sense as extentions to both org and orgUnit.
        RFC 2256 provides the IETF's overview on these attributes and
recommendations on which attributes should be included for
standardization. The group expects to produce a set of recommendations on the attributes
that should be passed on from the original x.521, and refers to these
documents as much as possible.  Some attributes will have no comment,
which is tantamount to deprecation; the group could define no useful reason
for having the attribute.
        [AI] Amidst some confusion over the differences between
auxiliary, structural, and abstract object classes, whether an x.500 object was
explicitly defined as one object type or whether an object could have
its type inferred by its attributes or multiple types, and the relationships
between org, orgUnit, and orgPerson, Keith asked everyone to bring back
additional knowledge about these topics for the next call.

x.521 org

        The group began its work on eduOrg by trolling through the
existing X.521 object class and evaluating each defined attribute.  org is
composed of a standalone description attribute, several auxiliary object classes:
locale attributes, postal attributes, telecommunications attributes, and
four other standalone attributes.  In this call, the group first looked
at teleCommunicationAttributeSet.  These attributes are the ones the group
commented on:

destinationIndicator:  This attribute originally specified the means for
getting a telegraph to an organization, and will likely receeive no
comment.

preferredDeliveryMethod:  Having been deprecated from many specs based
on x.500 objects, this will also not be commented on in eduOrg.

physicalDeliveryOfficeName:  This field will also receive no comment, as
it is very poorly defined and relatively useless with current mail-handling
technique.  The group determined the need to develop a new set of
recommendations to deal with different ways of handling mail in other
countries, much as these exist for dealing with different cultures'
common names.

locality:  This field's utility stymied the group.  The group was
confused as to whether locality was generally available in implementations as an
indexed attribute for search purposes; in Michael's experience, it had
only been meant as a way to browse.  Steven still saw some usefulness for the
attribute, especially for situations such as New England, where a large
number of cities can be present in a greater metropolitan area.

PKI and eduOrg

        In discussions between Keith and Eric, they agreed that a
mechanism to store an institutional certificate in eduOrg would be extremely handy
for many inter-realm applications.  Conveniently, one such method is
defined in x.521, where they refer to a pKICA object class in x.509.
This object class is an auxilliary object class, which means it can be added
in an eduOrg attribute.  pKICA has been well-defined and contains a wealth
of interesting and potentially useful attributes.  The only concern the
group voiced was that some products expect certain directory formats: for
example, an old program could load a directory entry, ignoring these
unknown attributes, then accidentally purge these attributes in a
re-write.

Shibboleth, MACE-Dir, and the eduPerson playGround

        Given that MACE-Dir, Shibboleth, and various other Internet2
programs are all generally involved in the NMI, there is a general
consensus that all these pieces should, in Steven's words, "lego
together well."  He was concerned that the amount of work that should proceed to
ensure that eduPerson, institutional directory designs, the newly
defined eduOrg, and Shibboleth interface reasonably well.
        In recent Shibboleth design team meetings, summarized on the
MACE-Shibboleth list by design team member Marlena Erdos of IBM/Tivoli,
there has been discussion of adding an additional data store between
Shibboleth's attribute authority, which is responsible for retrieving
local attributes and distributing them to other security domains in a trusted
fashion, and the institutional directories.  This was going to be done
in MySQL because of poor ACL implementation in open LDAP, which the group
agreed was an unfortunately weak area of the protocol.  The group
thought it would be important to discuss the reasoning behind the implementation
of a separate data store further with Tom Dopirak of Carnegie Mellon.
        Implementation of such an object concerned Steven greatly, and
he said that he assumed "everyone on [the MACE-Dir] call understands what
it means to maintain the contents of yet another directory."  Michael
remarked that Shibboleth is still very new, and given that as much ability and
flexibility as is possible is necessary to learn what it needs to be
able to do, this may be an acceptible approach for the v0.9 implementation of
Shibboleth.  [AI] Keith agreed to learn everything he could of
Shibboleth's current use of directories and to draft a message for the Shibboleth
design team detailing some recommendations on behalf of MACE-Dir to the
Shibboleth effort.  He will send this drafted message initially to MACE-Dir for
review and acceptance.
        Still, the group agreed that an ability to directly interface
with, in Keith's words, "a long and ugly list" of directory systems at many
institutions was a desirable eventual ability.  LDAP is one example of
this large number of directory solutions that could have been implemented,
and Michael was very clear to emphasize that if Shibboleth were to support
or require a specific feature of a specific implementation, muddy waters
would be strayed into.  Given that Shibboleth is open-source, there's a good
deal more leverage here; Shibboleth can aim for the lowest common
denominator, and then institutions can implement these more specialized features if
they wish to write the independant code.
        There has also been the request from several Shibboleth pilots
for a so-called playground in eduPerson which would allow them to transmit
effectively whichever proprietary information they wished.  There are
two primary ways in which this could be implemented: eduPerson could have
variant schema defined for these proprietary informations, or a
playGround attribute which could be populated in any means communicating parties
wished.  The group initially favoured the latter way of implementing
this because otherwise the maintenance of different styles of eduPerson and
the potential incompatibilities would result in very difficult
interoperability and would serve to partially de-standardize eduPerson.  The playGround
attribute would be totally undefined and could be used as any party
pleased.

*Action Items*

1.  Keith asked everyone to bring back additional knowledge about object
class definitions and other topics for the next call.

2.  Keith agreed to learn everything he could of Shibboleth's current
use of directories and to draft a message for the Shibboleth design team
detailing some recommendations on behalf of MACE-Dir to the Shibboleth
effort.  He will send this drafted message initially to MACE-Dir for
review and acceptance.