**MACE-Dir Call 2-November-2009**

**Attending**
Keith Hazelton, U. Wisconsin - Madison (stand-in chair)

Eric Goodman, UC Santa Cruz

Keith Hirsch, Suffolk U.

Bert Bee-Lindgren, Georgia Tech

Todd Deginski, ODU

Michael Pelikan, The Penn State U.

Tom Barton, U. Chicago

Scott Cantor, The Ohio State U.

Steven Carmody, Brown U.

Todd Piket, Minnesota State Colleges and Universities

Wes Hubert, U. Kansas

Don Picnor, U. South Dakota

Michael Hodges, U. Hawaii

RL "Bob" Morgan, U. Washington

Paul Hilche, U. Victoria

Steve Olshansky, Internet2 (scribe)

**Next call 16-November-2009 4:30 PM EST**

**New Action Items**

[A] (All) Volunteers for working on surveys about managing people entries, attributes, and affiliations from non-authoritative sources, contact Keith.

**Carryover Action Items**

[A] (Keith) will follow up on the REFEDs list conveying the sentiments expressed on the call today about the ePSA usage comparison.

[AI] (Mike) review the LocalDomainPerson survey results and the Shibboleth attribute naming documentation with an eye toward useful attributes to generalize, as a reference for naming guidelines and base attributes to propose.

http://middleware.internet2.edu/dir/localsurvey.html

http://middleware.internet2.edu/dir/docs/internet2-mace-dir-localdomainperson-200505.html

[AI] (RL "Bob") will craft a survey on use of the mail attribute and possible need for additional email attributes. This surfaced again at the recent TF-EMC2 meeting, in the context of a campus IdP serving Grid apps. E.g. what are RPs assuming?

[AI] (Brendan) will poll the mailing list for feedback on the use of name fields, and whether they have had the need to extend eduPerson locally with additional name fields.

[AI] (Brendan) will coordinate with the leaders of the Educause IdM Constituent Group, toward the goal of polling that group along with MACE-Dir for feedback on the use of commercial and open-source IdM products.

**Discussion**

1. eduMember status and usefulness

- There is international interest in using isMemberOf. However eduMember has not enjoyed the adoption that eduPerson has.

How are we representing group memberships in registries/LDAP directories, or in SAML expressions? A standard way of approaching this would be of significant benefit to many communities.

There is already a mapping of LDAP attributes into SAML expressions, which we would be leveraging in the SAML context.

There appears to be significant interest in expressing group membership in SAML expressions, in a quick poll among call attendees. Using entitlement values was raised as well, as an alternative.

The existing X.500 profile (using OIDs) would seem to be the logical approach where possible, but if nothing has been defined in a particular situation then perhaps using entitlement would be the easiest solution.

The issue was raised of group names that, while unique locally, might conflict with those used at other organizations. Using URIs or prefixes to disambiguate would thus be advisable.

Using Grouper to get group names into LDAP, one approach is to use Ldappc, while some organizations are using custom code to accomplish this.

Q: do SPs find difficulty using OID-named attributes?

A: SPs have problems with attributes they don't automatically support...

2. Practices regarding shared (departmental, organizational) accounts

- For those on the EDUCAUSE IDM list see the thread "[IDM] "Edge" LDAP servers, and writing to central LDAP servers" initiated by Eric Goodman Oct 20

Eric's goals in starting this discussion are:

- seeking clarity on common practice in adding data to IdM systems

- understanding the processes used for adding additional data, e.g. replicas, virtual directories, locally controlled attributes

- better understanding issues and concerns about functional accounts (i.e. not associated with a particular user identity)

Auditing requirements arose as a potential issue affecting the approach taken, and need to be considered. Help-desk issues as well could be a factor, in diagnosing access problems.

It was observed that in some cases, insisting on the authoritativeness of information can be at cross purposes to utility in actual use (i.e. using data of questionable provenance), subject to practical requirements of the application in question.

Being able to readily identify the source of a particular data element, including how authoritative it is, was raised as a useful approach in practice. The rapid pace of technology advancement can certainly outrun the policies in place.

Managing access is often at the root of issues around attribute usage, but providing useful information to other users is also seen in the wild (e.g. supervisor or office hours).