Untitled Document

NSF Middleware Initiative Document: draft-internet2-mace-dir-higher-ed-person-analysis-06.htm Category: Informational DRAFT	Brendan Bellina, University of Southern California Peter Gietz, DAASI International, GmbH Tübingen
Copyright © 2005 by Internet2 and/or the respective authors	November 2005
	Revision: 06
Comments to: nmi-support@nsf-middleware.org	Nov 21, 2005

Higher-Education Person: A Comparative Analysis of Collaborative Public LDAP Person Object Classes in Higher-Education

Abstract

Higher-education institutions around the world have implemented LDAP directories to meet their authentication, authorization, and attribute release needs. Several independent collaborative efforts have produced publicly documented person object classes to address the specific needs of higher-education institutions. This document surveys a collection of these object classes, describing their common features as well as their unique differences.

To facilitate the initial researching of these object classes and to allow readers the opportunity of further research, it is a requirement of all of the sources included in this document that they be non-proprietary and openly published on the world wide web. Links to source websites are included throughout the text and repeated in the Websites and References sections.

This document would not have been possible without the significant work by all collaborative bodies evident in the source documents. Readers are encouraged to review the source documents directly for additional detail and depth.

Table of Contents

Higher-Education Person: A Comparative Analysis of Collaborative Public LDAP Person Object Classes in Higher-Education 1
Abstract 1
Table of Contents 2
1 Introduction 6
2 Conventions used in this document 6
3 Terminology 6
4 Contributing Sources 10
4.1 MACE - eduPerson, eduCourse, eduMember 10
4.2 TERENA - DEEP Standardization of LDAP Schema Report 11
4.3 NMI LocalDomainPerson Survey Results 11
4.4 TERENA Schema Harmonization Commitee 11
4.5 Australia - WALAP auEduPerson 12
4.6 Germany - AMBIX 2002 and HIS Schema v0.5.2 12
4.7 Finland - Finnish IT Centre for Science (CSC) FunetEduPerson 13
4.8 Norway - FEIDE norEdu Object Class Specification 1.3 13
4.9 France - SupAnnPerson 1.0 Object Class for French Education Directories 14
4.10 Switzerland – SWITCH swissEduPerson 14
4.11 Spain - Spanish National Research Network RedIRIS 14
4.12 Poland – pleduperson 14
5 Additional Considered Sources 14
5.1 Croatia – CarnetPerson and CarnetCmuPerson Object Classes 15
5.2 Czech Technical University 15
5.3 Greece – GRNET Directory Service 15
5.4 Belgium – BELNET Directory Service 15
5.5 The United Kingdom – DANTE 16
5.6 Czech Republic National Research Network – CESNET 16
5.7 The Netherlands – SURFnet, TrustSURF, and NLeduperson 16
6 Object Class Attribute Comparisons 16
6.1 Personal Characteristics 17
6.1.1 Affiliation 17
6.1.2 Primary Affiliation 18
6.1.3 Date of Birth 19
6.1.4 Personal Title/Salutation 19
6.1.5 Preferred Given Name 21
6.1.6 gender 21
6.1.7 Marital Status 22
6.1.8 Area of Expertise, Area of Interest 23
6.1.9 Interest Classification Scheme 23
6.1.10 Prior Name 23
6.1.11 Formal Name 23
6.1.12 Preferred Surname 24
6.1.13 First Surname (paternal name) and Second Surname (maternal maiden name) 24
6.1.14 Middle Name 24
6.1.15 Spouse Name 24
6.1.16 Preferred Language 25
6.1.17 Deceased Date 25
6.1.18 Citizenship / Nationality 25
6.1.19 Immigration Status 26
6.1.20 Home Town 26
6.1.21 Generation Qualifier 26
6.1.22 Personal Title After First Name 26
6.1.23 Sort Name 27
6.1.24 Curriculum Vitae URL 27
6.1.25 Degree Conferred 27
6.1.26 Surname at Birth 27
6.1.27 Name Extension 27
6.2 Contact / Location Information 28
6.2.1 Home Organization Code, Name, and Type 28
6.2.2 Address and Telephone Number Types 28
6.2.3 Internal Organization / Department / Active Unit 29
6.2.4 Additional Telephone Number(s) 29
6.2.5 Campus and Primary Campus 30
6.2.6 Country of Residence 30
6.2.7 Postal Country 30
6.2.8 House Identifier 30
6.2.9 Postal Address Extension 30
6.3 Student Information 31
6.3.1 Curriculum / Branch of Study / Educational Program 31
6.3.2 Major(s) 31
6.3.3 Degree 32
6.3.4 Class / Level of Study 32
6.3.5 Minor(s) 33
6.3.6 College 33
6.3.7 Concentration 33
6.3.8 Orientation Alternative 33
6.3.9 Status 33
6.3.10 Cohort Year 33
6.3.11 Student Start Date / Matriculation (Enrollment) Date 34
6.3.12 Exmatriculation Date 34
6.3.13 Last Term Enrolled 34
6.3.14 Enrolled course list 35
6.3.15 Course Role Information 35
6.4 Employee Information 35
6.4.1 Category Code / Position 35
6.4.2 Office Hours / Consulting Hours 36
6.4.3 Primary Department 36
6.4.4 Title(s) with Department(s) 36
6.4.5 Primary Title with Department 37
6.4.6 Teaching Subject 37
6.4.7 Cost Center 37
6.4.8 Employee Start Date 37
6.4.9 Employee Expiry Date 37
6.5 Linkage Identifiers / Foreign Keys 38
6.5.1 Government Assigned Identification Code 38
6.5.2 Student System Identification Code 39
6.5.3 Unique Permanent Person Identification Code 40
6.5.4 Federated Identification Code 40
6.5.5 Local University Identification Code 41
6.5.6 Directory Globally Unique Identification Code (GUID) 41
6.5.7 Email aliases 42
6.5.8 Employee Identification Code 42
6.5.9 Kerberos Principal 43
6.5.10 Network Operating System (NOS) Identification Code 43
6.5.11 Network Services Identification Code 44
6.5.12 Prior Identification Codes 44
6.5.13 Library Card Bar Code Number 45
6.5.14 Account DN (Distinguished Name) 45
6.5.15 Login alias 45
6.6 Entry Metadata / Administration Information 45
6.6.1 Expiration Date 46
6.6.2 Entry Owner / Maintainer 46
6.6.3 Entry Creation Date 47
6.6.4 Decay Date 47
6.6.5 Expiration Countdown 47
6.6.6 Proxy 47
6.6.7 Entry Type 48
6.6.8 Administrator Comment 48
6.6.9 Data Source 48
6.6.10 Status 48
6.6.11 Contact History 49
6.6.12 Entry COPA Classification Code 49
6.7 Security Attributes and Keys 49
6.7.1 PIN 49
6.7.2 Challenge Question Pairs 50
6.7.3 Public Key 50
6.7.4 Library PIN 50
6.8 Confidentiality / Attribute Release (Visibility) 51
6.8.1 Restrict entry externally 52
6.8.2 Private attributes / Attribute Release Policy 52
6.8.3 Attribute Indexing Policy 53
6.8.4 FERPA restriction 53
6.8.5 Restrict Personal Information 54
6.8.6 Accept FERPA Responsibility 54
6.8.7 Accept FERPA Responsibility Date 54
6.8.8 Objection to Public View Period Date 54
6.8.9 Opt-in Status 54
6.8.10 Distribution 55
6.9 Authorization, Entitlements 55
6.9.1 Authorized Applications 55
6.9.2 Service Activity Statuses 56
6.9.3 Entitlements 56
6.10 Group-related Attributes 57
6.10.1 Current Group Membership 57
6.10.2 Historical Group Membership 58
6.11 Other Attributes 59
6.11.1 Mail Host 59
6.11.2 Mail Routing Address 59
6.11.3 Mailbox 59
6.11.4 Presence ID 59
6.12 Standard Attributes 60
6.12.1 common Name (cn) (OID 2.5.4.3) 60
6.12.2 description (OID 2.5.4.13) 61
6.12.3 departmentNumber (OID 2.16.840.1.113730.3.1.2) 61
6.12.4 displayName (OID 16.840.1.113730.3.1.241) 61
6.12.5 employeeNumber (OID 2.16.840.1.113730.3.1.3) 61
6.12.6 employeeType (OID 2.16.840.1.113730.3.1.4) 62
6.12.7 facsimileTelephoneNumber (OID 2.5.4.23) 62
6.12.8 givenName (gn) (OID 2.5.4.42) 62
6.12.9 homePhone (OID 0.9.2342.19200300.100.1.20) 62
6.12.10 homePostalAddress (OID 0.9.2342.192000300.100.1.39) 62
6.12.11 jpegPhoto (OID 0.9.2342.19200300.100.1.60) 63
6.12.12 labeledURI (OID 1.3.6.1.4.1.250.1.57) 63
6.12.13 localityName (l) (OID 2.5.4.7) 63
6.12.14 mail (OID 0.9.2342.19200300.100.1.3) 63
6.12.15 manager (OID 0.9.2342.19200300.100.1.10) 63
6.12.16 mobile (OID 0.9.2342.19200300.100.1.41) 63
6.12.17 o (organizationName) (OID 2.5.4.10) 64
6.12.18 organizationalUnitName (ou) (OID 2.5.4.11) 64
6.12.19 pager (OID 0.9.2342.19200300.100.1.42) 64
6.12.20 postalAddress (OID 2.5.4.16) 64
6.12.21 postalCode (OID 2.5.4.17) 65
6.12.22 postOfficeBox (OID 2.5.4.18) 65
6.12.23 preferredLanguage (OID 2.16.840.1.113730.3.1.39) 65
6.12.24 roomNumber (OID 0.9.2342.19200300.100.1.6) 65
6.12.25 seeAlso (OID 2.5.4.34) 65
6.12.26 street (OID 2.5.4.9) 66
6.12.27 surname (OID 2.5.4.4) 66
6.12.28 telephoneNumber (OID 2.5.4.20) 66
6.12.29 title (OID 2.5.4.12) 66
6.12.30 uid (OID 0.9.2342.19200300.100.1.1) 67
6.12.31 userCertificate (OID 2.5.4.36) 67
6.12.32 userPassword (OID 2.5.4.35) 67
6.12.33 userSMIMECertificate (OID 2.16.840.1.113730.3.1.40) 67
7 Summary 67
8 Addenda 68
9 Websites 68
10 Change Log 69
11 Acknowledgments 70
12 References 70
13 Contact Information 72

1 Introduction

This document is a comparative analysis of LDAP person object classes developed in collaboration for use at higher education institutions to represent the attributes of their members. All object classes included in this analysis are non-proprietary and published openly. It was the intent of the authors to compare and contrast the widest possible range of freely available LDAP person object classes in order to gain an understanding of the patterns of usefulness within higher education.

2 Conventions used in this document

This document is not a specification. The following paragraph is intended for quoted content included from specification documents.

The key words "MUST";, "MUST NOT";, "REQUIRED";, "SHALL";, "SHALL NOT";, "SHOULD";, "SHOULD NOT";, "RECOMMENDED";, "MAY";, and "OPTIONAL"; in this document are to be interpreted as described in RFC-2119.

3 Terminology

Access Controls
Directory Service products use access controls to restrict the release of directory information. The syntax and capabilities of access controls vary among DSA's.

authentication (authN)
Authentication is the process of establishing whether or not a real-world subject is who or what its identifier says it is. Identity can be proven by: Something you know, like a password or challenge-response mechanisms; Something you have, as with smart-cards or public-key certificates; Something you are, as with positive photo identification, fingerprints, and biometrics. (For more on this topic, see the Internet-2 Middleware Authentication website at <http://middleware.internet2.edu/core/authentication.html>.)

authorization (authZ)
The determination that a request can be honored is known as authorization. (For more on this topic, see the Internet-2 Middleware Authorization website at <http://middleware.internet2.edu/core/authorization.html>.)

auxiliary object class
An LDAP object class that is used to add a set of related attributes to an entry that already belongs to a structural object class.

CSC
The Finnish IT Center for Science

directory
A directory is a specialized database that may contain information about an institution’s membership, groups, roles, devices, systems, services, locations, and other resources.

DFN
The German National Research Network

eduOrg
An LDAP object class authored and promoted by the EDUCAUSE/Internet2 eduPerson Task Force to facilitate the development of inter-institutional applications. The eduOrg object class focuses on the attributes of organizations. Current documentation on the eduOrg object class is available at <http://www.educause.edu/eduperson/>.

eduPerson
An LDAP object class authored and promoted by the EDUCAUSE/Internet2 eduPerson Task Force to facilitate the development of inter-institutional applications. The eduPerson object class focuses on the attributes of individuals. Current documentation on the eduPerson object class is available at <http://www.educause.edu/eduperson/>.

enterprise directory
An enterprise directory is a core middleware architecture that may provide common authentication, authorization, and attribute services to electronic services offered by an institution. See the "Middleware Business Case"; <http://middleware.internet2.edu/earlyadopters/draft-internet2-ea-mw-business-case-00.pdf> for a thorough discussion of the values provided by enterprise directory services.

enterprise directory infrastructure
The infrastructure required to support and maintain an enterprise directory. This may include multiple directory hardware components as well as the processes by which data flows into and out of the directory service.

Enterprise resource planning (ERP)
ERP systems typically handle the back-end requires of a business. Within higher-education an ERP may handle all academic and administrative system requirements, replacing independent student, employee, and financial systems.

FERPA
Family Educational Rights and Privacy Act of 1974. A United States Federal Act which seeks to ensure the rights of students to review student records and prevent the unwanted release of personal information. See <http://www.ed.gov/policy/gen/guid/fpco/ferpa/index.html>.

GUID
GUID stands for Globally Unique Identifier. A guid is a unique identifier intended to identify a single person for the entire period of their intersection with an institution’s electronic services. The IETF standard attribute UUID in RFC 4122 is defined for this purpose.

inetOrgPerson
inetOrgPerson is an LDAP object class standardized in RFC 2798 that contains attributes describing people. inetOrgPerson is structurally descended from the standard organizationalPerson object class as specified in RFC 2256 and is often used as a parent for localized object classes.

Internet2
Led by more than 200 U.S. universities, working with industry and government, Internet2 develops and deploys advanced network applications and technologies for research and higher education, accelerating the creation of tomorrow's Internet. For more on this topic see <http://www.internet2.edu>.

ITU-T
International Telecommunication Union – Telecom Standardization Committee. The international organization responsible for documenting telephone number standards. These are published in ITU-T Recommendation E.123 Notation for national and international telephone numbers, e-mail addresses and Web addresses. ITU-T is also the standardization body of the X.500 standards suite for a direcvtory, which was the predecessor of LDAP directories. The ITT website is <http://www.itu.int/>.

Kerberos
Kerberos is a network authentication system for use on physically insecure networks, based on the key distribution model presented by Needham and Schroeder. It allows entities communicating over networks to prove their identity to each other while preventing eavesdropping or replay attacks. It also provides for data stream integrity (detection of modification) and secrecy (preventing unauthorized reading) using cryptography systems. Kerberos can be used to provide Single Sign-On functionality.

LDAP directory
An LDAP directory is one that supports the Lightweight Directory Access Protocol (LDAP). LDAP is a widely adopted IETF standard directory access protocol well suited to the authentication and authorization needs of modern application architectures. The Directory Server Agent or DSA is the system that processes LDAP protocol requests. Sun Java System Directory Server
(formerly SunONE Directory Server, formerly iPlanet Directory Server), Netscape Directory Server, OpenLDAP, Novell eDirectory, Oracle Internet Directory, IBM Secureway, and Microsoft Active Directory are examples of DSA’s. (For more on this topic see RFC3377 and the RFC’s it specifies, and Jeff Hodges’ LDAP Roadmap (1997) <http://www.kingsmountain.com/ldapRoadmap.shtml>.)

MACE
MACE is the Middleware Architecture Committee for Education, which consists of IT leaders from several higher-educational institutions. This committee focuses on a range of middleware issues affecting higher-education institutions. Working groups within MACE include, but are not limited to, MACE-Dir which focuses on directories, MACE-CourseID which focuses on learning management systems, and MACE-Dir-Groups which focuses on groups.

metadirectory (also meta-directory)
The metadirectory is a set of processes where source data is captured, identities are joined, and resulting data is transformed according to business processes and then stored or pushed to a directory or other application-serving repository. (For more on this topic, see Metadirectory Practices for Enterprise Directories in Higher Education <http://middleware.internet2.edu/dir/metadirectories/internet2-mace-dir-metadirectories-practices-200210.htm>.)

object class
An LDAP object class defines what attributes can be in an LDAP entry. Typically an object class models a real-world object such as a person.

registry
The registry is the system in which identity of resources is resolved. This often refers to a database component of the enterprise directory.
alt. def.: Data taken from multiple source/owner systems to which "intelligence"; has been applied in preparation for feed to one or more directories, applications, or other consumer systems. Further "intelligence"; may be applied as part of any individual feeding process. Registry data may be housed in a relational database, indexed files, or a directory server.

structural object class
An LDAP object class that describes the basic aspects of an object.

SWITCH
The Swiss Education & Research Network, operators of the SWITCHaai Federation for Switzerland.

TERENA
An organization of European Research Institutions. Sponsors of the DEEP Project and the SCHAC Project.

WAGUL
Western Australian Group of University Libraries – a partnership of the five western Australian libraries: Edith Cowan University, University of Western Australia, Curtin University of Technology, Murdoch University, and Notre Dame University

4 Contributing Sources

Contributing sources for this document were constrained to those that described person-based LDAP object classes that are:

- Currently in use in higher-education
- Publicly documented on the web and freely available
- Either developed collaboratively or developed to meet the needs of a group of institutions

In addition two published studies on the use of person object classes in higher-education, the TERENA DEEP Standardization of LDAP Schema Report (see section 4.2) and the NMI LocalDomainPerson Survey Results (see section 4.3) were included as representative samples of institution-specific practices in Europe and the United States.

Since all contributing resources are documented on the web, readers are encouraged to examine the contributing sources directly.

4.1 MACE - eduPerson, eduCourse, eduMember

eduPerson is an LDAP object class for institutional directories to be used to facilitate communication among institutions of higher learning. Consisting of a set of data elements, or attributes, about individuals within higher education, along with recommendations on the syntax, semantics, and privacy of the data that may be assigned to those attributes, eduPerson provides a common base upon which to construct advanced inter-institutional applications. Since v1.5 eduPerson has been defined as an auxiliary object class. First released by the MACE-Dir team in 2000 eduPerson has been implemented by a growing number of institutions. Additional information on eduPerson is available at the website <http://www.educause.edu/eduperson/>.

Developed by the MACE-CourseID working group eduCourse is an LDAP object class to be used to record course-related information in person entries or other entry types. Additional information on eduCourse is available at the website <http://middleware.internet2.edu/courseid/>.

Developed by the Groups subgroup of the MACE-Dir working group eduMember is an LDAP object class to be used to record group memberships in person entries or other entry types. Additional information on eduMember is available at the website <http://middleware.internet2.edu/dir/groups/>.

4.2 TERENA - DEEP Standardization of LDAP Schema Report

In 2002 the European organization TERENA together with a number of European National Research Networks sponsored a questionnaire for the "Definition of an European EduPerson"; Project, DEEP. The final results of the questionnaire were published in October 2002 by Peter Gietz of DAASI International Ltd., a German company active in the directory space. The web-based survey resulted in 18 participants, representing institutions in Australia and several European countries: the United Kingdom, the Netherlands, Poland, Spain, the Czech Republic, Hungary, Croatia, Switzerland, Sweden, Norway, and Finland. The questionnaire focused on the usage of person attributes and organization attributes. Statistical results and the DEEP Final Report are available at the TERENA website <http://www.terena.nl> and the DAASI website <http://www.daasi.de> at <http://www.daasi.de/projects/DEEP/DEEPFinalReport.pdf>.

4.3 NMI LocalDomainPerson Survey Results

Published by Internet2 and funded by NMI (National Science Foundation Middleware Initiative) this April 2004 white paper documents the results of a 2003 MACE-Dir team authored survey on the usage of locally defined person LDAP object classes in higher education. The survey was circulated via Internet2 and EDUCAUSE email lists and could also be filled out on the Internet2 middleware web site. While the survey was not intended to focus on the practices of U.S. institutions, 20 of the 23 respondents represented U.S. institutions. This survey was focused on localized extensions to the standard object classes and eduPerson and not on the usage of the standard attributes. Both the survey and the results document is available at the Internet2 middleware website <http://middleware.internet2.edu> at <http://middleware.internet2.edu/dir/docs/draft-internet2-mace-dir-localdomainperson-01.html>.

4.4 TERENA Schema Harmonization Commitee

After some other as yet unsuccessful approaches of standardizing LDAP schema for the higher educational community beyond the Internet2 eduPerson object classes, like the Internet2 activity called "International Person SChema" (<http://middleware.internet2.edu/intl-schema/>), the TERENA Task Force EMC2 (<http://www.terena.nl/tech/task-forces/tf-emc2/>) recognized the need for additional work in this critical area and founded a separate working group called the SChema Harmonization Committee "SCHAC"; (<http://www.terena.nl/tech/task-forces/tf-emc2/schac.html>). The Website says:

"The SChema Harmonization Committee was set up in February 2005 with the aim of carrying out some work in the area of attributes coordination related to higher education under the aspect of inter-institutional data exchange, recognized by the group as a real need. To date eduPerson represents the only successful attempt in this area, but it tailors American needs.";

and

"The objectives of SCHAC are:
- Build an internal kernel from existing local attributes and to agree on syntax and semantics
- Define a method to accept new attributes/classes
- Make the kernel evolve via a collaborative approach proposing new attributes/classes
- Promote the schemas within the NRENs constituency, making the results part of the local schemas
- Promoting the schemas in other projects, such as GEANT2, digital libraries etc
- Seek collaboration with EUNIS, Internet2 and others";

This work is based on the DEEP findings and tries to fill the gap of interoperability in directory deployments within Europe.

Until now there is a release candidate 3 version of the SCHAC specification called "SCHAC Schema for Academia - Attribute definitions for individual data, SCHAC-IAD-RC3" posted to the mailing list September 5, 2005. As the title indicates, this specification does not (yet?) include an object class definition, but only lists attribute types that would be interesting for inter-organizational data transfer. The short introduction states that the specified SCHAC schema is "not oriented to any particular technology" and that "appropriate profiles for LDAP and XML will be defined in other documents". Nonetheless the attribute list is based on the assumption that the LDAP standards on person schema including eduPerson are prerequisites.

The proposals made in the attribute list as of RC 3 have been included in this document. When a final release has been published this document will be updated accordingly.

4.5 Australia - WALAP auEduPerson

WALAP (WA Libraries Authentication Project) is an effort initiated by the Western Australian Group of University Librarians (WAGUL) in 2000 and funded by the Commonwealth Development Pool. The project’s aim was a distributed authentication infrastructure for the five western Australia universities. WALAP developed auEduPerson and auEduUnit object classes after determining that "PRIDE was too specific to its own content and that eduPerson didn’t add anything to inetOrgPerson for (their) purposes"; (<A Distributed Authentication Infrastructure for Western Australian Universities>). Complete WALAP documentation is available at the website <http://walap.curtin.edu.au/docs/>. The WALAP schema is available at <http://walap.curtin.edu.au/docs/walap_schema_1_0.ldif>.

4.6 Germany - AMBIX 2002 and HIS Schema v0.5.2

Between May 1994 and February 2003 the AMBIX 2002 system was designed and established to further discourse among German researchers. With sponsorship from by the German National Research Network (DFN) and the German Federal Ministry for Education and Research (BMBF), the AMBIX 2002 schema was created by DAASI International, an organization formerly affiliated with the University of Tübingen, Germany. The AMBIX 2002 schema is described at the website <http://www.directory.dfn.de/docs/AMBIX2002/ambix2002.html>.

In April 2005 DAASI International established the service eva|wiss as a enhancement to and replacement for AMBIX 2002. The eva|wiss service is documented at <http://www.evawiss.de>.

The following copyright notice relates to AMBIX 2002 and references to it in this document:

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to DAASI International GmbH.

The federal government funded non-profit company HIS GmbH (Higher Education Information Systems Ltd.) is in charge of developing Software products for German higher education organizations, e.g., for administering staff and students. The next release of this software suite, which is deployed by the majority of German universities, will contain an openLDAP based LDAP server for exporting data about staff members and students. It is believed that the schema used for this LDAP server will also be deployed in other LDAP servers of the higher ed organizations and will become a de facto
standard in Germany. The person object class hisPerson is based on eduPerson. At the time of this writing (September, 2005) the object class is at v0.5.2 and documentation is available (in German) online at <http://www.his.de/Abt1/HISSVA/HIS-PersOrgSchma-v0.5.2.pdf>.

4.7 Finland - Finnish IT Centre for Science (CSC) FunetEduPerson

CSC, the Finnish IT Centre for Science, created FunetEduPerson in 2003 to be the schema for LDAP directories in Finnish higher education. The object class is also used in attributes exchanged in the HAKA federation. The funetEduPerson 1.0 object class is described in the following pdf: <http://www.csc.fi/suomi/funet/middleware/haka/funetEduPerson_1_0.pdf>. For further information in English on the object class see the website <http://www.csc.fi/suomi/funet/middleware/english/>.

4.8 Norway - FEIDE norEdu Object Class Specification 1.3

norEdu is an object class that is based on the Internet2 MACE-Dir eduPerson and eduOrg object classes representing the common understanding of the Nordic academic community. Enhancements to eduPerson include the Norwegian National Identity Number (norEduPersonNIN) and support for the academic numbering and identifier schemes. Attributes in norEduPerson are regarded as personal information, and therefore their storage and use is regulated by Norwegian and international privacy legislation. The object class specification for norEdu, norEduOrg, and norEduOrgUnit can be found online at website <http://www.feide.no/dokumenter/feide-schema-current.html> and posted into CVS at <http://cvs.sourceforge.net/viewcvs.py/gnomis/norEdu/norperson-eduperson-13.html>. A document describing LDAP attribute usage in FEIDE is available at <http://www.feide.no/dokumenter/ldap/FEIDEldap.pdf>.

4.9 France - SupAnnPerson 1.0 Object Class for French Education Directories

The SupAnnPerson Object Class is a recommended auxiliary object class for French educational institutions. The SupAnnPerson object class is recommended as an extension to the eduPerson object class. For information in English on the SupAnnPerson object class and its accompanying groups object class SupAnnGroupe see the website <http://www.cru.fr/ldap/supann/supann-en.html>.

4.10 Switzerland – SWITCH swissEduPerson

SWITCH, the Swiss Education & Research Network, coordinates and operates the SWITCHaai Federation, implementing a Shibboleth-based Authentication and Authorization Infrastructure for the Swiss higher education community.

Based on the eduPerson object class definition and adjusted for the needs of the Swiss higher education system, the swissEduPerson object class is available at <http://www.switch.ch/aai/docs/swissedu.schema>. The attribute usage of the object class is documented at <http://www.switch.ch/aai/docs/AAI_Attr_Specs.pdf>. Prior versions of the swissEduPerson object class are available at <http://www.switch.ch/aai/docs/LDAP-schemas/>.

4.11 Spain - Spanish National Research Network RedIRIS

The object classes irisPerson, irisInetEntity, and irisInetEntityStr were developed by the Spanish National Research Network – RedIRIS – to support networked applications and communications among the members of its community. The schema documents are available online at <http://www.rediris.es/ldap/esquemas/iris.schema>. The 20050711 version is referenced in this document.

4.12 Poland – pleduperson

The pleduperson specification, developed for use in the educational institutions of Poland, is available online at <http://ldap.uni.torun.pl/raporty/ftp/uci/pledu.html>.

5 Additional Considered Sources

A number of additional national directory services were initially considered for inclusion, but in the end excluded for a variety of reasons. Not all national directory services publish their LDAP object classes online, a requirement for inclusion in this document, and not all have adequate documentation online to aid in a comparative analysis. Interested readers are nonetheless encouraged to examine the source materials directly using the web links provided. If circumstances warrant and allow, future revisions of this document may include object classes from one or more of the following sources.

5.1 Croatia – CarnetPerson and CarnetCmuPerson Object Classes

The Croatian CarnetPerson and CarnetCmuPerson object classes are described at the website <http://cmung.cmu.carnet.hr/shema.html>. These object classes are specifically to support CARNet network access and privileges. As such they are not an attempt to define person characteristics, but rather networking privileges, such as network identity, allowed dial-in method, and account expiration. While such object classes are useful and necessary for networking, their scope is too narrow for inclusion in this document.

5.2 Czech Technical University

Object classes described at website <http://usermap.cvut.cz/ldap/>. These object classes are highly customized to the specific departmental systems at the Czech Technical University, and do not meet the criterion of object classes that have been designed or proposed for multi-institutional usage.

5.3 Greece – GRNET Directory Service

The Greek academic and research institutions are provided national and international networking services by GRNET, the Greek Research and Technology Network. GRNET supports Universities, Technologoical Education Institutes and over 9500 schools via the Greek School Network. The GRNET Directory Service provides information about the users of the GRNET community. Community institutions providing directory content include: Aristotle University of Thessaloniki, GRNET, National Technical University of Athens, University of the Aegean, University of Crete, Universitty of Patras, and TEI Thessalonikis. A web interface to the GRNET Directory Service is provided via the GRNET website at <http://www.grnet.gr> and <http://ds.grnet.gr>. For documentation in English go to <http://ds.grnet.gr/main.php?language=en&e=1>. The lack of published materials online about the LDAP object class behind the directory service prevented its inclusion in this document.

5.4 Belgium – BELNET Directory Service

In April 1999, Jean-Marc Verbegt proposed to BELNET – the national research and education network of Belgium - a project to create a global Belgian directory based on LDAP. The BELNET directory service was developed and integrated with the European NameFLOW project. A web interface to the directory was provided at <http://ldap.belnet.be:8080> and <http://ldap.belnet.be:8389>. The lack of published materials online about the LDAP object class behind the web interface prevented its inclusion in this document

5.5 The United Kingdom – DANTE

Founded in 1993, DANTE (Delivery of Advanced Network Technology to Europe) was created by Europe’s National Research and Education Networks (NRENs) to plan, build, and operate pan-European networks for research and education. DANTE used standard LDAP attributes for the LDAP schema used in its "Nameflow"; project, which established an international X.500 infrastructure maintaining a root DSA, thus furthering X.500 deployment in the higher education realm across Europe. DANTE’s role and influence in the European directory space has been in decline since 2000 and documentation on their schema is no longer available online. Due to the lack of current online documentation and the lack of current usage it is not included in this document. Additional information on DANTE is available at <http://www.dante.net>.

5.6 Czech Republic National Research Network – CESNET

Founded in 1996, CESNET is an association of all universities of the Czech Republic and the Czech Academy of Sciences whose main goals are the operation and development of the Czech National Research and Education Network (NREN), and the broadening of public knowledge of the developing areas of advanced networking. Documentation about CESNET is available online at <http://www.cesnet.cz>. The lack of published materials online about the LDAP object class behind CESNET prevented its inclusion in this document.

5.7 The Netherlands – SURFnet, TrustSURF, and NLeduperson

SURFnet, the National Research Network of the Netherlands, provided an LDAP-hosting service aimed at recording personal data of staff and students of small institutions in the Netherlands that did not wish to host their own directory service. While the SURFnet service is discontinued as of June 30, 2005 SURFnet gave rise to the TrustSURF directory service and the NLeduperson object class which describes attributes recommended for use in Dutch institutions of higher education. TrustSURF and the Nleduperson object class are documented online at <http://www.surfnet.nl/innovatie/surfworks/directories/trustsurf.pdf>. Because the TrustSURF directory schema is almost entirely based on the standard attributes described in the TERENA-DEEP survey, and the DEEP survey is addressed independently in this document, including TrustSURF as a contributor in this document would be redundant. (The designers of the TrustSURF schema wanted to minimize the use of non-standard attributes, thus they only specified one attribute in addition to the standard classes, namely gender.)

6 Object Class Attribute Comparisons

The LDAP object classes considered in this document are designed to contain information specifically about people. It is helpful to consider this information within broad categories. The ten categories used in this document were compiled from the NMI LocalDomainPerson survey and discussions with the International Schema Archives (Feb, 2004). The categories are:

- Personal Characteristics
- Contact / Local Information
- Student Information
- Employee Information
- Linkage Identifiers / Foreign Keys
- Entry Metadata / Administration Information
- Security Attributes and Keys
- Confidentiality / Attribute Release (Visibility)
- Authorization, Entitlements
- Group-related Attributes
- Other Attributes (attributes that do not easily fit in one of the other categories)

Without exception the person object classes used in higher-education are designed to extend the standard LDAP object classes "person"; and "inetOrgPerson";. Section 6.12 discusses the attributes of these standard object classes and how they are used in higher-education.

Within each category the presence and usage of each attribute will be described. Attributes will be described in the order of their frequency within specifications, from most frequent to least frequent.

6.1 Personal Characteristics

Personal characteristics describe the individual person represented by the entry. Name and favorite drink are attributes that would be considered personal characteristics.

6.1.1 Affiliation

Included in:
eduPerson – eduPersonAffiliation
auEduPerson – auEduPersonType, auEduPersonSubType
AMBIX 2002 – dfnOrgPersonAffiliation
Funet – recommends both eduPersonAffiliation and a local institution affiliation attribute
norEduPerson – recommends the use of eduPersonAffiliation
supAnnPerson – recommends the use of eduPersonAffiliation with additional value "researcher";,

additional related attributes supannCodeINE and supannRole
swissEduPerson – recommends the use of eduPersonAffiliation
hisPerson - hisRole

Mentioned in:
LocalDomainPerson Survey – 63% of respondents
DEEP Survey – 77% of respondents

The desire to capture the roles of a person within an attribute seems to be universal. All of the object classes make an attempt to classify a person relationship or role within an institution.

The eduPerson object class uses a pair of affiliation attributes with a limited domain. The multi-valued eduPersonAffiliation and single-valued eduPersonPrimaryAffiliation attributes are intended to facilitate inter-institutional authorization decisions and as such use broad terms: student, staff, faculty, employee, alum, member, and affiliate, leaving the specific interpretations of the terms to the institutional agreement policies.

Similarly the auEduPerson object class uses the multi-valued attribute auEduPersonType to describe the broad categories: student, staff, other, and null (i.e., blank if no type applies). The auEduPersonSubType attribute provides a finer-grained level of authorization with categories: undergraduate (student), honours (student), postgraduate (student), external (student), visitor, unclassified, and null (i.e., left blank if no subtype applies).

The AMBIX 2002 dfnOrgPersonAffiliation attribute describes a person’s affiliation with the organizational unit it is defined within, but the online documentation does not specify the allowed values.

The HIS Person attribute hisRole is intended to be used in combination with eduPersonAffiliation and will contain more formal roles defined by the type of contract, e.g. technical staff, research staff.

The Finnish Funet, Norwegian norEduPerson, SWITCH swissEduPerson, Spanish RedIRIS, and Polish pleduperson each recommend the use of eduPerson. Funet recommends a locally defined affiliation attribute can be useful as well, and provides specific Finnish definitions for the affiliation values.

The French supAnnPerson recommends eduPersonAffiliation and eduPersonPrimaryAffiliation be used, but adds an additional non-standard value "researcher";. In addition supAnnPerson defines the attribute supannRole which identifies the roles played by a person at the institution. This shares similarity with the employee position attribute defined in some of the other object classes (sepStaffCategory, pleduPersonPosition).

6.1.2 Primary Affiliation

Included in:
eduPerson – eduPersonPrimaryAffiliation
AMBIX 2002 – dfnOrgPersonPrimaryAffiliation
Funet – recommends both eduPersonPrimaryAffiliation and a local institution primary affiliation attribute
norEduPerson – recommends the use of eduPersonPrimaryAffiliation
supAnnPerson – recommends the use of eduPersonPrimaryAffiliation with additional value "researcher";
swissEduPerson – recommends the use of eduPersonAffiliation

Mentioned in:
LocalDomainPerson Survey – 68% of respondents
DEEP Survey – 83% of respondents

EduPerson describes a "primary affiliation"; as that affiliation that one would put on a name tag at a institutionally sponsored social gathering. Most of the object class specifications recommend the use of the eduPerson attributes.

AMBIX 2002 defines a single-valued attribute dfnOrgPersonPrimaryAffiliation to correspond with its dfnOrgPersonAffiliation attribute (see the Affiliation section above).

6.1.3 Date of Birth

Included in:
Funet – FunetEduPersonDateOfBirth
swissEduPerson – swissEduPersonDateOfBirth
hisPerson – hisDateOfBirth
SCHAC – schacDateOfBirth

Derivable in:
norEduPerson – norEduPersonNIN

Mentioned in:
LocalDomainPerson Survey
DEEP Survey

The FunetEduperson, swissEduPerson, and HIS-Person object classes as well as the SCHAC attribute list each define an attribute to contain a person’s date of birth, although they do not agree on the appropriate format – Funet uses DD.MM.YYYY format , swissEduPerson and SCHAC use YYYYMMDD format, and HIS-Person uses YYYYMMDD00Z format which corresponds to the generalizedTime syntax specified in RFC 2252.

The Norwegian norEduPersonNIN attribute contains the Norwegian National Identity Number from which date of birth can be derived.

Most standard LDAP attributes that contain time-based information contain a complete timestamp, rather than a date. This has resulted in date fields, such as date of birth, being formatted inconsistently.

6.1.4 Personal Title/Salutation

Included in:
AuEduPerson - auEduPersonSalutation
SupAnnPerson – supannCivilite
RedIRIS – irisPersonalTitle
pleduperson – personalTitle
hisPerson – hisAcademicTitle, hisSalutationForm
SCHAC - schacPersonalTitle

Mentioned in:
DEEP Survey

Personal Title or Salutation attributes capture the usually short and often abbreviated salutation used prior to a person’s name. The values vary with written language of the country. Often the salutation will vary depending on the gender of the individual, so if gender is considered to be sensitive with respect to privacy (i.e, not something that a person would want to be generally released), then salutation should probably also be considered sensitive.

A personal title/salutation attribute is included in six of the specifications.

In auEduPerson the auEduPersonSalutation attribute may contain values such as "Mr";, "Ms";, "Dr";, "Prof";. None of the example salutations listed, while all are abbreviations, include a period. The salutations may indicate gender or profession. The use of "Ms"; rather than "Mrs"; prevents the attribute from revealing marital status. Similarly the documented examples for the RedIRIS attribute irisPersonalTitle and the SCHAC attribute schacPersonalTitle indicate gender ("Ms";) and profession ("Dr";, "Prof";, and "Rev";), but not marital status.

In supAnnPerson the supannCivilite attribute has three allowable values: "M.";, "Mme";, or "Mlle";. These values reveal gender and information about a woman’s marital status (presumably a "Mlle"; is a woman who has never married, while a "Mme"; is a woman previously or currently married).

Examples for the pleduperson personalTitle attribute include professional salutations such as "Profesor";, "Mgr";, and "Dr";. There are no examples that indicate gender or marital status. The DEEP Survey results document provides more information about the use of personalTitle in Poland:

"This attribute is only defined in pilotPerson structural object class; it is indispensable to describe Person defined by inetorgperson structural object class chain and eduPerson auxiliary class. Additionally, in Poland we have probably a specific situation - we should distinguish between professional degree and academic/research degree, so in fact two attributes will be necessary (or we will extend our schema locally).";

The need for separate title attributes for academic and research degrees was not described in any of the other object class specifications, so it may not be a general need.

The HIS attribute hisAcademicTitle is defined as the "Academic title of a person";. The attribute hisSalutationForm is defined as the "form of salutation as expected at the beginning of a letter.";

It is unclear whether the standard attribute "title"; is intended to describe job title rather than a professional salutation. The example given of "Vice President"; could be both title and salutation. The attribute "personalTitle"; as specified in RFC 1274 was intended to contain the "academic"; title.

In practice, the population of title and personalTitle attributes is culturally sensitive.

See section 6.12.29 for a discussion of the standard title attribute.

6.1.5 Preferred Given Name

Included in:
eduPerson – eduPersonNickname
auEduPerson – auEduPersonPreferredGivenName

Mentioned in:
LocalDomainPerson Survey – 26% of respondents
DEEP Survey – 44% of respondents

The purpose of the Preferred Given Name attributes in eduPerson and auEduPerson are to allow a person to specify an alternative name. Commonly this allows people who use a shortened or alternate form of their formal name – Bob instead of Robert, Meg instead of Margaret, Nick instead of Nicholas – or those who prefer to use their middle name in place of their first name to specify their preference. The preferred given name can be used in the displayname attribute. The preferred given name attribute may be the same as the standard givenname attribute.

Recommended in the Funet documentation.

6.4.7 Cost Center

Included in:
hisPerson – hisCostCenter

Defined in the hisPerson object class as the cost center associated with the person.

6.4.8 Employee Start Date

Included in:
hisPerson – hisEntryDate

Defined in the hisPerson object class as the date the relationship began with an employee. The format of the date is YYYYMMDD00Z.

6.4.9 Employee Expiry Date

Included in:
hisPerson – hisExpiryDate

Recommended in:
Funet - employeeInactiveDate

Defined in the hisPerson object class as the date an employee relationship ended. A similar attribute hisDateOfExatriculation is used to record the termination of a student relationship.

Funet recommends the use of a locally defined employeeInactiveDate to record the termination date of an employee relationship. Funet recommends a locally defined studentInactiveDate attribute to record the termination of a student relationship.

6.5 Linkage Identifiers / Foreign Keys

Linkage attributes are those identifiers used to link a directory entry with records in external data stores or other directory entries. The use of linkage identifiers can obviate the need to synchronize data elements between systems of record and the enterprise directory. Linkage attributes are also used in the implementation of metadirectory services.

6.5.1 Government Assigned Identification Code

Included in:
Funet – funetEduPersonIdentityCode
norEduPerson – norEduPersonNIN
supAnnPerson – supannCodeINE
RedIRIS – irisPersonalUniqueId
SCHAC - schacPersonalUniqueID

Mentioned in:
LocalDomainPerson Survey
DEEP Survey

Government-issued identifiers are often unique, persistent, and verifiable, so it is not surprising that they are used as a means of reliably identifying persons. Often a government id is used to link a person to a financial aid system, a payroll system, a health system, or a student system.

The Funet funetEduPersonIdentityCode is a single-valued attribute containing the Finnish Identity Code (FIC, formerly referred to as the Finnish Social Security Number). In order to support foreign students who do not have a Finnish Identity Code the attribute can also be used to contain artificial codes.

The FEIDE norEduPersonNIN attribute contains the Norwegian National Identity Number, an 11 digit string which is constructed in part from the subject’s birth date and gender. The Norwegian Data Inspectorate, which is responsible for providing a NIN to anyone who lives in Norway more than 3 months, does not consider the NIN to be sensitive information, a view that, according to the online documentation, is not necessarily shared by the Norwegian citizenry.

In the French SupAnn objectclass the supannCodeINE contains the French government assigned student identifier.

The RedIRIS irisPersonalUniqueId specfies a unique identifier that can be locally defined, but may be populated with a government identifier such as a passport number.

The SCHAC specification uses URN format to make it possible to include the different identifier mentioned above, like NIN or FIC, with the following syntax:
urn:SCHACPREFIX:uniqueID:<country-code>:<udType>:<idValue>, where <country-code> must be a ISO 3166 two-letter code and <idType> must be declared per each country code. The ID itself is stored in the <idValue> part.

Participants of both the LocalDomainPerson Survey and the DEEP Survey reported the usage of government identifiers such as U.S. Social Security Number for residents, as well as the need to create an attribute for the storage of Government Immigration Id for foreign visitors.

With government identifiers being the most common identification mechanism among all of the object classes analyzed it seems likely that use of government identifiers will be a continuing practice.

6.5.2 Student System Identification Code

Included in:
auEduPerson – auEduPersonID
Funet - funetEduPersonStudentID
NorEduPerson – norEduPersonLIN
supAnnPerson – supannEtuId
hisPerson - matriculationNumber

Mentioned in:
LocalDomainPerson Survey
DEEP Survey

The auEduPersonID is used to hold a student or employee identification number which is also expected to be used for cn. It is not clear from the object class definition why an identification code would be populated into the cn attribute.

The Funet funetEduPersonStudentID holds one or more student identifiers. The supAnnPerson attribute supannEtuId is also used to hold a student identification code.

FEIDE norEduPersonLIN is a local identity number that would usually be populated with student system number or employee system number. In order to make the attribute globally unique, directory designers are recommended to pre-pend the realm used in the eduPersonPrincipleName (normally the abbreviated institution name).

The hisMatriculationNumber contains a student ID unique within the higher education instituition.

Participants in both the LocalDomainPerson Survey and the DEEP Survey also reported the use of local attributes to record student identification numbers.

6.5.3 Unique Permanent Person Identification Code

Included in:
eduPerson – eduPersonPrincipalName
auEduPerson - auEduPersonID
Funet – recommends usage of eduPersonPrincipalName

Mentioned in:
LocalDomainPerson Survey – 47%
DEEP Survey – 72%

EduPerson defines the eduPersonPrincipalName as:

The "NetID" of the person for the purposes of inter-institutional authentication. Should be stored in the form of user@univ.edu, where univ.edu is the name of the local security domain.

If populated, the user should be able to authenticate with this identifier, using locally operated services. Local authentication systems should be able to adequately affirm (to both local and remote applications) that the authenticated principal is the person to whom this identifier was issued.

(EduPerson specification 200312)

The results of the LocalDomainPersonSurvey and the DEEP Survey indicate a fairly wide acceptance of an attribute for this purpose. The use of an attribute such as this lends itself to institutions that follow a persistent single-NetID or primary NetID model. For institutions that allow multiple NetID’s per person, allow NetID’s to be changed on demand or with some frequency, or allow NetID’s to be reissued this attribute may be problematic.

6.5.4 Federated Identification Code

Included in:
swissEduPerson - swissEduPersonUniqueId
plEduPerson – pleduPersonGId

Mentioned in:
DEEP Survey

The Swiss EduPerson object class defines the attribute swissEduPersonUniqueId to serve as a unique identifier for inter-institutional user identification. This is a case-insensitive single-valued string. The object class definition does not prescribe how the attribute will be populated to guarantee uniqueness within a federation.

The pleduPerson pleduPersonGId is defined as a "University person global identification number"; and is intended to be unique globally. The object class definition does not prescribe the algorithm that could be used to guarantee global uniqueness.

6.5.5 Local University Identification Code

Included in:
plEduPerson – pleduPersonLId
norEduPerson – norEduPersonLIN

Mentioned in:
LocalDomainPerson Survey

The pleduperson pleduPersonGId is defined as a "University person local identification number"; and is used for intra-institutional applications. The object class definition does not indicate how this attribute is created and maintained.

There is a scarcity of object classes that define a local identification code, so it is fair to assume that student system and employee system identification codes are more often used to meet the needs of local identification. This may be an indication of a continuing practice of traditional systems of record acting as identification hubs rather than an identity management system. As institutions implement identity management systems or enterprise resource planning (ERP) systems there may be growing usage of local identifiers that are generated in those systems.

The need for an ERP Identification Code was mentioned in the LocalDomainPerson Survey.

6.5.6 Directory Globally Unique Identification Code (GUID)

Included in:
RedIRIS – irisDnComp
hisPerson – hisUuid
SCHAC - schacUUID

Mentioned in:
LocalDomainPerson Survey

The RedIRIS object class defines the attribute irisDnComp as an attribute used in the formation of a directory object’s dn (distinguished name) which is used to "decouple"; the DN of the object from any of its actual attribute values. This provides the object with a primary key which is independent of the changing of attribute values over time and therefore can remain constant. This is especially beneficial as the changing of a directory object dn is an expensive operation and can become problematic when other directory entries use the dn to refer to a directory entry (groups, seeAlso references, etc.), and even moreso when the directory dn is provided to systems external to the directory (not a recommended practice, but one that proves hard to avoid.)

The HIS Person object class defines hisUuid as a single-valued attribute that records a unique identifier for a person at a higher education institution using the UUID format as specified in RFC 4122. This attribute contains an ID which is unique in space and time due to its construction algorithms and is intended to be usable in federations of higher educational institutions.

The SCHAC specification like hisPerson uses the same UUID format as defined in RFC 4122. In both cases the attribute is specified as a single valued attribute.

Readers considering the use of an external identifer for use as a directory GUID are encouraged to read section 4.5.2 of the Metadirectory Practices for Enterprise Directories in Higher Education white paper "Why Social Security Number (or Any Government identifer) is NOT a Good GUID"; published in October 2002 by the NSF Middleware Initiative.

6.5.7 Email aliases

Included in:
RedIRIS – irisMailAlternateAddress

Recommended in:
Funet

Mentioned in:
LocalDomainPerson Survey

The RedIRIS attribute irisMailAlternateAddress is used to record the valid email addresses (aliases) for a person’s institutional email account/mailbox. The standard mail attribute would contain a single one of these email addresses.

The Funet documentation recommends a local attribute be defined to record the valid email aliases for a person’s institutional email account.

6.5.8 Employee Identification Code

Included in:
auEduPerson – auEduPersonID
supAnnPerson – supannEmpId

Mentioned in:
hisPerson

The supannEmpId is used to hold the employee id from the Human Resources system.

The hisPerson specification proposes the usage of the standard attribute employeeNumber from inetOrgPerson for this purpose.

6.5.9 Kerberos Principal

Mentioned in:
LocalDomainPerson Survey
eduPerson - eduPersonPrincipalName

The use of MIT Kerberos as an authentication system is widely used by research institutions in the United States. It is not surprising then that the Kerberos principal for a user was mentioned by Local Domain Person respondents.

If one considers Kerberos to be a network service, then it is possible that a more generically defined attribute, such as the Network Services Identification Code (see section 6.5.11) in RedIRIS, irisUserPresenceId, could be used to store Kerberos principal as well as the unique identifiers for additional network services.

The eduperson eduPersonPrincipalName (EPPN) attribute may contain Kerberos Principal, but is not required to do so:

"EPPN looks like a Kerberos identifier (principal@realm). A site might choose to locally implement EPPN as Kerberos principals. However, this is not a requirement. A site can choose to do authentication in any way that is locally acceptable. Over time, many sites are expected to be using PKI for authentication; however, they may still be specifying identity in EPPN format.";

6.5.10 Network Operating System (NOS) Identification Code

Mentioned in:
LocalDomainPerson Survey (Microsoft Active Directory, Novell File Services)
DEEP Survey (Microsoft Passport)

With the usage of Microsoft Active Directory, Novell File Services, and other Network Operating Systems within higher education in the United States it is not surprising that Local Domain Survey respondents mentioned defining local attributes within their enterprise directories to store the identifiers of these systems. Such attributes can be useful when provisioning services, attributes, and group memberships across multiple directory platforms.

DEEP Survey respondents expressed the need for an attribute to store the Microsoft Passport Identification Code.

Like the Kerberos Principal, it is possible that these identifiers could be combined with a more generic attribute such as the RedIRIS irisUserPresenceId defined in section 6.5.11.

6.5.11 Network Services Identification Code

Included in:
RedIRIS – irisUserPresenceId

The RedIRIS irisUserPresenceId attribute is used to store a set of values related to a network presence. The values are stored in the URN (Uniform Resource Name) format, allowing globally unique precise single-valued identifiers. The examples provided in the RedIRIS object class description are:

urn:mace:rediris.es:presence:xmpp:pepe@im.univx.es
urn:mace:rediris.es:presence:sip:pepe@miweb.es
urn:mace:rediris.es:presence:sip:jose.perez@univx.es
urn:mace:rediris.es:presence:h323:pepe@miweb.es:8080;parametros
urn:mace:rediris.es:presence:skype:pepe.perez

With the use of URN’s a multi-valued attribute such as this may be an efficient way to address storing unique single-valued attributes for an individual that are used for access to network services and systems.

6.5.12 Prior Identification Codes

The changing of identifiers in systems can create significant problems for enterprise directory services. In order to ensure that linkages between systems are maintained Local Domain Person Survey respondents mentioned the need for a prior identification codes to be recorded in a directory attribute.

Mentioned in the local domain person survey.

6.5.13 Library Card Bar Code Number

Included in:
auEduPerson – auEduPersonLibraryBarCodeNumber

Library systems within higher-education often provide services to constituencies other than an students and employees. Those offered library resources – commonly referred to as library "patrons"; – are generally issued library cards that have a unique bar code. The library card is presented at material check-in/check-out and the bar code scanned to identify the patron. This technology is fairly ubiquitous in libraries because of the widespread use of bar codes to uniquely identify books and other library materials.

The auEduPerson auEduPersonLibraryBarCodeNumber captures the bar code on a patron’s library card.

6.5.14 Account DN (Distinguished Name)

Recommended in:
Funet

Mentioned in:
hisPerson

Used to record the directory dn’s (distinguished names) of accounts owned by the person. This is necessary in the Funet structure to support a person owning multiple accounts.

The hisPerson specification recommends using separate account entries below a person entry to record related accounts.

6.5.15 Login alias

Included in:
supAnnPerson – supannAliasLogin

The supannEmpId is used to allow an account owner to create a unique alias identifier for use when connecting to the institution’s information system. The possible benefit of such an attribute is that it may allow the individual the freedom of personalizing their login while not requiring the primary identifier of the person to be changed. It is not specified in the object class definition whether this login alias communicated publicly or is use solely as a convenience for the user login.

6.6 Entry Metadata / Administration Information

Entry metadata attributes are used to contain information about the entry itself, often its status, birth, and death. Such attributes can be critical to metadirectory processing. While the object classes discussed here were designed to accommodate person entries, metadata attributes can also be useful with non-person entry types such as groups. In such cases the metadata attributes may be best defined in an auxiliary object class independent of the person object class.

6.6.1 Expiration Date

Included in:
auEduPerson – auEduPersonExpiryDate
SCHAC - schacExpiryDate

Recommended in:
Funet

Mentioned in:
LocalDomainPerson Survey

The auEduPersonExpiryDate is used to store the date when the entry should expire. It is a single-valued attribute. The data format used is ISO 8601, which describes a date in the format YYYY-MM-DD. For example, the 17th day in March in the year 2006 is represented as "2006-03-17";.

Funet recommends a local attribute personExpDate which would contain "the date a person will be removed from the directory";.

The schacExpiryDate attribute is meant to contain "the date which the set of data is to be considered invalid (specifically, in what refers to rights and entitlements)". It uses the format YYYYMMDD as specified in RFC 3339 ("full-date") but without the dashes.

Neither auEduPerson, Funet, SCHAC nor the LocalDomainPerson survey distinguish between deleting an entry and removing access to an entry via attribute settings, both of which may occur when the entry is "expired";, so that this is left to decide by the local deployers of the directories.

6.6.2 Entry Owner / Maintainer

Included in:
supAnnPerson – supannParrainDN
AMBIX 2002 - dfnMaintainedBy

Mentioned in:
LocalDomainPerson Survey

In the supannPerson object class the supannParrainDN records the dn of the person responsible for the creation of the entry. This is required to be filled when the entry is not that of an institutional member (student, employee, or academic).

The AMBIX 2002 dfnMaintainedBy attribute is used to record the dn of the manager of the entry. The manager is allowed special access and write privileges.

The local domain person survey respondents used an entry owner attribute to record the dn of the owner of the entry. The owner may be granted special access and write privileges.

It is worth noting that it may be useful to distinguish between an entry owner or maintainer and an entry sponsor, where the owner or maintainer may be responsible for the correctness of some of the entry information, and the sponsor is responsible for allowing the entry to be created and retained.

6.6.3 Entry Creation Date

Used to record the date that the entry was created. While standard attributes may be maintained by the DSA to record the date and time an entry is created, it may be useful to have a separate manually maintained attribute for this purpose that can survive across directory reloads.

Mentioned in the local domain person survey.

6.6.4 Decay Date

Used to record the date that an entry enters the initial phase of deactivation. Sometimes referred to as a "decay"; period, in this state an entry may have reduced visibility and privileges, with an expectation that at the end of the period the entry will be completely deactivated.

Mentioned in the local domain person survey.

6.6.5 Expiration Countdown

Used to record an integer indicating the number of days remaining until an entry should expire. As time passes the countdown value is decreased, presumably via a scheduled process. An alternative approach would be to use an expiration date.

Mentioned in the local domain person survey.

6.6.6 Proxy

Used to hold the dn of a directory entry that has editing privilege over an entry but is not the owner. This could be used to delegate write privileges to a trusted person, such as an administrative assistant.

Mentioned in the local domain person survey.

6.6.7 Entry Type

Indicates the classification of entry: group, individual, object, or device.

Mentioned in the local domain person survey.

6.6.8 Administrator Comment

A free-form attribute used by the directory administrator or entry administrator to record restricted notations about the entry.

Mentioned in the local domain person survey.

6.6.9 Data Source

Included in:
AMBIX 2002 – dfnOriginalSource

Mentioned in:
LocalDomainPerson Survey

The AMBIX attribute dfnOriginalSource is used to record the authoritative data source of the entry. Allowable values are: self, which indicates the entry is self-entered; organization, which indicates that the entry data is provided by its home organization; historic, which indicates that the entry is legacy AMBIX data; and ambix, which indicates that the entry is maintained by the AMBIX directory managers themselves. While the AMBIX values are specific to the needs of the AMBIX directory, the concept of recording the primary authoritative system is a more general need.

In the local domain survey the need was expressed for an attribute to record the primary system of record of a directory entry.

6.6.10 Status

The DEEP survey mentions an accountStatus attribute to record whether an entry is active or disabled.

Mentioned in the DEEP survey.

6.6.11 Contact History

Included in:
AMBIX 2002 – dfnContactHistory

The AMBIX attribute dfnContactHistory is used to record the log of interaction between the client and AMBIX. This need is specific to the needs of the AMBIX directory and is not likely to be needed at institutions that maintain their own directory.

6.6.12 Entry COPA Classification Code

Included in:
RedIRIS - irisClassifCode

The RedIRIS irisClassifCode is used to store a set of values as URN’s indicating the position of the object defined by the entry in a classification hierarchy. This is used to facilitate searching the directory for related objects. The classification scheme used is described in the COPA document at <http://www.rediris.es/ldap/copa/copa-intro.en.pdf> and further described in an LDAP schema at <http://www.rediris.es/ldap/esquemas/copa.schema>.

urn:mace:rediris.es:<org>:classif:<classifName>:<classifVersion>:<classifValue>

6.7 Security Attributes and Keys

Security attributes are used to assist in authentication-related activities such as password self-reset. Security attributes that contain sensitive data such as passwords should be carefully protected, highly restricted, and probably encrypted using a one-way hash algorithm such as MD5 or SHA1 so that in the event that the directory server is compromised in an attack the attribute values are not useful to an attacker.

For comments regarding the standard attribute userPassword see section 6.12 Standard Attributes.

6.7.1 PIN

A PIN, or Personal Identification Number, is often used in place of a user password to verify identity.

If a PIN does not need to be retrieved and displayed, but only compared against user-entry, then consideration should be given to encrypting the PIN with a one-way hash and using the LDAP compare operation to compare a hash of the user entered value with the value in the directory.

Mentioned in the local domain person survey.

6.7.2 Challenge Question Pairs

Challenge Question Pairs (also called Question-Answer pairs) are an alternative to passwords and PIN’s for verifying identity, and are often used to allow end-users to reset their passwords when forgotten. Questions are usually designed to elicit a single unique or rare answer from a wide range of possible answers that is known only to the user and is unlikely to be forgotten. Examples include "name of first pet";, "city of birth";, "favorite singer";, "favorite author";.

Challenge Question systems may include fixed questions – where the questions are assigned, controlled questions – where the questions are partially fixed, or open questions – in which the user can author questions usually with guidance. Those designing a Challenge Question system should bear in mind that open question systems can be less secure that fixed question systems because questions created by the user may not have a widely varied answer domain or be readily evident (exp. "Favorite ice cream flavor";, "Eye color";).

Consideration should be given as to whether the answers in the pairs should be encrypted using a one-way hash. If so the LDAP compare operation could be used to determine whether a hash of the answers provided by the user matches a hash of the answers stored in the directory.

Mentioned in the local domain person survey.

6.7.3 Public Key

A public key is a cryptographic key (one part of a public-private key pair) used to facilitate document/email encryption and document signing.

The standard object class inetOrgPerson specifies the attribute type userCertificate (see section 6.12.31) for including signed public keys into the directory. Unsigned public keys should not be published.

Mentioned in the local domain person survey.

6.7.4 Library PIN

Included in:
auEduPerson – auEduPersonLibraryPIN

The auEduPerson auEdupersonLibraryPIN attribute is used in conjunction with the bar code from the library card to act as a password and ensure the identity of the patron. This allows patrons remote access to library services.

If a Library PIN does not need to be retrieved and displayed, but only compared against user-entry, then consideration should be given to encrypting the PIN with a one-way hash and using the LDAP compare operation to compare a hash of the user entered value with the value in the directory. The auEduPersonLibraryPIN attribute is not encrypted.

6.8 Confidentiality / Attribute Release (Visibility)

Often person lookup, termed "white pages";, is the first institutional service reliant upon an LDAP directory. Even if an LDAP directory is designed to support multiple applications, it is common practice for the directory to be accessible via LDAP and LDAPS queries and return limited information to institution members and other interested parties around the globe.

While there are risks to allowing direct LDAP protocol access to an institutional directory, such as directory harvesting or crawling (a technical term meaning to browse the directory content) to obtain email addresses, allowing LDAP access can simplify integration with LDAP-enabled products and reduce application integration time, as well as allowing institutional members the freedom to utilize many LDAP-enabled utilities and applications that are freely available.

Confidentiality attributes are commonly used to indicate whether an entry is visible publicly, visible only to affiliates of the institution, or not visible at all. In some cases only specific attributes, such as phone, address, and email address, are restricted, in other cases all attributes are restricted.

Confidentiality attributes may be provided to applications so that the applications can determine under what circumstances to display the attributes. Confidentiality attributes may also be used internally by the directory DSA to restrict the information returned by the server to LDAP queries, this can be done through directory access controls. DSA’s vary in their access control capabilities.

Access control information is used to define the accessibility of directory entries and attributes. Each DSA implements access controls in its own fashion and syntax. In X.500 these are referred to as Access Control Information. LDAP DSA’s may refer to them as access control lists (ACL’s) or access control instructions (ACI’s) or by other names. (Generally ACL’s are stored in a DSA configuration file, but not within the directory itself, whereas ACI’s are entries within the directory DIT.) Membership in a group may give a person or account the privileges necessary to see entries and attributes. Privileges may also be based on what type of authentication is used or what IP address the query is initiated from. The entries and attributes returned can be filtered so that only entries or attributes that meet certain criteria are returned. Confidentiality attributes can be used to dynamically customize and personalize the filters that are applied so that queries retrieve only the information that is allowed, which may vary from person to person.

There is nothing in the LDAP protocol itself to categorize or define restrictions, it is left to the directory architect to structure the access controls, define attributes that describe confidentiality preferences, and determine how those attributes are best populated and propagated to ensure that personal confidentiality and privacy is maintained.

Directory architects are encouraged to review their governmental privacy regulations and their institutional interpretation of those regulations. Not doing so can result in the inappropriate release of private information via the directory, which can seriously undermine institutional acceptance of the directory service.

For information on FERPA, the U.S. Family Educational Rights and Privacy Act, see <http://www.ed.gov/policy/gen/guid/fpco/ferpa/index.html>).

6.8.1 Restrict entry externally

Included in:
supAnnPerson – supannListeRouge
plEduPerson - pleduPersonPublic

Recommended in:
Funet

Mentioned in:
LocalDomainPerson Survey

The supAnnPerson supannListeRouge attribute is a single-valued attribute indicating that someone is (value "1";) or is not (value "0";) on the "red list";. For people who are on the red list directory information is not disclosed outside of the institution.

Similarly the plEduPerson pleduPersonPublic is used to determine if a person’s information can be released outside of the institution.

In neither supAnnPerson nor plEduPerson is it clear how "outside of the institution"; is determined. It can perhaps be assumed that this is either a reference to restricting access by IP address range, or by restricting access based on the ability of someone to prove community membership by authenticating to the directory.

The Funet documentation recommends an attribute for this purpose, and several respondents to the local domain person survey described similar locally defined attributes.

6.8.2 Private attributes / Attribute Release Policy

Included in:
RedIRIS – irisUserPrivateAttribute
SCHAC - schacUserPrivateAttribute

Recommended in:
Funet

Mentioned in:
DEEP Survey

The RedIRIS irisUserPrivateAttribute attribute is a multi-valued attribute used to store the names of attributes that should not be released. There is a specific list of approved attribute names: telephoneNumber, facsimileTelephoneNumber, mobile, postalAddress, postalCode, homePhone, homePostalAddress, mail, labeledURI, title, description, and jpegPhoto. In addition to these there are two special values: "all";, to indicate that all of the attributes in the approved list should be blocked from release; and "entry"; to indicate that the entire directory entry should be blocked from release. The object class definition indicates that blocking using this attribute affects all queries, not just queries initiated from outside the institution.

The SCHAC attribute userPrivateAttribute is very similar to the RedIRIS irisUserPrivateAttribute. The difference lies only in the fact that SCHAC defines no fixed list of possible values, but states: "The values are intended to be attribute type names and applies to the attribute and any subtypes of it for a given entity".

The Funet documentation recommends an attribute for this purpose, and DEEP survey respondents described similar locally defined attributes.

6.8.3 Attribute Indexing Policy

The DEEP survey mentions an indexingPolicy attribute which records:

"A definition of the policy under which the data of this entry should be collected for indexing. May be implemented as a list of (attribute, release policy) [pairs].";

This attribute level metadata seems to provide information regarding the circumstances under which specific attributes can be released for external indexing/storage.

Mentioned in the DEEP survey.

6.8.4 FERPA restriction

An attribute used to indicate that an entry has been restricted by the request of a student under the U.S. Family Educational Rights and Privacy Act (FERPA).

For information on FERPA, see <http://www.ed.gov/policy/gen/guid/fpco/ferpa/index.html>).

Mentioned in the local domain person survey.

6.8.5 Restrict Personal Information

An attribute used to indicate that a person’s "personal information"; is restricted. It is not clear whether "personal information"; refers to personal contact information (such as email address and telephone number), personal identifying information (such as name, date of birth, and government identification number), or both.

Mentioned in the local domain person survey.

6.8.6 Accept FERPA Responsibility

An attribute indicating that a person has completed required FERPA (U.S. Family Educational Rights and Privacy Act) training and has accepted legal responsibility for viewing FERPA protected student records. This attribute is paired with the "Accept FERPA Responsibility Date"; attribute described below.

Mentioned in the local domain person survey.

6.8.7 Accept FERPA Responsibility Date

An attribute indicating the date that a person has completed required FERPA (U.S. Family Educational Rights and Privacy Act) training and has accepted legal responsibility for viewing FERPA protected student records. This attribute is paired with the "Accept FERPA Responsibility"; attribute described above.

Mentioned in the local domain person survey.

6.8.8 Objection to Public View Period Date

Included in:
AMBIX 2002 – dfnEndOfObjectionPeriod

The AMBIX object class supports the concept of an objection period, during which a user has the opportunity to state an objection to having his/her personal information published. An objection will opt the person out of the directory. During the objection period the user data is not published, but when that period has expired, lacking an objection, approval for public release is assumed. The attribute dfnEndOfObjectionPeriod defines the time at which approval for public release is assumed.

6.8.9 Opt-in Status

Included in:
AMBIX 2002 – dfnOptInStatus

The AMBIX attribute dfnOptInStatus is a single-value integer attribute that indicates the degree to which a person has given explicit consent for their data to be released. The defined degrees of opt-in status are:

0. The person has not given explicit consent to release his/her information
1. The supplying organization has recorded the person giving explicit consent
2. The person has given explicit consent to release his/her information
3. The person is in the process of deciding whether consent will be given to release his/her information

6.8.10 Distribution

Included in:
AMBIX 2002 – dfnDistribution

The AMBIX attribute dfnDistribution is a single-value integer attribute that indicates the degree to which an entry should be visible. The defined degrees range from completely restricted (0) to completely unrestricted (4). The degrees of visibility are defined as:

0. Entry is not visible to anyone.
1. Entry is visible only to the owning organization as specified in the organization (o) section of the entry and requestor dn.
2. Entry is visible only to requestors within the country of origin as specified in the country (c) section of the entry and requestor dn.
3. Entry is visible within all states following the European Commission’s Directive on Data Protection (October, 1998).
4. Entry is visible without restriction.

6.9 Authorization, Entitlements

Authorization for services is generally implemented in LDAP directories either through the use of entry attributes or group memberships. (For information regarding LDAP groups please see the MACE Best Practices for Directory Groups document at <http://middleware.internet2.edu/dir/groups/>).

Applications such as Shibboleth (see <http://shibboleth.internet2.edu/>) can make use of entitlement attributes in an entry to provide authorization information to requesting services.

6.9.1 Authorized Applications

Respondents of the local domain person survey expressed the need to record the list of applications that a person is authorized to use: email, ERP, VPN, etc.

Mentioned in the local domain person survey.

6.9.2 Service Activity Statuses

Included in:
RedIRIS – irisUserStatus
SCHAC - schacUserStatus

The RedIRIS irisUserStatus attribute is a multi-valued attribute that stores URN’s which indicate the status that a person has to a specific service activity. This can be used to allow or disallow specific activities possible within a service. Examples are:

urn:mace:rediris.es:uma.es:userStatus:affiliation:expired
urn:mace:rediris.es:uma.es:userStatus:sendMail:expired
urn:mace:rediris.es:uma.es:userStatus:getMail:active

The schacUserStatus attribute is specified for exactly the same purpose, and just uses a different URN hierarchy: urn:SCHACPREFIX:status:<NSS> where <NSS> is a URN Namespace Specific String. The examples in the specification have "uma.es:affiliation:expired", "uma.es:sendMail:expired" and "uma.es:getMail:acitive" for such a NSS. The NSS can also contaion a parameter to represent the temporal validity of the status like in "ujl.si:webmail:active?ttl=20060531" indicating that the entitlement for using webmail at the domain ujl.si terminates on May 31, 2006.

6.9.3 Entitlements

Included in:
eduPerson - eduPersonEntitlement
Funet – recommends eduPersonEntitlement
norEduPerson – recommends the use of eduPersonEntitlement
RedIRIS – irisUserEntitlement

Mentioned in:
LocalDomainPerson Survey – 21% of respondents
DEEP Survey – 50% of respondents

The eduPersonEntitlement attribute is defined as a multi-valued "URI (either URN or URL) that indicates a set of rights to specific resources."; Examples are:

eduPersonEntitlement: urn:mace:washington.edu:confocalMicroscope
eduPersonEntitlement: http://xstor.com/contracts/HEd123

One benefit of the use of an entitlement attribute such as this is that it allows one attribute to record varying entitlements rather than having a different attribute for each entitlement. In order to use edupersonEntitlement an organization should register with MACE so that a unique URN root is assigned to their organization for their use. Information on the MACE URN registration process is available at the MACE URN Registry at <http://middleware.internet2