Internet2 Middleware - eduPerson Object Class Specification

Document: internet2-mace-dir-eduPerson200806
Home: http://www.educause.edu/eduperson/

https://www.internet2.edu/media/medialibrary/2013/09/04/internet2...

Internet2 Middleware Architecture
Committee for Education, Directory
Working Group (MACE-Dir)

Released: June 30, 2008
Copyright © 2006-2008 by Internet2
and/or the respective authors

Comments to: i2mi-info@internet2.edu

eduPerson Object Class Specification (200806)
Status of this document
The (200806) version of the eduPerson object class specification is described in this document. Thisversion is appropriate for adoption in a production enterprise directory service environment.

0. Table of Contents
1. Introduction
1.1 General Remarks
1.2 Identifier Concepts
1.3 Scope
2 eduPerson Object Class and Attributes
2.1 eduPerson Object Class Definition
2.2 eduPerson Attribute Definitions
2.2.1. eduPersonAffiliation
2.2.2. eduPersonEntitlement
2.2.3. eduPersonNickname
2.2.4. eduPersonOrgDN
2.2.5. eduPersonOrgUnitDN
2.2.6. eduPersonPrimaryAffiliation
2.2.7. eduPersonPrimaryOrgUnitDN
2.2.8. eduPersonPrincipalName
2.2.9. eduPersonScopedAffiliation
2.2.10. eduPersonTargetedID
2.2.11. eduPersonAssurance
3. Comments on Other Common Person Attributes
3.1. audio
3.2. cn (commonName)
3.3. description
3.4. displayName

1 of 39

3.10. jpegPhoto
3.11. localityName
3.12. labeledURI
3.13. mail3.14. manager
3.15. mobile
3.16. o (organizationName)
3.17. ou (organizationalUnitName)
3.18. pager
3.19. postalAddress
3.20. postalCode3.21. postOfficeBox
3.22. preferredLanguage
3.23. seeAlso
3.24. sn (surname)3.25. st (stateOrProvinceName)
3.26. street
3.27. telephoneNumber
3.28. title
3.29. uid
3.30. uniqueIdentifier
3.31. userCertificate
3.32. userPassword

3/5/20, 12:16 PM

Internet2 Middleware - eduPerson Object Class Specification

3.5. facsimileTelephoneNumber
3.6. givenName
3.7. homePhone
3.8. homePostalAddress
3.9. initials

https://www.internet2.edu/media/medialibrary/2013/09/04/internet2...

3.33. userSMIMECertificate
3.34. x500uniqueIdentifier
4. Change Log
5. Acknowledgments

1. Introduction
1.1 General Remarks
The portions of the eduPerson specification intended to support LDAP operations include an auxiliary
object class for campus directories designed to facilitate communication among higher education
institutions. It consists of a set of data elements or attributes about individuals within higher education,
along with recommendations on the syntax and semantics of the data that may be assigned to those
attributes. The eduPerson attributes are found in the next section.
It is recommended that person entries have the person, organizationalPerson and inetOrgPerson object
classes defined. The former two are included in X.521 (2001) and inetOrgPerson is included in RFC 2798
and based in part on RFC 4512. EduPerson attributes would be brought into the person entry as
appropriate from the auxiliary eduPerson object class. This represents a change from eduPerson 1.0 where
the object class was defined as structural, and inherited from other person classes. Sites that have
implemented eduPerson 1.0 should not experience any operational difficulties due to the object classdifference between structural and auxiliary. If, however, one were to export an LDIF file of person entries
from an eduPerson 1.0-based directory, the LDIF would have to be tweaked before being imported into a
directory implementing post 1.0 versions to add the person, orgPerson and inetOrgPerson object classes tothe entry.
Attributes from the person, organizationalPerson and inetOrgPerson classes are listed alphabetically in thesecond section of this document. The purpose of listing them is primarily as a convenience to enterprise
directory designers, but in some cases notes were added to clarify aspects of meaning or usage in the
education community beyond what can be found in the original standards documents.
If widespread agreement and implementation of this object class in campus directories is achieved, abroad and powerful new class of higher education applications can be more easily deployed. Additional
information on eduPerson, including LDIF for implementing the object class and attributes, is available atits home on the web: http://www.educause.edu/eduperson/.
1.2 Identifier Concepts
Among the most common and useful personal attributes are identifiers. An identifier is an information
element that is specifically designed to distinguish each entry from its peers in a particular set. Whilealmost any information in an entry may contribute to differentiating it from similar entries, identifiers areintentionally designed to do this. It is common for entries to contain several different identifiers, used for
different purposes or generated by different information sources. Identifiers have a number ofcharacteristics that help to determine appropriate usage. The following comments are offered to help
clarify some points of definition for these various identifiers. These concepts are also referred to invarious attribute descriptions.
2 of 39

3/5/20, 12:16 PM

Internet2 Middleware - eduPerson Object Class Specification

https://www.internet2.edu/media/medialibrary/2013/09/04/internet2...

Persistence
Persistence is a measure of the length of time during which an identifier can be reliably associated with aparticular principal. A short-term identifier might be associated with an application session. A permanent
identifier is associated with its entry for its lifetime.
PrivacySome identifiers are designed to preserve the principal's privacy and inhibit the ability of multiple
unrelated recipients from correlating principal activity by comparing values. Such identifiers are therefore
REQUIRED to be opaque, having no particular relationship to the principal's other identifiers. Note that
this definition permits sharing of the identifier among multiple recipients if they are deemed by theattribute provider to be equivalent to a single recipient for privacy purposes.
Uniqueness
Unique identifiers are those which are unique within the namespace of the identity provider and thenamespace of the service provider(s) for whom the value is created. A globally-unique identifier isintended to be unique across all instances of that attribute in any provider.
Reassignment
Many identifiers do not specifically guarantee that a given value will never be reused. Reuse would mean
assigning an identifier value to one principal, and then assigning the same value to a different principal atsome point in the (possibly distant) future. There will be some sets of requirements that dictate a strict noreassignment policy.
Human Palatability
An identifier that is human-palatable is intended to be rememberable and reproducible by typical humanusers, in contrast to identifiers that are, for example, randomly generated sequences of bits.
1.3 Scope
The eduPersonPrincipalName and eduPersonScopedAffiliation attribute definitions found below bothmake use of the concept of scope. The meaning of scope is specific to the attribute to which it is attachedand can vary from one attribute to another. In the case of these two attributes, scope conveys theadministrative domain or security domain within which the affiliation or principal name holds.

2 eduPerson Object Class and Attributes
2.1 eduPerson Object Class Definition
All eduPerson-defined attribute names are prefaced with "eduPerson." The eduPerson auxiliary object
class contains all of them as "MAY" attributes:( 1.3.6.1.4.1.5923.1.1.2

3 of 39

3/5/20, 12:16 PM

Internet2 Middleware - eduPerson Object Class Specification

https://www.internet2.edu/media/medialibrary/2013/09/04/internet2...

NAME 'eduPerson'
AUXILIARY
MAY ( eduPersonAffiliation $eduPersonNickname $eduPersonOrgDN $eduPersonOrgUnitDN $eduPersonPrimaryAffiliation $eduPersonPrincipalName $eduPersonEntitlement $eduPersonPrimaryOrgUnitDN $eduPersonScopedAffiliation $eduPersonTargetedID $eduPersonAssurance))

2.2 eduPerson Attribute Definitions
Attributes in the following section were newly defined for eduPerson. Each entry specifies the version inwhich the attribute was first defined.
2.2.1. eduPersonAffiliation (defined in eduPerson 1.0); OID: 1.3.6.1.4.1.5923.1.1.1.1
RFC 4512 definition( 1.3.6.1.4.1.5923.1.1.1.1
NAME 'eduPersonAffiliation'
DESC 'eduPerson per Internet2 and EDUCAUSE'EQUALITY caseIgnoreMatchSYNTAX '1.3.6.1.4.1.1466.115.121.1.15' )Application utility class: standard; # of values: multi

4 of 39

3/5/20, 12:16 PM

Internet2 Middleware - eduPerson Object Class Specification

https://www.internet2.edu/media/medialibrary/2013/09/04/internet2...

Definition
Specifies the person's relationship(s) to the institution in broad categories such as student, faculty, staff,
alum, etc. (See controlled vocabulary).
Permissible values
faculty, student, staff, alum, member, affiliate, employee, library-walk-in
Notes
If there is a value in eduPersonPrimaryAffiliation, that value should be stored here as well.
The list of allowed values in the current version of the object class is CERTAINLY incomplete. We feltthat any additional values should come out of discussions with the stakeholder communities. Any agreedupon additional values will be included as part of the later versions of eduPerson.
We also deliberately avoided including a value such as "other" or "misc" because it would be semanticallyequivalent to "none of the above." To indicate "none of the above," for a specific person, leave theattribute empty.
"Member" is intended to include faculty, staff, student, and other persons with a basic set of privilegesthat go with membership in the university community (e.g., they are given institutional email and calendar
accounts). It could be glossed as "member in good standing of the university community.""Affiliate" is intended to apply to people with whom the university has dealings, but to whom no general
set of "community membership" privileges are extended.
"Library-walk-in:" This value is intended to facilitate the handling of a fairly widely encounteredagreement between an institution and licensed resource providers that e-resources may be made accessible
to students, faculty, staff and library walk-ins. This term originally indicated people who were physicallypresent in a library facility. In recent years the library walk-in provision has been extended to cover othercases such as library users on the campus network, or those using on-campus workstations. Licensed
resource providers have often been willing to interpret their contracts with licensees to accept this broader
definition of "library-walk-in," though specific terms may vary. Under appropriate licensing terms, it isvalid to assert an affiliation of "library-walk-in" for members of this broader class of users. The affiliation"library-walk-in" is independent of any other affiliation value. In other words, having the affiliation"library-walk-in" has no effect, positive or negative, on any of the other defined affiliation values.
Similarly, no other affiliation value implies or precludes the affiliation "library-walk-in."Semantics
Each institution decides the criteria for membership in each affiliation classification.
A reasonable person should find the listed relationships commonsensical.
Example applications for which this attribute would be usefulwhite pages, controlling access to resources

5 of 39

3/5/20, 12:16 PM

Internet2 Middleware - eduPerson Object Class Specification

https://www.internet2.edu/media/medialibrary/2013/09/04/internet2...

Example (LDIF Fragment)
eduPersonAffiliation: faculty
Syntax: directoryString; Indexing: pres,eq
2.2.2. eduPersonEntitlement (defined in eduPerson 200210); OID: 1.3.6.1.4.1.5923.1.1.1.7
RFC 4512 definition( 1.3.6.1.4.1.5923.1.1.1.7
NAME 'eduPersonEntitlement'
DESC 'eduPerson per Internet2 and EDUCAUSE'EQUALITY caseExactMatchSYNTAX '1.3.6.1.4.1.1466.115.121.1.15' )Application utility class: extended; # of values: multiDefinition
URI (either URN or URL) that indicates a set of rights to specific resources.
Notes
A simple example would be a URL for a contract with a licensed resource provider. When a principal's
home institutional directory is allowed to assert such entitlements, the business rules that evaluate aperson's attributes to determine eligibility are evaluated there. The target resource provider does not learn
characteristics of the person beyond their entitlement. The trust between the two parties must be
established out of band. One check would be for the target resource provider to maintain a list of
subscribing institutions. Assertions of entitlement from institutions not on this list would not be honored.
See the first example below.
URN values would correspond to a set of rights to resources based on an agreement across the relevant
community. MACE (Middleware Architecture Committee for Education) affiliates may opt to registerwith MACE as a naming authority, enabling them to create their own URN values. See the second
example below.
The driving force behind the definition of this attribute has been the MACE Shibboleth project.
Shibboleth defines an architecture for inter-institutional sharing of web resources subject to access
controls. For further details, see the project's web pages at http://shibboleth.internet2.edu/.
Examples:eduPersonEntitlement: http://xstor.com/contracts/HEd123
eduPersonEntitlement: urn:mace:washington.edu:confocalMicroscope
6 of 39

3/5/20, 12:16 PM

Internet2 Middleware - eduPerson Object Class Specification

https://www.internet2.edu/media/medialibrary/2013/09/04/internet2...

Example applications for which this attribute would be usefulcontrolling access to resources
Example (LDIF Fragment)
eduPersonEntitlement: urn:mace:washington.edu:confocalMicroscope
Syntax: directoryString; Indexing: No recommendation
2.2.3. eduPersonNickname (defined in eduPerson 1.0); OID: 1.3.6.1.4.1.5923.1.1.1.2
RFC 4512 definition( 1.3.6.1.4.1.5923.1.1.1.2
NAME 'eduPersonNickname'
DESC 'eduPerson per Internet2 and EDUCAUSE'EQUALITY caseIgnoreMatchSYNTAX '1.3.6.1.4.1.1466.115.121.1.15' )Application utility class: standard; # of values: multiDefinition
Person's nickname, or the informal name by which they are accustomed to be hailed.
Notes
Most often a single name as opposed to displayName which often consists of a full name. Useful for userfriendly search by name. As distinct from the cn (common name) attribute, the eduPersonNickname
attribute is intended primarily to carry the person's preferred nickname(s). E.g., Jack for John, Woody for
Durwood, JR for Joseph Robert.
Carrying this in a separate attribute makes it relatively easy to make this a self-maintained attribute If it
were merely one of the multiple values of the cn attribute, this would be harder to do. A review step by a
responsible adult is advisable to help avoid institutionally embarrasing values being assigned to this
attribute by would-be malefactors!
Application developers can use this attribute to make directory search functions more "user friendly."
Example applications for which this attribute would be usefulwhite pages
Example (LDIF Fragment)

7 of 39

3/5/20, 12:16 PM

Internet2 Middleware - eduPerson Object Class Specification

https://www.internet2.edu/media/medialibrary/2013/09/04/internet2...

eduPersonNickname: Spike
Syntax: directoryString; Indexing: pres,eq,sub
2.2.4. eduPersonOrgDN (defined in eduPerson 1.0); OID: 1.3.6.1.4.1.5923.1.1.1.3
RFC 4512 definition( 1.3.6.1.4.1.5923.1.1.1.3
NAME 'eduPersonOrgDN'
DESC 'eduPerson per Internet2 and EDUCAUSE'EQUALITY distinguishedNameMatchSYNTAX '1.3.6.1.4.1.1466.115.121.1.12' SINGLE-VALUE )Application utility class: core; # of values: single
Definition
The distinguished name (DN) of the directory entry representing the institution with which the person isassociated.
Notes
With a distinguished name, the client can do an efficient lookup in the institution's directory to find out
more about the organization with which the person is associated.
Cn (common name), sn (surname, family name) and this attribute, eduPersonOrgDN, are the three
attributes satisfying the "core" application utility class of eduPerson.
Semantics
The directory entry pointed to by this dn should be represented in the X.521(2001) "organization" object
class The attribute set for organization is defined as follows:o (Organization Name, required}
Optional attributes include:
description
localeAttributeSet
postalAttributeSet
telecommunicationsAttributeSet

8 of 39

3/5/20, 12:16 PM

Internet2 Middleware - eduPerson Object Class Specification

https://www.internet2.edu/media/medialibrary/2013/09/04/internet2...

businessCategory
seeAlsosearchGuide
userPassword
Note that labeledURI is not included in the above list. We recommend adding the labeledURIObject
auxiliary object class to the organization object pointed to by this dn, which endows it with a labeledURI
attribute. Some directory servers implement this object class by default. For others, the schema may need
to be extended using this definition (using the syntax specified by RFC 4512):( 1.3.6.1.4.1.250.3.15 NAME 'labeledURIObject' SUP top AUXILIARY
MAY labeledURI )Example applications for which this attribute would be usefulwhite pages
Example (LDIF Fragment)
eduPersonOrgDN: o=Hogwarts, dc=hsww, dc=wiz
Syntax: distinguishedName; Indexing: No recommendation
2.2.5. eduPersonOrgUnitDN (defined in eduPerson 1.0); OID: 1.3.6.1.4.1.5923.1.1.1.4
RFC 4512 definition( 1.3.6.1.4.1.5923.1.1.1.4
NAME 'eduPersonOrgUnitDN'
DESC 'eduPerson per Internet2 and EDUCAUSE'EQUALITY distinguishedNameMatchSYNTAX '1.3.6.1.4.1.1466.115.121.1.12' )Application utility class: standard; # of values: multiDefinition
The distinguished name(s) (DN) of the directory entries representing the person's Organizational Unit(s).
May be multivalued, as for example, in the case of a faculty member with appointments in multiple
departments or a person who is a student in one department and an employee in another.
Notes

9 of 39

3/5/20, 12:16 PM

Internet2 Middleware - eduPerson Object Class Specification

https://www.internet2.edu/media/medialibrary/2013/09/04/internet2...

With a distinguished name, the client can do an efficient lookup in the institution's directory for
information about the person's organizational unit(s).
Semantics
The directory entry pointed to by this dn should be represented in the X.521(2001) "organizational unit"
object class. In addition to organizationalUnitName, this object class has the same optional attribute set as
the organization object class:ou (Organization Unit Name, required) Note that O is NOT required.
Optional attributes include:
description
localeAttributeSet
postalAttributeSet
telecommunicationsAttributeSet
businessCategory
seeAlsosearchGuide
userPassword
Note that labeledURI is not included in the above list. We recommend adding the labeledURIObject
auxiliary object class to the organization object pointed to by this dn, which endows it with a labeledURI
attribute. Some directory servers implement this object class by default. For others, the schema may need
to be extended using this definition (using the syntax specified by RFC 4512):( 1.3.6.1.4.1.250.3.15 NAME 'labeledURIObject' SUP top AUXILIARY
MAY labeledURI )Example applications for which this attribute would be usefulwhite pages
Example (LDIF Fragment)
eduPersonOrgUnitDN: ou=Potions, o=Hogwarts, dc=hsww, dc=wiz
Syntax: distinguishedName; Indexing: eq
2.2.6. eduPersonPrimaryAffiliation (defined in eduPerson 1.0);

10 of 39

3/5/20, 12:16 PM

Internet2 Middleware - eduPerson Object Class Specification

https://www.internet2.edu/media/medialibrary/2013/09/04/internet2...

OID: 1.3.6.1.4.1.5923.1.1.1.5
RFC 4512 definition( 1.3.6.1.4.1.5923.1.1.1.5
NAME 'eduPersonPrimaryAffiliation'
DESC 'eduPerson per Internet2 and EDUCAUSE'EQUALITY caseIgnoreMatchSYNTAX '1.3.6.1.4.1.1466.115.121.1.15' SINGLE-VALUE )Application utility class: standard; # of values: single
Definition
Specifies the person's PRIMARY relationship to the institution in broad categories such as student,
faculty, staff, alum, etc. (See controlled vocabulary).
Permissible values
faculty, student, staff, alum, member, affiliate, employee, library-walk-in
Notes
Appropriate if the person carries at least one of the defined eduPersonAffiliations. The choices of values
are the same as for that attribute.
Think of this as the affiliation one might put on the name tag if this person were to attend a generalinstitutional social gathering. Note that the single-valued eduPersonPrimaryAffiliation attribute assigns
each person in the directory into one and only one category of affiliation. There are application scenarios
where this would be useful.
The list of allowed values in the current version of the object class is CERTAINLY incomplete. We feltthat any additional values should come out of discussions with the stakeholder communities. Any agreedupon additional values will be included as part of future versions of eduPerson.
We also deliberately avoided including a value such as "other" or "misc" because it is semanticallyequivalent to "none of the above." To indicate "none of the above," for a specific person, leave theattribute unpopulated.
"Member" is intended to include faculty, staff, student, and other persons granted a basic set of privilegesthat go with membership in the university community (e.g., library privileges). It could be glossed as"member in good standing of the university community.""Affiliate" is intended to apply to people with whom the university has dealings, but to whom no general
set of "community membership" privileges are extended.

11 of 39

3/5/20, 12:16 PM

Internet2 Middleware - eduPerson Object Class Specification

https://www.internet2.edu/media/medialibrary/2013/09/04/internet2...

"Library-walk-in:" This value is intended to facilitate the handling of a fairly widely encounteredagreement between an institution and licensed resource providers that e-resources may be made accessible
to students, faculty, staff and library walk-ins. This term originally indicated people who were physicallypresent in a library facility. In recent years the library walk-in provision has been extended to cover othercases such as library users on the campus network, or those using on-campus workstations. Licensed
resource providers have often been willing to interpret their contracts with licensees to accept this broader
definition of "library-walk-in," though specific terms may vary. Under appropriate licensing terms, it isvalid to assert an affiliation of "library-walk-in" for members of this broader class of users. The affiliation"library-walk-in" is independent of any other affiliation value. In other words, having the affiliation"library-walk-in" has no effect, positive or negative, on any of the other defined affiliation values.
Similarly, no other affiliation value implies or precludes the affiliation "library-walk-in."Semantics
Each institution decides the criteria for membership in each affiliation classification.
A reasonable person should find the listed relationships commonsensical.
Example applications for which this attribute would be usefulcontrolling access to resources
Example (LDIF Fragment)
eduPersonPrimaryAffiliation: student
Syntax: directoryString; Indexing: pres,eq,sub
2.2.7. eduPersonPrimaryOrgUnitDN (defined in eduPerson 200210); OID: 1.3.6.1.4.1.5923.1.1.1.8
RFC 4512 definition( 1.3.6.1.4.1.5923.1.1.1.8
NAME 'eduPersonPrimaryOrgUnitDN'
DESC 'eduPerson per Internet2 and EDUCAUSE'EQUALITY distinguishedNameMatchSYNTAX '1.3.6.1.4.1.1466.115.121.1.12' SINGLE-VALUE )Application utility class: extended; # of values: single
Definition
The distinguished name (DN) of the directory entry representing the person's primary Organizational
Unit(s).
Notes
12 of 39

3/5/20, 12:16 PM

Internet2 Middleware - eduPerson Object Class Specification

https://www.internet2.edu/media/medialibrary/2013/09/04/internet2...

Appropriate if the person carries at least one of the defined eduPersonOrgUnitDN. The choices of values
are the same as for that attribute.
Semantics
Each institution populating this attribute decides the criteria for determining which organization unit entry
is the primary one for a given individual.
Example applications for which this attribute would be usefulwhite pages
Example (LDIF Fragment)
eduPersonPrimaryOrgUnitDN: ou=Music Department, o=Notre Dame, dc=nd, dc=edu
Syntax: distinguishedName; Indexing: eq
2.2.8. eduPersonPrincipalName (defined in eduPerson 1.0); OID: 1.3.6.1.4.1.5923.1.1.1.6
RFC 4512 definition( 1.3.6.1.4.1.5923.1.1.1.6
NAME 'eduPersonPrincipalName'
DESC 'eduPerson per Internet2 and EDUCAUSE'EQUALITY caseIgnoreMatchSYNTAX '1.3.6.1.4.1.1466.115.121.1.15' SINGLE-VALUE )Application utility class: standard; # of values: single
Definition
The "NetID" of the person for the purposes of inter-institutional authentication. It should be represented in
the form "user@scope" where scope defines a local security domain. Multiple "@" signs are notrecommended, but in any case, the first occurrence of the "@" sign starting from the left is to be taken as
the delimiter between components. Thus, user identifier is to the left, security domain to the right of thefirst "@". This parsing rule conforms to the POSIX "greedy" disambiguation method in regular expression
processing. When the scope is a registered domain name, the corresponding registrant organization is tobe taken as the scope. For example, francis@trinity.edu would imply that the identity behind the ePPN
has the "NetID" "francis" at the instituion of higher education that registered itself with the domain name"trinity.edu." If other value styles are used, their semantics will have to be profiled by the parties involved.
Each value of scope defines a namespace within which the assigned principal names are unique. Given
this rule, no pair of eduPersonPrincipalName values should clash. If they are the same, they refer to thesame principal within the same administrative domain.

13 of 39

3/5/20, 12:16 PM

Internet2 Middleware - eduPerson Object Class Specification

https://www.internet2.edu/media/medialibrary/2013/09/04/internet2...

Notes
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.
The initial intent is to use this attribute within the Shibboleth project, http://shibboleth.internet2.edu/.
However, it has quickly become clear that a number of other applications could also make good use ofthis attribute (e.g. H.323 video, chat software, etc). eduPersonPrincipalName (EPPN) would be used asfollows: A resource owner, A, would look at B's directory entry to discover B's EPPN. A would then tell
the local authorization system that B's EPPN is allowed to use the resource. When B tries to access theresource, the application (or access control infrastructure) would validate B's identity, check with the local
authorization system to ensure that B has been granted the appropriate access privileges, and then either
grant or deny access.
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.
Likewise, EPPN should NOT be confused with the user's published email address, although the twovalues may be the same. Some sites have chosen to make the user portion of email addresses and security
principals the same character string; other sites have chosen not to do this. Even when they appear to be
the same, they are used in different subsystems and for different purposes, and there is no requirement thatthey have to remain the same.
The uid attribute of the user's object within the local white pages directory may also contain a login id, asecurity principal; some systems (eg NDS) may put a login id in the cn attribute. These attributes aredefined within objectclasses that are universal. Unfortunately, their use is not prescribed in a sufficiently
precise and consistent manner for use with cross domain authorization. A variety of systems already makeconflicting use of these attributes; consequently, we have defined this new attribute.
An assumption is that EPPNs are managed on an enterprise basis by the univ of univ.edu. A particular
EPPN is assigned solely to the associated user; it is not a security principal identifier shared by more than
one person. Lastly, each EPPN is unique within the local security domain.
How long, if ever, before a formerly assigned EPPN is reassigned to a differrent individual is an
institutional decision. Some institutions will choose never to reassign EPPNs. Others may opt for a
relatively short hiatus before reassignment. While this complicates the work of the relying parties, it isunavoidable given institutional autonomy. See MACE best practice documents on identifiers for further
discussion of these issues.
This attribute should prove useful in creating some applications that are based on currently deployedtechnologies and on code that does not currently use LDAP or require a PKI. This attribute should help tocreate a framework to foster interesting inter-institutional collaborations between sites that use different
technologies. In short, this attribute provides a foundation for yet another abstraction layer.
Example applications for which this attribute would be useful

14 of 39

3/5/20, 12:16 PM

Internet2 Middleware - eduPerson Object Class Specification

https://www.internet2.edu/media/medialibrary/2013/09/04/internet2...

controlling access to resources
Example (LDIF Fragment)
eduPersonPrincipalName: hputter@hsww.wiz
Syntax: directoryString; Indexing: pres,eq,sub
2.2.9. eduPersonScopedAffiliation (defined in eduPerson (200312)); OID: 1.3.6.1.4.1.5923.1.1.1.9
RFC 4512 definition( 1.3.6.1.4.1.5923.1.1.1.9
NAME 'eduPersonScopedAffiliation'
DESC 'eduPerson per Internet2 and EDUCAUSE'EQUALITY caseIgnoreMatchSYNTAX '1.3.6.1.4.1.1466.115.121.1.15' )Application utility class: standard; # of values: multiDefinition
Specifies the person's affiliation within a particular security domain in broad categories such as student,
faculty, staff, alum, etc. The values consist of a left and right component separated by an "@" sign. The
left component is one of the values from the eduPersonAffiliation controlled vocabulary.This right-handside syntax of eduPersonScopedAffiliation intentionally matches that used for the right-hand side values
for eduPersonPrincipalName since both identify a security domain. Multiple "@" signs are notrecommended, but in any case, the first occurrence of the "@" sign starting from the left is to be taken as
the delimiter between components. Thus, user identifier is to the left, security domain to the right of thefirst "@". This parsing rule conforms to the POSIX "greedy" disambiguation method in regluar expression
processing.
Permissible values
See controlled vocabulary for eduPersonAffiliation. Only these values are allowed to the left of the "@"sign. The values to the right of the "@" sign should indicate a security domain.
Notes
Consumers of eduPersonScopedAffiliation will have to decide whether or not they trust values of this
attribute. In the general case, the directory carrying the eduPersonScopedAffiliation is not the ultimate
authoritative speaker for the truth of the assertion. Trust must be established out of band with respect toexchanges of this attribute value.
Semantics

15 of 39

3/5/20, 12:16 PM

Internet2 Middleware - eduPerson Object Class Specification

https://www.internet2.edu/media/medialibrary/2013/09/04/internet2...

An eduPersonScopedAffiliation value of "x@y" is to be interpreted as an assertion that the person inwhose entry this value occurs holds an affiliation of type "x" within the security domain "y."Example applications for which this attribute would be usefulwhite pages, controlling access to resources
Example (LDIF Fragment)
eduPersonScopedAffiliation: faculty@cs.berkeley.edu
Syntax: directoryString; Indexing: pres,eq
2.2.10. eduPersonTargetedID (defined in eduPerson 200312); OID: 1.3.6.1.4.1.5923.1.1.1.10
Application utility class: extended; # of values: multiDefinition
A persistent, non-reassigned, privacy-preserving identifier for a principal shared between a pair of
coordinating entities, denoted by the SAML 2 architectural overview [1] as identity provider and service
provider (or a group of service providers). An identity provider uses the appropriate value of this attribute
when communicating with a particular service provider or group of service providers, and does not revealthat value to any other service provider except in limited circumstances.
Notes
While this attribute might not be stored as such in a typical Directory Service, it may be produced by a
Directory Service. In any case, it is defined here for potential use in other service contexts such as
Security Assertion Markup Language (SAML) assertions.
EduPersonTargetedID values should not be reassigned.
Persistence
eduPersonTargetedID does not require a specific lifetime, but the association SHOULD be maintained
longer than a single user interaction and long enough to be useful as a key for a particular service that isconsuming it. Protocols might also be used to refresh (or "roll-over") an identifier to maintain the user's
privacy by communicating such changes to service providers to avoid a loss of service. See [2] for an
example of such a protocol.
PrivacyThis attribute is designed to preserve the principal's privacy and inhibit the ability of multiple unrelated
services from correlating principal activity by comparing values. It is therefore REQUIRED to be opaque,having no particular relationship to the principal's other identifiers, such as a username or
eduPersonPrincipalName. It SHOULD be considerably difficult for an observer to guess the value thatwould be returned to a given service provider.

16 of 39

3/5/20, 12:16 PM

Internet2 Middleware - eduPerson Object Class Specification

https://www.internet2.edu/media/medialibrary/2013/09/04/internet2...

It MAY be a pseudorandom value generated and stored by the identity provider, or MAY be derived fromsome function over the service provider's identity and other principal-specific input(s), such as a serial
number or UUID assigned by the identity provider.
It MUST NOT exceed 256 characters in length.
UniquenessA value of this attribute is intended only for consumption by a specific audience of applications (often asingle one). Values of this attribute therefore MUST be unique within the namespace of the identity
provider and the namespace of the service provider(s) for whom the value is created. The value is"qualified" by these two namespaces and need not be unique outside them. Logically, the attribute value ismade up of the triple of an identifier, the identity provider, and the service provider(s). [2] suggests a
possible naming scheme for such qualifiers based on URIs.
Reassignment
A distinguishing feature of this attribute is that it prohibits re-assignment. Since the values are opaque,there is no meaning attached to any particular value beyond its identification of the principal. Therefore
particular values created by an identity provider MUST NOT be re-assigned such that the same value
given to a particular service provider refers to two different principals at different points in time.
[1] http://www.oasis-open.org/committees/download.php/7521/[2] http://www.oasis-open.org/committees/download.php/10627/
Example applications for which this attribute would be usefulService providers or directory-enabled applications with the need to maintain a persistent but opaqueidentifier for a given user for purposes of personalization or record-keeping.
Identity or service providers or directory-enabled applications with the need to link an external account toan internal account maintained within their own system. This attribute is often used to represent a longterm account linking relationship between an identity provider and service provider(s). Note that such a
service provider might itself also be an identity provider.
2.2.11. eduPersonAssurance (defined in eduPerson 200806); OID: 1.3.6.1.4.1.5923.1.1.1.11
RFC 4512 definition( 1.3.6.1.4.1.5923.1.1.1.11
NAME 'eduPersonAssurance'
DESC 'eduPerson per Internet2 and EDUCAUSE'EQUALITY caseExactMatchSYNTAX '1.3.6.1.4.1.1466.115.121.1.15' )17 of 39

3/5/20, 12:16 PM

Internet2 Middleware - eduPerson Object Class Specification

https://www.internet2.edu/media/medialibrary/2013/09/04/internet2...

Application utility class: extended; # of values: multiDefinition
Set of URIs that assert compliance with specific standards for identity assurance.
Notes
This multi-valued attribute represents identity assurance profiles (IAPs), which are the set of standards
that are met by an identity assertion, based on the Identity Provider's identity management processes, thetype of authentication credential used, the strength of its binding, etc. An example of such a standard is
the InCommon Federation's proposed IAPs.
Those establishing values for this attribute should provide documentation explaining the semantics of thevalues.
As a multi-valued attribute, relying parties may receive multiple values and should ignore unrecognizedvalues.
The driving force behind the definition of this attribute is to enable applications to understand the various
strengths of different identity management systems and authentication events and the processes andprocedures governing their operation and to be able to assess whether or not a given transaction meets therequirements for access.
Example applications for which this attribute would be useful
Determining strength of asserted identity for on-line transactions, especially those involving more thanminimal institutional risk resulting from errors in authentication.
A system supporting access to grants management in order to provide assurance for financial transactions.
Example (LDIF Fragment)
eduPersonAssurance: urn:mace:incommon:IAQ:sample
eduPersonAssurance: http://idm.example.org/LOA#sample
Syntax: directoryString; Indexing: No recommendation
3. Comments on Other Common Person Attributes
The attributes in the following section are from other standard object classes or attribute definitions. It is
not a complete list of such attributes, but in any case where the eduPerson working group considered thatsome comment was needed to clarify the meaning or utility of an attribute, it can be found here. For
details on the syntax and other aspects of these attributes, see the appropriate standards documents.
3.1. audio (defined in RFC2798, inetOrgPerson); OID: 0.9.2342.19200300.100.1.55
Application utility class: no recommendation;

18 of 39

3/5/20, 12:16 PM

Internet2 Middleware - eduPerson Object Class Specification

https://www.internet2.edu/media/medialibrary/2013/09/04/internet2...

Definition
RFC 1274 notes that the proprietary format they recommend is "interim" only.
Notes
Avoid. Not clearly defined, no defacto standard.
3.2. cn (commonName, included in person); OID: 2.5.4.3
Application utility class: core; # of values: multiDefinition
Common name.
According to RFC 4519, "The 'cn' ('commonName' in X.500) attribute type contains names of an object.
Each name is one value of this multi-valued attribute. If the object corresponds to a person, it is typicallythe person's full name."
Notes
Required. One of the two required attributes in the person object class (the other is sn). As such it is oneof three recommended "core application utility" attributes. The third is eduPersonOrgDN.
With eduPersonOrgDN and cn, the client knows the person's name and the distinguished name of theorganization with which he/she is associated. The latter could help them find a directory entry for the
person's organization.
This attribute is often overloaded in the sense that many applications act as if this were "their" attribute,and therefore add values to this attribute as they see fit. Because of that it is impossible to give a precise
and accurate definition of what this field means.
Example applications for which this attribute would be usefulall
Example (LDIF Fragment)
cn: Mary Francis Xavier
3.3. description (included in person); OID: 2.5.4.13
Application utility class: standard; # of values: multiDefinition
Open-ended; whatever the person or the directory manager puts here. According to RFC 4519, "The19 of 39

3/5/20, 12:16 PM

Internet2 Middleware - eduPerson Object Class Specification

https://www.internet2.edu/media/medialibrary/2013/09/04/internet2...

'description' attribute type contains human-readable descriptive phrases about the object. Each description
is one value of this multi-valued attribute."
Notes
Can be anything.
Example applications for which this attribute would be usefulwhite pages
Example (LDIF Fragment)
description: A jolly good felon
3.4. displayName (defined in RFC2798, inetOrgPerson); OID: 2.16.840.1.113730.3.1.241
Application utility class: standard; # of values: single
Definition
The name(s) that should appear in white-pages-like applications for this person.
From RFC 2798 description: "preferred name of a person to be used when displaying entries."
Notes
Cn (common name) is multi-valued and overloaded to meet the needs of multiple applications.
displayName is a better candidate for use in DoD white pages and configurable email clients.
Example applications for which this attribute would be usefulwhite pages, email client
Example (LDIF Fragment)
displayName: Jack Dougherty
3.5. facsimileTelephoneNumber (defined in RFC 4519, included in orgPerson); OID: 2.5.4.23
Application utility class: extended; # of values: multiDefinition
According to RFC 4519: "The 'facsimileTelephoneNumber' attribute type contains telephone numbers(and, optionally, the parameters) for facsimile terminals. Each telephone number is one value of thismulti-valued attribute."

20 of 39

3/5/20, 12:16 PM

Internet2 Middleware - eduPerson Object Class Specification

https://www.internet2.edu/media/medialibrary/2013/09/04/internet2...

Notes
Attribute values should comply with the ITU Recommendation E.123 [E.123]: i.e., "+44 71 123 4567."
Semantics
A fax number for the directory entry.
Example applications for which this attribute would be usefulwhite pages
Example (LDIF Fragment)
facsimileTelephoneNumber: +44 71 123 4567
3.6. givenName (defined in RFC 4519, inetOrgPerson); OID: 2.5.4.42
Application utility class: standard; # of values: multiDefinition
From RFC 4519 description:"The 'givenName' attribute type contains name strings that are the part of aperson's name that is not their surname. Each string is one value of this multi-valued attribute."
Example applications for which this attribute would be useful
Example (LDIF Fragment)
givenName: Stephen
3.7. homePhone (defined in RFC2798, inetOrgPerson); OID: 0.9.2342.19200300.100.1.20
Application utility class: extended; # of values: multiDefinition
From RFC 1274 description: "The [homePhone] attribute type specifies a home telephone number
associated with a person."
Notes
Attribute values should comply with the ITU Recommendation E.123 [E.123]: i.e., "+44 71 123 4567."
In RFC 1274, this was originally called homeTelephoneNumber.
Example applications for which this attribute would be useful

21 of 39

3/5/20, 12:16 PM

Internet2 Middleware - eduPerson Object Class Specification

https://www.internet2.edu/media/medialibrary/2013/09/04/internet2...

white pages
Example (LDIF Fragment)
homePhone: +1 608 555 1212
3.8. homePostalAddress (defined in RFC2798, inetOrgPerson); OID: 0.9.2342.19200300.100.1.39
Application utility class: extended; # of values: multiDefinition
From RFC 1274 description: "The Home postal address attribute type specifies a home postal address foran object. This should be limited to up to 6 lines of 30 characters each."
Semantics
Home address. OrgPerson has a PostalAddress that complements this attribute.
Example applications for which this attribute would be usefulwhite pages
Example (LDIF Fragment)
homePostalAddress: 1212 Como Ave.$Midton, SD 45621
3.9. initials (defined in RFC 4519, inetOrgPerson); OID: 2.5.4.43
Application utility class: extended; # of values: multiDefinition
From RFC 4519 description: "The 'initials' attribute type contains strings of initials of some or all of anindividual's names, except the surname(s). Each string is one value of this multi-valued attribute."
Example applications for which this attribute would be useful
Example (LDIF Fragment)
initials: f x
3.10. jpegPhoto (defined in RFC2798, inetOrgPerson); OID: 0.9.2342.19200300.100.1.60
Application utility class: extended; # of values: multiDefinition

22 of 39

3/5/20, 12:16 PM

Internet2 Middleware - eduPerson Object Class Specification

https://www.internet2.edu/media/medialibrary/2013/09/04/internet2...

Follow inetOrgPerson definition of RFC 2798: "Used to store one or more images of a person using theJPEG File Interchange Format [JFIF]."
Semantics
A smallish photo in jpeg format.
Example applications for which this attribute would be usefulwhite pages
3.11. l (localityName, defined in RFC 4519, included in orgPerson); OID: 2.5.4.7
Application utility class: extended; # of values: multiDefinition
locality name.
According to RFC 4519, "The 'l' ('localityName' in X.500) attribute type contains names of a locality orplace, such as a city, county, or other geographic region. Each name is one value of this multi-valued
attribute."
X.520(2000) reads: "The Locality Name attribute type specifies a locality. When used as a component of adirectory name, it identifies a geographical area or locality in which the named object is physically locatedor with which it is associated in some other important way."
Example applications for which this attribute would be usefulwhite pages
Example (LDIF Fragment)l: Hudson Valley
3.12. labeledURI (defined in RFC2798, inetOrgPerson); OID: 1.3.6.1.4.1.250.1.57
Application utility class: extended; # of values: multiDefinition
Follow inetOrgPerson definition of RFC 2079: "Uniform Resource Identifier with optional label."Notes
Commonly a URL for a web site associated with this person. Good candidate for a self-maintained
attribute. Note, however, that the vocabulary for the label portion of the value is not standardized.

23 of 39

3/5/20, 12:16 PM

Internet2 Middleware - eduPerson Object Class Specification

https://www.internet2.edu/media/medialibrary/2013/09/04/internet2...

Note from RFC 2079: "The labeledURI attribute type has the caseExactString syntax (since URIs arecase-sensitive) and it is multivalued. Values placed in the attribute should consist of a URI (at the present
time, a URL) optionally followed by one or more space characters and a label. Since space characters are
not allowed to appear un-encoded in URIs, there is no ambiguity about where the label begins. At thepresent time, the URI portion must comply with the URL specification.
Multiple labeledURI values will generally indicate different resources that are all related to the X.500
object, but may indicate different locations for the same resource.
The label is used to describe the resource to which the URI points, and is intended as a friendly name fit
for human consumption. This document does not propose any specific syntax for the label part. In somecases it may be helpful to include in the label some indication of the kind and/or size of the resource
referenced by the URI.
Note that the label may include any characters allowed by the caseExactString syntax, but that the use of
non-IA5 (non-ASCII) characters is discouraged as not all directory clients may handle them in the samemanner. If non-IA5 characters are included, they should be represented using the X.500 conventions, not
the HTML conventions (e.g., the character that is an "a" with a ring above it should be encoded using theT.61 sequence 0xCA followed by an "a" character; do not use the HTML escape sequence "&aring").
Examples of labeledURI Attribute Values
An example of a labeledURI attribute value that does not include a label:
ftp://ds.internic.net/rfc/rfc822.txt
An example of a labeledURI attribute value that contains a tilde character in the URL (special charactersin a URL must be encoded as specified by the URL document [1]). The label is "LDAP Home Page":
http://www.umich.edu/%7Ersug/ldap/ LDAP Home Page
Another example. This one includes a hint in the label to help the user realize that the URL points to a
photo image.
http://champagne.inria.fr/Unites/rennes.gif Rennes [photo]"
Semantics
Most commonly a URL for a web site associated with this person
Example applications for which this attribute would be usefulwhite pages
Example (LDIF Fragment)labeledURI: http://www.hsww.wiz/%7Eputter Harry's home page

24 of 39

3/5/20, 12:16 PM

Internet2 Middleware - eduPerson Object Class Specification

https://www.internet2.edu/media/medialibrary/2013/09/04/internet2...

3.13. mail (defined in RFC 4524, inetOrgPerson); OID: 0.9.2342.19200300.100.1.3
Application utility class: standard; # of values: multiDefinition
From RFC 4524: The 'mail' (rfc822mailbox) attribute type holds Internet mail addresses in Mailbox[RFC2821] form (e.g., user@example.com).
Notes
Preferred address for the "to:" field of email to be sent to this person. Usually of the form
localid@univ.edu. Though multi-valued, there is often only one value.
Some mail clients will not display entries unless the mail attribute is populated. See the LDAP Recipe forfurther guidance on email addresses, routing, etc. (http://middleware.internet2.edu/dir/docs/ldaprecipe.htm).
Semantics
Preferred address for the "to:" field of email to be sent to this person.
Example applications for which this attribute would be usefulwhite pages, email client
Example (LDIF Fragment)
mail: dumbledore@hsww.wiz
3.14. manager (defined in RFC 4524, inetOrgPerson); OID: 0.9.2342.19200300.100.1.10
Application utility class: no recommendation; # of values: multiDefinition
From RFC 4524: "The 'manager' attribute specifies managers, by distinguished name, of the person (orentity).
Notes
This attribute carries the DN of the manager of the person represented in this entry.
Example applications for which this attribute would be usefulwhite pages
Example (LDIF Fragment)

25 of 39

3/5/20, 12:16 PM

Internet2 Middleware - eduPerson Object Class Specification

https://www.internet2.edu/media/medialibrary/2013/09/04/internet2...

manager: uid=twilliams, ou=people, dc=hobart, dc=edu
3.15. mobile (defined in RFC 4524, inetOrgPerson); OID: 0.9.2342.19200300.100.1.41
Application utility class: extended; # of values: multiDefinition
From RFC 4524: "The 'mobile' (mobileTelephoneNumber) attribute specifies mobile telephone numbers(e.g., "+1 775 555 6789") associated with a person (or entity)."Notes
cellular or mobile phone number. Attribute values should comply with the ITU Recommendation E.123[E.123]: i.e., "+44 71 123 4567."
Semantics
cellular or mobile phone number.
Example applications for which this attribute would be usefulwhite pages
Example (LDIF Fragment)
mobile: +47 22 44 66 88
3.16. o (organizationName, defined in RFC2798, inetOrgPerson); OID: 2.5.4.10
Application utility class: standard; # of values: multiDefinition
Standard name of the top-level organization (institution) with which this person is associated.
Notes
Likely only one value.
Meant to carry the TOP-LEVEL organization name. Do not use this attribute to carry school college
names.
Example applications for which this attribute would be usefulwhite pages
Example (LDIF Fragment)

26 of 39

3/5/20, 12:16 PM

Internet2 Middleware - eduPerson Object Class Specification

https://www.internet2.edu/media/medialibrary/2013/09/04/internet2...

o: St. Cloud State
3.17. ou (organizationalUnitName, included in orgPerson); OID: 2.5.4.11
Application utility class: standard; # of values: multiDefinition
Organizational unit(s). According to X.520(2000), "The Organizational Unit Name attribute type specifies
an organizational unit. When used as a component of a directory name it identifies an organizational unit
with which the named object is affiliated.
The designated organizational unit is understood to be part of an organization designated by an
OrganizationName [o] attribute. It follows that if an Organizational Unit Name attribute is used in a
directory name, it must be associated with an OrganizationName [o] attribute.
An attribute value for Organizational Unit Name is a string chosen by the organization of which it is apart."
Example applications for which this attribute would be usefulwhite pages
Example (LDIF Fragment)
ou: Faculty Senate
3.18. pager (defined in RFC 4524, inetOrgPerson); OID: 0.9.2342.19200300.100.1.42
Application utility class: extended; # of values: multiDefinition
From RFC 4524: "The 'pager' (pagerTelephoneNumber) attribute specifies pager telephone numbers (e.g.,"+1 775 555 5555") for an object."
Notes
Attribute values should comply with the ITU Recommendation E.123 [E.123]: i.e., "+44 71 123 4567."
Semantics
pager number.
Example applications for which this attribute would be usefulwhite pages

27 of 39

3/5/20, 12:16 PM

Internet2 Middleware - eduPerson Object Class Specification

https://www.internet2.edu/media/medialibrary/2013/09/04/internet2...

Example (LDIF Fragment)
pager: +1 202 555 4321
3.19. postalAddress (included in orgPerson); OID: 2.5.4.16
Application utility class: extended; # of values: multiDefinition
Campus or office address. inetOrgPerson has a homePostalAddress that complements this attribute.
X.520(2000) reads: "The Postal Address attribute type specifies the address information required for thephysical postal delivery to an object."
Notes
Campus or office address. inetOrgPerson has a homePostalAddress that complements this attribute.
Semantics
Campus or office address. X.520(2000) reads: "The Postal Address attribute type specifies the address
information required for the physical postal delivery to an object."Example applications for which this attribute would be usefulwhite pages
Example (LDIF Fragment)
postalAddress: P.O. Box 333$Whoville, WH 99999
3.20. postalCode (included in orgPerson); OID: 2.5.4.17
Application utility class: extended; # of values: multiDefinition
Follow X.500(2001): "The postal code attribute type specifies the postal code of the named object. If this
attributevalue is present, it will be part of the object's postal address." Zip code in USA, postal code for othercountries.
Notes
ZIP code in USA, postal code for other countries.
Semantics

28 of 39

3/5/20, 12:16 PM

Internet2 Middleware - eduPerson Object Class Specification

https://www.internet2.edu/media/medialibrary/2013/09/04/internet2...

Zip code in USA, postal code for other countries.
Example applications for which this attribute would be usefulwhite pages
Example (LDIF Fragment)
postalCode: 54321
3.21. postOfficeBox (RFC 4519, included in orgPerson); OID: 2.5.4.18
Application utility class: extended; # of values: multiDefinition
From RFC 4519: "The 'postOfficeBox' attribute type contains postal box identifiers that a Postal Service
uses when a customer arranges to receive mail at a box on the premises of the Postal Service. Each postal
box identifier is a single value of this multi-valued attribute."
Notes Example applications for which this attribute would be usefulwhite pages
Example (LDIF Fragment)
postOfficeBox: 109260
3.22. preferredLanguage (defined in RFC2798, inetOrgPerson); OID: 2.16.840.1.113730.3.1.39
Application utility class: extended; # of values: single
Definition
Follow inetOrgPerson definition of RFC 2798: "preferred written or spoken language for a person."
Permissible values (if controlled)
See RFC2068 and ISO 639 for allowable values in this field. Esperanto, for example is EO in ISO 639,
and
RFC2068 would allow a value of en-US for US English.
Example applications for which this attribute would be usefulwhite pages
Example (LDIF Fragment)

29 of 39

3/5/20, 12:16 PM

Internet2 Middleware - eduPerson Object Class Specification

https://www.internet2.edu/media/medialibrary/2013/09/04/internet2...

preferredLanguage: EO
3.23. seeAlso (RFC 4519, included in person); OID: 2.5.4.34
Application utility class: standard; # of values: multiDefinition
From RFC 4519: The 'seeAlso' attribute type contains the distinguished names of objects that are related
to the subject object. Each related object name is one value of this multi-valued attribute."
Semantics
The distinguished name of another directory entry.
Example applications for which this attribute would be usefulwhite pages
Example (LDIF Fragment)
seeAlso: cn=Department Chair, ou=physics, o=University of Technology, dc=utech, dc=ac, dc=uk
3.24. sn (surname, RFC 4519, included in person); OID: 2.5.4.4
Application utility class: core; # of values: multiDefinition
Surname or family name. From RFC 4519: "The 'sn' ('surname' in X.500) attribute type contains namestrings for the family names of a person. Each string is one value of this multi-valued attribute."
Notes
Required. One of the two required attributes in the person object class from which eduPerson derives (theother is cn). As such it is one of eduPerson's three "core application utility" attributes. The third is
eduPersonOrgDN.
If the person has a multi-part surname (whether hyphenated or not), store both 1) the whole surname
including hyphens if present and 2) each component of a hyphenated surname as a separate value in thismulti-valued attribute. That yields the best results for the broadest range of clients doing name searches.
Example applications for which this attribute would be usefulall
Example (LDIF Fragment)

30 of 39

3/5/20, 12:16 PM

Internet2 Middleware - eduPerson Object Class Specification

https://www.internet2.edu/media/medialibrary/2013/09/04/internet2...

sn: Carson-Smith
sn: Carson
sn: Smith
3.25. st (stateOrProvinceName, RFC 4519, included in orgPerson); OID: 2.5.4.8
Application utility class: extended; # of values: multiDefinition
Abbreviation for state or province name.
Format: The values should be coordinated on a national level. If well-known shortcuts exist, like the twoletter state abbreviations in the US, these abbreviations are preferred over longer full names.
From RFC 4519: "The 'st' ('stateOrProvinceName' in X.500) attribute type contains the full names ofstates or provinces. Each name is one value of this multi-valued attribute."
Permissible values (if controlled)
For states in the United States, U.S. Postal Service set of two-letter state name abbreviations.
Notes
State or province name. While RFC 4519 specifies use of the "full name," it is customary to use the U.S.
Postal Service set of two-letter state name abbreviations for states in the U.S. and, as noted in thedefinition, other nationally coordinated official abbreviations are preferred for province names.
Semantics
Standard two-letter abbreviations for U.S. state names, other standards based abbreviations for provinces
where available.
Example applications for which this attribute would be usefulwhite pages
Example (LDIF Fragment)
st: IL
3.26. street (RFC 4519, included in orgPerson); OID: 2.5.4.9
Application utility class: extended; # of values: multiDefinition
From RFC 4519: "The 'street' ('streetAddress' in X.500) attribute type contains site information from a

31 of 39

3/5/20, 12:16 PM

Internet2 Middleware - eduPerson Object Class Specification

https://www.internet2.edu/media/medialibrary/2013/09/04/internet2...

postal address (i.e., the street name, place, avenue, and the house number). Each street is one value of thismulti-valued attribute."
Example applications for which this attribute would be usefulwhite pages
Example (LDIF Fragment)
street: 303 Mulberry St.
3.27. telephoneNumber (included in person); OID: 2.5.4.20
Application utility class: standard; # of values: multiDefinition
Office/campus phone number. Attribute values should comply with the ITU Recommendation E.123[E.123]: i.e., "+44 71 123 4567."
Example applications for which this attribute would be usefulwhite pages
Example (LDIF Fragment)
telephoneNumber: +1 212 555 1234
3.28. title (RFC 4519, included in orgPerson); OID: 2.5.4.12
Application utility class: extended; # of values: multiDefinition
From RFC 4519: "The 'title' attribute type contains the title of a person in their organizational context.
Each title is one value of this multi-valued attribute."
Notes
No controlled vocabulary, may contain anything.
Example applications for which this attribute would be usefulwhite pages
Example (LDIF Fragment)
title: Assistant Vice-Deputy for Redundancy Reduction

32 of 39

3/5/20, 12:16 PM

Internet2 Middleware - eduPerson Object Class Specification

https://www.internet2.edu/media/medialibrary/2013/09/04/internet2...

3.29. uid (defined in RFC 4519, inetOrgPerson); OID: 0.9.2342.19200300.100.1.1
Application utility class: standard; # of values: multiDefinition
From RFC 4519: "The 'uid' ('userid' in RFC 1274) attribute type contains computer system login names
associated with the object. Each name is one value of this multi-valued attribute."
Notes
Likely only one value. See the extensive discussion in the "LDAP Recipe"(http://middleware.internet2.edu/dir/docs/ldap-recipe.htm).
A number of off-the-shelf directory-enabled applications make use of this inetOrgPerson attribute, notalways consistently.
RFC 1274 uses the longer name 'userid'.
Example applications for which this attribute would be usefulcontrolling access to resources
Example (LDIF Fragment)
uid: gmettes
3.30. uniqueIdentifier (RFC 4524); OID: 0.9.2342.19200300.100.1.44
Application utility class: no recommendation; # of values:
Definition
From RFC 4524: "The 'uniqueIdentifier' attribute specifies a unique identifier for an object represented in
the Directory. The domain within which the identifier is unique and the exact semantics of the identifier
are for local definition. For a person, this might be an institution- wide payroll number. For an
organizational unit, it might be a department code."
Notes
Avoid. UniqueIdentifier should not be reused because 1) it is not included in any of the commonly
implemented object classes and 2) iPlanet documentation states that its value is "assigned by the server."
Relying on it for other purposes would be overloading of intended uses, something we avoid on principle
since iPlanet is a commonly used directory server.
3.31. userCertificate (defined in RFC2798, inetOrgPerson); OID: 2.5.4.36

33 of 39

3/5/20, 12:16 PM

Internet2 Middleware - eduPerson Object Class Specification

https://www.internet2.edu/media/medialibrary/2013/09/04/internet2...

Application utility class: extended; # of values: multiDefinition
A user's X.509 certificate
Notes
RFC 2256 states that this attribute is to be stored and requested in the binary form, as'userCertificate;binary.'
Note that userSMIMECertificate is in binary syntax (1.3.6.1.4.1.1466.115.121.1.5) whereas theuserCertificate attribute is in certificate syntax (1.3.6.1.4.1.1466.115.121.1.8).
Example applications for which this attribute would be usefulemail clients, controlling access to resources
3.32. userPassword (RFC 4519, included in person); OID: 2.5.4.35
Application utility class: extended; # of values: multiDefinition
This attribute identifies the entry's password and encryption method in the following format:{encryption method}encrypted password.
Notes
The user pw is hidden, and is used in the bind operation in LDAP. The bind operation must be done over
SSL to avoid sending clear text passwords over the wire or through the air.
Example applications for which this attribute would be usefulcontrolling access to resources
3.33. userSMIMECertificate (defined in RFC2798, inetOrgPerson); OID: 2.16.840.1.113730.3.1.40
Application utility class: extended; # of values: multiDefinition
An X.509 certificate specifically for use in S/MIME applications (see RFCs 2632, 2633 and 2634).
Notes
An X.509 certificate specifically for use in S/MIME applications. According to RFC 2798, "If available,

34 of 39

3/5/20, 12:16 PM

Internet2 Middleware - eduPerson Object Class Specification

https://www.internet2.edu/media/medialibrary/2013/09/04/internet2...

this attribute is preferred over the userCertificate attribute for S/MIME applications."
RFC 2798 states that this attribute is to be stored and requested in the binary form, as'userSMIMECertificate;binary.'
Semantics
Following userSMIMECertificate in RFC 2798, "A PKCS#7 [RFC2315] SignedData."
Example applications for which this attribute would be usefulemail clients
3.34. x500uniqueIdentifier (defined in RFC2798, inetOrgPerson); OID: 2.5.4.45
Application utility class: no recommendation; # of values:
Definition
Defined originally in X.509(96) and included in RFC2256.
Notes
Avoid. X500UniqueIdentifier syntax is specified as bit string, and that is not likely to be a good fit for
many of the institutional attribute value choices, especially as part of the DN.
4. Change Log
This section lists changes that have been made from version to version of eduPerson.
The following list shows changes in version (200806) relative to version (200712).
1. In section 1.1, changed RFC2256 to RFC 4512.
2. In section 1.1, removed paragraph explaining upgrade process from 200312 to 200604.
3. In section 1.2, removed reference to an "upcoming MACE-Dir documenton information models"
4. In section 2.1, restructured attribute list to one per line for improved readability and added
attribute eduPersonAssurance
5. Add named anchors and linked Table of Contents. This is document enhancement, not a
specification change.
6. Added subsection 2.2.11 "eduPersonAssurance".
7. In all subsections of 2.2, changed "RFC 2252 definition" to "RFC 4512 definition".
8. In section 2.2.5, changed reference from "RFC2252" to "RFC 4512".
35 of 39

3/5/20, 12:16 PM

Internet2 Middleware - eduPerson Object Class Specification

https://www.internet2.edu/media/medialibrary/2013/09/04/internet2...

9. In section 3.2, 3.3, changed reference from "RFC2256" to "RFC 4519" and updated text.
10. In section 3.5, added reference to RFC 4519 and updated text. Added notes section.
11. In section 3.6, changed reference from "RFC2798" to "RFC 4519" and updated text.
12. In section 3.7, added note "Attribute values should comply with the ITU Recommendation
E.123 [E.123]: i.e., "+44 71 123 4567.""
13. In section 3.9, changed reference from "RFC2798" and "RFC 2256" to "RFC 4519" andupdated text.
14. In section 3.11, changed reference from "RFC 2256" to "RFC 4519" and updated text.
15. In section 3.13, changed reference from "RFC2798" to "RFC 4524" and updated text.
16. In section 3.13, changed wording of "Likely to be only one value" to "Though multi-valued,
there is often only one value."
17. In section 3.13, updated location of the LDAP Recipe from "http://www.duke.edu/~gettes/giia/ldap-recipe" to "http://middleware.internet2.edu/dir/docs/ldap-recipe.htm".
18. In section 3.13, removed notation about RFC 1274 and rfc822Mailbox
19. In section 3.14, 3.15, changed reference from "RFC2798" to "RFC 4524" and updated text.
20. In section 3.15, removed notation regarding RFC 1274. Added note "Attribute values should
comply with the ITU Recommendation E.123 [E.123]: i.e., "+44 71 123 4567.""
21. In section 3.18, changed reference from "RFC2798" to "RFC 4524" and updated text. Removed
notation regarding RFC 1274. Added notation that ITU Recommendation E.123 should be used.
22. In section 3.21, changed to RFC 4519 and removed redundant notation.
23. In section 3.23, added reference to RFC 4519
24. In section 3.24, added reference to RFC 4519. Changed example to show recommended usage
with a hyphenated name.
25. In section 3.25, added reference to RFC 4519
26. In section 3.26, changed reference from RFC 2256 to RFC 4519 and updated text.
27. In section 3.27, changed internation format recommendation to "Attribute values should comply
with the ITU Recommendation E.123 [E.123]: i.e., "+44 71 123 4567."".
28. In section 3.28, added reference to RFC 4519 and updated text.
29. In section 3.29, changed reference from "RFC2798" to "RFC 4519" and update text.

36 of 39

3/5/20, 12:16 PM

Internet2 Middleware - eduPerson Object Class Specification

https://www.internet2.edu/media/medialibrary/2013/09/04/internet2...

30. In section 3.29, updated location of the LDAP Recipe from "http://www.duke.edu/~gettes/giia/ldap-recipe" to "http://middleware.internet2.edu/dir/docs/ldap-recipe.htm".
31. In section 3.30, changed reference from "RFC1274" to "RFC 4524" and updated text.
32. In section 3.32, added reference to RFC 4519. Text was not updated because it is significantly
different than RFC 4519.
33. In section 4, added indention to all subsections to improve readability and added breakline after
section.
34. In section 2.2.2 change EQUALITY caseIgnoreMatch to caseExactMatch, matching the
eduPerson LDIF.
35. In sections 2.2.2 and 2.2.4 specify indexing as "No recommendation". No indexing
recommendation has ever been specified for these attributes, this language is just for clarification.
The following list shows changes in version (200712) relative to version (200604).
1. In section 2.2.1, "eduPersonAffiliation" and section 2.2.6, "eduPersonPrimaryAffiliation," added"library-walk-in" to Permissible values
2. In section 2.2.1, "eduPersonAffiliation" and section 2.2.6, "eduPersonPrimaryAffiliation," added
the new paragraph explaining "library-walk-in."
The following list shows changes in version (200604) relative to version (200312).
1. Definition of eduPersonPrincipalName and eduPersonScopedAffiliation modified. A "first match
from the left" rule is invoked such that the two components are the substrings found on either sideof the first "@" sign.
2. Definition of eduPersonTargetedID revised to align with current recommended practice in
Shibboleth applications.
The following list shows changes in version (200312) relative to version (200210).
1. EduPersonScopedAffiliation added.
2. Substring indexing recommendation removed from eduPersonAffiliation
3. New section added for attributes not included in the eduPerson object class. Includes one
attribute in this version: eduPersonTargetedID.
4. Introduction altered to include description of this new section.
5. Comments on identifiers and their properties consolidated into an introductory note,correesponding edits in the eduPersonTargetedID section.
6. Recommendation on the "sn" attribute amended to suggest including the whole surname as well

37 of 39

3/5/20, 12:16 PM

Internet2 Middleware - eduPerson Object Class Specification

https://www.internet2.edu/media/medialibrary/2013/09/04/internet2...

as the components in cases of hyphenated surnames.
7. Various typographical errors corrected.
The following lists the changes (other than typographical corrections) that were made between version 1.0of the eduPerson object class definition and version 200210.
1. Document Status and Introductory sections have been added.
2. Attention called to the change of the eduPerson object class from structural to auxiliary
3. Subsection headings for empty fields deleted..
4. Indexing recommendations for the eduPerson attributes has been improved and corrected inmany cases.
5. The syntax notes for the eight eduPerson attributes have been corrected and they now match the
LDIF file. DirectoryString is used for five eduPerson attributes. The other three contain
distinguished names, so they use distinguishedName syntax.
6. RFC2252 style definitions have been included for the eduPerson object class itself and for eachof the eduPerson attributes.
7. Two new attributes are defined: eduPersonEntitlement and eduPersonPrimaryOrgUnitDN.
8. The notes on the c (country) attribute have been deleted since c is not contained in any of thereferenced object classes.
9. Notes have been added for several additional attributes from the standard person object classes.
These include audio, manager, title, uniqueIdentifier and x500UniqueIdentifier.
10. Notes on userCertificate and userSMIMECertificate have been rewritten.
11. Clarifying text added in sections 1.3 and 2.2.8
5. Acknowledgments
MACE members and others who contributed many hours to the definition of this object class include Rob
Banz, Tom Barton, Brendan Bellina, Scott Cantor, Steven Carmody, Michael Gettes, Paul Hill, Ken
Klingenstein, RL "Bob" Morgan, Todd Piket, David Wasley, Ann West, Ignacio Coupeau, Leif Johannson,
Hallvard Furuseth, Diego Lopez, Roland Hedberg, Ingrid Melve, Alistair Young, Peter Gietz, Mark Jones,
Nathan Dors, Tom Scavo, Lynn McRae, Chad La Joie, Katheryn Strojny, Kathryn Huxtable, Digant
Kasundra and others. The editor of the MACE-Dir working group, Keith Hazelton, would like to thankthem and the many others who helped bring this effort to completion. This version also had the benefit ofcomments from several of the NMI Testbed institutions. Three that deserve special mention are Georgia
State University, the University of Alabama at Birmingham and the University of Michigan. Special
thanks to Internet2 staff members for their invaluable assistance, Ben Chinowsky, Renee Frost, Lisa
Hogeboom, Nate Klingenstein, Steve Olshansky, Jessica Bibbee, and Ellen Vaughan.

38 of 39

3/5/20, 12:16 PM

Internet2 Middleware - eduPerson Object Class Specification

https://www.internet2.edu/media/medialibrary/2013/09/04/internet2...

This material is based in whole or in part on work supported by EDUCAUSE, Internet2, and the National
Science Foundation under the NSF Middleware Initiative - NSF 02-028, Grant No. ANI-0123937. Any
opinions, findings and conclusions or recommendations expressed in this material are those of theauthor(s) and do not necessarily reflect the views of the National Science Foundation (NSF).

39 of 39

3/5/20, 12:16 PM