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 RFC2798 and based in part on RFC4512 and RFC4519.
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 class difference 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
to the entry.

Attributes from the person, organizationalPerson and inetOrgPerson classes are listed alphabetically in the second 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, a broad 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 at its 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. While
almost any information in an entry may contribute to differentiating
it from similar entries, identifiers are intentionally 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 of characteristics
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 in various attribute
descriptions.

Persistence

Persistence is a measure of the length of time during which an identifier can be
reliably associated with a particular principal. A short-term
identifier might be associated with an application session. A
permanent identifier is associated with its entry for its lifetime.

Privacy

Some 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 the attribute 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 the namespace of the service provider(s) for
whom the value is created. A globally-unique identifier is intended
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 at some point in the (possibly distant) future. There will
be some sets of requirements that dictate a strict no reassignment
policy.

Human Palatability

An
identifier that is human-palatable is intended to be rememberable and
reproducible by typical human users, in contrast to identifiers that
are, for example, randomly generated sequences of bits.

1.3 Scope

The eduPersonPrincipalName, eduPersonPrincipalNamePrior, eduPersonScopedAffiliation, and eduPersonUniqueId attribute definitions found
below make use of the concept of scope. The meaning
of scope is specific to the attribute to which it is attached
and can vary from one attribute to another.

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:

If there is a value in eduPersonPrimaryAffiliation, that value MUST be asserted here as well.

The primary intended purpose of eduPersonAffiliation is to convey broad-category affiliation assertions between members of an identity federation. Given this inter-institutional context, only values of eduPersonAffiliation with broad consensus in definition and practice will have any practical value. The list of allowed values in the current version of the object class is certainly incomplete, especially in terms of local institutional use. The editors felt that any additional values should come out of discussions with the stakeholder communities. Any agreed-upon additional values will be included in later versions of eduPerson.

"Member" is intended to include faculty, staff, student, and other persons with a full set of basic privileges that go with membership in the university community (e.g., they are given institutional calendar privileges, library privileges and/or vpn accounts). It could be glossed as "member in good standing of the university community."

The "member" affiliation MUST be asserted for people carrying one or more of the following affiliations:

faculty or
staff or
student or
employee

Note: Holders of the affiliation "alum" are not typically "members" since they are not eligible for the full set of basic institutional privileges enjoyed by faculty, staff and students.

Cautionary note: There are significant differences in practice between identity providers in the way they define faculty, staff and employee and the logical relationships between the three. In particular there are conflicting definitions of "staff" and "employee" from country to country that make those values particularly unreliable in any international context.

The "affiliate" value for eduPersonAffiliation indicates that the holder has some definable affiliation to the university NOT captured by any of faculty, staff, student, employee, alum and/or member. Typical examples might include event volunteers, parents of students, guests and external auditors. There are likely to be widely varying definitions of "affiliate" across institutions. Given that, "affiliate" is of dubious value in federated, inter-institutional use cases.

For the sake of completeness, if for some reason the institution carries digital identity information for people with whom it has no affiliation according to the above definitions, the recommendation is simply not to assert eduPersonAffiliation values for those individuals.

"Library-walk-in:" This term was created to cover the case where physical presence in a library facility grants someone access to electronic resources typically licensed for faculty, staff and students. In recent years the library walk-in provision has been extended to cover other cases 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. For a more direct way of using eduPerson attributes to express library privilege information, see the eduPersonEntitlement value "urn:mace:dir:entitlement:common-lib-terms" as defined in the MACE-Dir Registry of eduPersonEntitlement values http://middleware.internet2.edu/urn-mace/urn-mace-dir-entitlement.html.

The presence of other affiliation values neither implies nor precludes the affiliation "library-walk-in."

It is not feasible to attempt to reach broad-scale, precise and binding inter-institutional definitions of affiliations such as faculty and students. Organizations have a variety of business practices and institutional specific uses of common terms. Therefore each institution will decide the criteria for membership in each affiliation classification. What is desirable is that a reasonable person should find an institution's definition of the affiliation plausible.

Semantics

Each institution decides
the criteria for membership in each affiliation classification.

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 a person'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 register with 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/.

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 user-friendly 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
embarrassing values being assigned to this attribute by would-be
malefactors!

Application developers
can use this attribute to make directory search functions more "user
friendly."

The distinguished name
(DN) of the directory entry representing the institution with which
the person is associated.

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

businessCategory

seeAlso

searchGuide

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 RFC4512):

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

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

seeAlso

searchGuide

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 RFC4512):

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 general institutional 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.

A scoped identifier for a person. It should be represented in the form "user@scope" where 'user' is a name-based identifier for the person and where the "scope" portion MUST be the administrative domain of the identity system where the identifier was created and assigned. Each value of 'scope' defines a namespace within which the assigned identifiers MUST be unique. Given this rule, if two eduPersonPrincipalName (ePPN) values are the same at a given point in time, they refer to the same person. There must be one and only one "@" sign in valid values of eduPersonPrincipalName.

Notes

Syntactically, ePPN looks like an email address but is not intended to be a person's published email address or be used as an email address.
In general, name-based identifiers tend to be subject to some degree of expected change and/or reassignment.

Values of eduPersonPrincipalName are often, but not required to be,
human-friendly, and may change as a result of various business processes.
They may also be reassigned after a locally-defined period of dormancy.
Applications that require a guarantee of non-reassignment and more
stability, but can tolerate values unfriendly (and unknown) to humans
should refer to the eduPersonTargetedID attribute.

Example applications for which this attribute would be useful

controlling access to
resources and other cases where a human friendly identifier is needed

Example (LDIF
Fragment)

eduPersonPrincipalName:
hputter@hsww.wiz

Syntax: directoryString; In general Unicode characters are allowed.
In LDAP, this data type implies UTF-8
encoding, and such characters are permitted. However, to reduce the risk
of application errors, it is recommended that values contain only
characters that could occur in account or login user names. While the UTF-8 encoding
will often be appropriate, the specific encoding depends on the technology
involved, and may not be limited to UTF-8 when more than LDAP is involved.

Each value of this multi-valued attribute represents an ePPN
(eduPersonPrincipalName) value that was previously associated with the
entry. The values MUST NOT include the currently valid ePPN value. There
is no implied or assumed order to the values.
This attribute MUST NOT be populated if ePPN values are ever reassigned to
a different entry (after, for example, a period of dormancy). That is,
they MUST be unique in space and over time.

Notes
This attribute provides a historical record of ePPN values associated with
an entry, provided the values are not subject to reassignment. It is
permissible to reassign ePPN values, but doing so precludes the use of
this attribute; consumers must be able to assume that a historical ePPN
value is associated with exactly one entry for all time.
As an identifier that may be based on a user's name, values of ePPN may
change over time, and this creates problems for applications that are
limited in their capacity to accommodate less friendly identifiers. To
improve the user experience in such cases, applications may be enhanced to
leverage this attribute to identify renamed accounts. Applications that
support automated renaming can be enhanced to do so, while those that do
not could be enhanced with logging or exception reporting that identifies
the problem.
It is strongly preferable to enhance, or build new, applications to
support more stable/persistent (and necessarily opaque) identifiers, but
this attribute may be useful as a transitional aid.
It is permissible, though likely unusual, for a subject with no current
eduPersonPrincipalName value to have eduPersonPrincipalNamePrior values.
This could reflect, for example, a deprovisioning scenario.

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-hand side syntax of eduPersonScopedAffiliation intentionally
matches that used for the right-hand side values for
eduPersonPrincipalName. The "scope" portion MUST be the administrative domain to which the
affiliation applies.
Multiple "@" signs are
not recommended, 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 the first "@". This parsing rule conforms to
the POSIX "greedy" disambiguation method in regular
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 to exchanges of this attribute
value.

Semantics

An
eduPersonScopedAffiliation value of "x@y" is to be
interpreted as an assertion that the person in whose entry this value
occurs holds an affiliation of type "x" within the security
domain "y."

eduPersonTargetedID is an abstracted version of the SAML V2.0 Name Identifier format of "urn:oasis:names:tc:SAML:2.0:nameid-format:persistent" (see http://www.oasis-open.org/committees/download.php/35711). In SAML, this is an XML construct consisting of a string value inside a <saml:NameID> element along with a number of XML attributes, of most significance NameQualifier and SPNameQualifier, which identify the source and intended audience of the value. It is left to specific profiles to define alternate syntaxes, if any, to the standard XML representation used in SAML.

In abstract terms, an eduPersonTargetedID value is a tuple consisting of an opaque identifier for the principal, a name for the source of the identifier, and a name for the intended audience of the identifier. The source of the identifier is termed an identity provider and the name of the source takes the form of a SAML V2.0 entityID, which is an absolute URI. The name of the intended audience also takes the form of an absolute URI, and may refer to a single service provider or a collection of service providers (for which SAML V2.0 uses the term "Affiliation", not to be confused with the ordinary eduPerson use of the term).

Per the SAML format definition, the identifier portion MUST NOT exceed 256 characters, and the source and audience URI values MUST NOT exceed 1024 characters.

In SAML, a service provider is an abstract designation and may or may not refer to a single application or physical system. As a result, and because service providers may be grouped arbitrarily into "Affiliations" for policy purposes, the intended audience of an eduPersonTargetedID may be (and often is) limited to a single "target" application, or may consist of a large number of related applications. This is at the discretion of the identity provider. The value of the principal identifier SHOULD be different for different "audience" values, but this is also at the discretion of the identity provider.

This attribute may or may not be stored in a typical Directory Service because of its potential variance by relying party, but it is defined here for use in other service contexts such as Security Assertion Markup Language (SAML) assertions. It is typically used in federated scenarios in which more typical opaque identifiers lack appropriate uniqueness guarantees across multiple identity providers.

More specific requirements and guidance follows.

Persistence

As defined by SAML, eduPersonTargetedID values are not required to have 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 consuming services. Protocols might also be used to refresh (or "roll-over") an identifier by communicating such changes to service providers to avoid a loss of service. (SAML V2.0 includes one such example.) This may be needed in the event that the association between the principal and the identifier becomes public, if privacy requirements are involved.

Privacy

This attribute is designed in part to aid in the preservation of user privacy. It is therefore REQUIRED to be opaque, having no particular relationship to the principal's other identifiers, such as a local username. It MAY be a pseudorandom value generated and stored by the identity provider, or MAY be derived from some function over the audience's identity and other principal-specific input(s), such as a serial number or UUID assigned by the identity provider.

This attribute is also designed to inhibit, when appropriate, the ability of multiple unrelated services to correlate user activity by comparing values. This is achieved when desired by varying the identifier based on the intended audience.

In other words, there is no guarantee of non-correlation, but there is an assumption of non-correlation from the relying party's perspective outside of explicitly arranged "Affiliations" of relying parties and cooperating identity providers prepared to recognize them.

Uniqueness

A value of this attribute is intended only for consumption by a specific audience of services (often a single 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; the uniqueness of the identifier therefore depends on all three pieces of information.

Reassignment

A distinguishing feature of this attribute inherited from SAML 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 reassigned such that the same value given to a particular relying party refers to two different principals at different points in time. It is allowable (though perhaps confusing) for a given value to refer to two or more different principals when scoped to different audiences.

Human Palatability

This attribute does not meet requirements for human palatability or readability. It is ill-suited for display to end users or administrators, and is not useful for provisioning accounts ahead of initial access by users since the value will rarely be known by users or administrators. It may be accompanied by other attributes more suited to such purposes, in which case its privacy properties are presumably of no interest, but the lack of reassignment often is.

Example applications

Service providers or directory-enabled applications with the need to maintain a persistent but opaque identifier 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 to an internal account maintained within their own system. This attribute is often used to represent a long-term account linking relationship between an identity provider and service provider(s) (or other identity/attribute provider).

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, the type 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 the values.

As a multi-valued attribute, relying parties may receive multiple values and should ignore unrecognized values.

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 and procedures governing their operation and to be able to assess whether or not a given transaction meets the requirements for access.

Example applications for which this attribute would be useful

Determining strength of asserted identity for on-line transactions, especially those involving more than minimal institutional risk resulting from errors in authentication.

A system supporting access to grants management in order to provide assurance for financial transactions.

A long-lived, non re-assignable, omnidirectional identifier suitable for use as a principal identifier by authentication providers or as a unique external key by applications.

This identifier represents a specific principal in a specific identity system. Values of this attribute MUST be assigned in such a manner that no two values created by distinct identity systems could collide. This identifier is permanent, to the extent that the principal is represented in the issuing identity system. Once assigned, it MUST NOT be reassigned to another principal. This identifier is meant to be freely sharable, is public, opaque, and SHOULD remain stable over time regardless of the nature of association, interruptions in association, or complexity of association by the principal with the issuing identity system. When possible, the issuing identity system SHOULD associate any number of principals associated with a single person with a single value of this attribute.

This identifier is scoped (see section 1.3) and of the form uniqueID@scope. The "uniqueID" portion MUST be unique within the context of the issuing identity system and MUST contain only alphanumeric characters (a-z, A-Z, 0-9). The length of the uniqueID portion MUST be less than or equal to 64 characters. The "scope" portion MUST be the administrative domain of the identity system where the identifier was created and assigned. The scope portion MAY contain any Unicode character. The length of the scope portion MUST be less than or equal to 256 characters. Note that the use of characters outside the seven-bit ASCII set or extremely long values in the scope portion may cause issues with interoperability.

Relying parties SHOULD NOT treat this identifier as an email address for the principal as it is unlikely (though not precluded) for it to be valid for that purpose. Most organizations will find that existing email address values will not serve well as values for this identifier.

Example applications

Controlling access to resources where it is important to ensure a unique stable identifier for a principal that will be unique across time.

ORCID iDs are persistent digital identifiers for individual researchers. Their primary purpose is to unambiguously and definitively link them with their scholarly work products. ORCID iDs are assigned, managed and maintained by the ORCID organization.

Permissible values (if controlled)

Values MUST be valid ORCID identifiers in the ORCID-preferred URL representation (see Example given below)

Semantics

Each value represents an ORCID identifier registered with ORCID.org as belonging to the principal.

Example applications

NIH/NLM SciENcv self-service web application.

Example (LDIF Fragment)

eduPersonOrcid: http://orcid.org/0000-0002-1825-0097

Syntax: directoryString;

Indexing: pres, eq

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 that some 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.

RFC1274 notes that the
proprietary format they recommend is "interim" only.

Notes

Avoid. Not clearly
defined, no de facto standard.

3.2. cn (commonName, included
in person); OID: 2.5.4.3

Application utility class:
core; # of values: multi

Definition

Common name.

According to RFC4519,
"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 typically the 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 one of 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
the organization 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 useful

all

Example (LDIF
Fragment)

cn: Mary Francis Xavier

3.3. description (included in
person); OID: 2.5.4.13

Application utility class:
standard; # of values: multi

Definition

Open-ended; whatever the
person or the directory manager puts here. According to RFC4519,
"The 'description' attribute type contains human-readable descriptive
phrases about the object. Each description is one value of this
multi-valued attribute."

The name(s) that should
appear in white-pages-like applications for this person.

From RFC2798
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 useful

white pages, email
client

Example (LDIF
Fragment)

displayName: Jack
Dougherty

3.5. facsimileTelephoneNumber
(defined in RFC4519, included in orgPerson); OID: 2.5.4.23

Application utility class:
extended; # of values: multi

Definition

According to RFC4519: "The 'facsimileTelephoneNumber' attribute type contains telephone
numbers (and, optionally, the parameters) for facsimile terminals.
Each telephone number is one value of this multi-valued attribute."

From RFC1274
description: "The Home postal address attribute type specifies a
home postal address for an 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 useful

white pages

Example (LDIF
Fragment)

homePostalAddress: 1212
Como Ave.$Midton, SD 45621$USA

3.9. initials (defined in
RFC4519, inetOrgPerson); OID: 2.5.4.43

Application utility class:
extended; # of values: multi

Definition

From RFC4519
description: "The 'initials' attribute type contains strings of initials of some or
all of an individual's names, except the surname(s). Each string is
one value of this multi-valued attribute."

According to RFC4519,
"The 'l' ('localityName' in X.500) attribute type contains names of a
locality or place, 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 a directory name, it identifies a geographical area or
locality in which the named object is physically located or with
which it is associated in some other important way."

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.

Note from RFC2079: "The
labeledURI attribute type has the caseExactString syntax (since URIs
are case-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 the present
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 some cases 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 same manner. 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 the T.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 characters in 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.

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 a part."

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 the physical postal
delivery to an object."

Notes

Campus or office
address. inetOrgPerson has a homePostalAddress that complements this
attribute.

Follow X.500(2001): "The
postal code attribute type specifies the postal code of the named
object. If this attribute

value is present, it
will be part of the object's postal address." Zip code in USA,
postal code for other countries.

Notes

ZIP code in USA, postal
code for other countries.

Semantics

Zip code in USA, postal
code for other countries.

Example applications
for which this attribute would be useful

white pages

Example (LDIF
Fragment)

postalCode: 54321

3.21. postOfficeBox (RFC4519, included
in orgPerson); OID: 2.5.4.18

Application utility class:
extended; # of values: multi

Definition

From RFC4519: "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."

Surname or family name.
From RFC4519: "The 'sn' ('surname' in X.500) attribute type contains name strings
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 (the other 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 this multi-valued attribute. That yields the
best results for the broadest range of clients doing name searches.

Format: The values
should be coordinated on a national level. If well-known shortcuts
exist, like the two-letter state abbreviations in the US, these
abbreviations are preferred over longer full names.

From RFC4519: "The 'st' ('stateOrProvinceName' in X.500) attribute type contains the
full names of states 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 RFC4519 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 the definition,
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 useful

white pages

Example (LDIF
Fragment)

st: IL

3.26. street (RFC4519, included in
orgPerson); OID: 2.5.4.9

Application utility class:
extended; # of values: multi

Definition

From RFC4519: "The 'street' ('streetAddress' in X.500) attribute type contains site
information from a postal address (i.e., the street name, place,
avenue, and the house number). Each street is one value of this
multi-valued attribute."

A number of
off-the-shelf directory-enabled applications make use of this
inetOrgPerson attribute, not always consistently.

RFC1274 uses the longer
name 'userid'.

Example applications
for which this attribute would be useful

controlling access to
resources

Example (LDIF
Fragment)

uid: gmettes

3.30. uniqueIdentifier (RFC4524); OID: 0.9.2342.19200300.100.1.44

Application utility class:
no recommendation; # of values:

Definition

From RFC4524: "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 RFC4524 states "The domain within which the identifier
is unique and the exact semantics of the identifier are for local definition."

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 side
of 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).

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, corresponding edits in the eduPersonTargetedID
section.

6. Recommendation
on the "sn" attribute amended to suggest including the
whole surname as well 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.0 of 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 in many 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 each of 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 the referenced 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.

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 (RIP), 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, Gabriel Sroka, Jon Saperia, David Bantz, Mikael Linden,
Marlena Erdos, Peter Schober and others. The editor of
the MACE-Dir working group, Keith Hazelton, would like to thank
them and the many others who helped bring this effort to completion.
This version also had the benefit of comments 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 over the years, Ben Chinowsky, Renee
Frost, Lisa Hogeboom, Nate Klingenstein, Steve Olshansky, Jessica
Bibbee, Ellen Vaughan and Emily Eisbruch.

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 the
author(s) and do not necessarily reflect the views of the National
Science Foundation (NSF).