Date: Thu, 28 Mar 2024 18:01:17 +0000 (UTC) Message-ID: <1691038567.1910.1711648877501@wiki-prod.refeds.org> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_1909_1559028670.1711648877500" ------=_Part_1909_1559028670.1711648877500 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Document: refeds-eduPerson-202001 Home: |
REFEDS Schema Board |
---|---|
Released: 09 January 2020 <= /th> | |
Copyright =C2=A9 2019 by Internet2 and/o= r the respective authors |
Comments to: schema-dis= cuss@lists.refeds.org |
Status of this document
The (202001) version of the eduPerson object class specification is desc= ribed in this document. This version is appropriate for adoption in a produ= ction enterprise directory service environment.
1.1. General Remarks
The portions of the eduPerson specification intended to support LDAP ope= rations include an auxiliary object class for campus directories designed t= o facilitate communication among higher education institutions. It consists= of a set of data elements or attributes about individuals within higher ed= ucation, along with recommendations on the syntax and semantics of the data= that may be assigned to those attributes. The eduPerson attributes are fou= nd in the next section.
It is recommended that person entries have the person, organizationalPer= son and inetOrgPerson object classes defined. The former two are included i= n X.521 (2001) and inetOrgPerson is included in RFC2798 and based in part o= n RFC4512 and RFC4519. EduPerson attributes would be brought into the perso= n entry as appropriate from the auxiliary eduPerson object class. This repr= esents a change from eduPerson 1.0 where the object class was defined as st= ructural, and inherited from other person classes. Sites that have implemen= ted 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-ba= sed directory, the LDIF would have to be tweaked before being imported into= a directory implementing post 1.0 versions to add the person, orgPerson an= d inetOrgPerson object classes to the entry.
Attributes from the person, organizationalPerson and inetOrgPerson class= es are listed alphabetically in the second section of this document. The pu= rpose of listing them is primarily as a convenience to enterprise directory= designers, but in some cases notes were added to clarify aspects of meanin= g or usage in the education community beyond what can be found in the origi= nal standards documents.
If widespread agreement and implementation of this object class in campu= s directories is achieved, a broad and powerful new class of higher educati= on applications can be more easily deployed. Additional information on eduP= erson, including LDIF for implementing the object class and attributes, is = available at its home on the web: https://refeds.org/eduperson= p>
1.2. Identifier Concepts
Among the most common and useful personal attributes are identifie= rs. An identifier is an information element that is specifically designed t= o distinguish each entry from its peers in a particular set. While almost a= ny information in an entry may contribute to differentiating it from simila= r entries, identifiers are intentionally designed to do this. It is common = for entries to contain several different identifiers, used for different pu= rposes or generated by different information sources.
Note that while the eduPerson specification includes a number of g= eneric identifier attribute types, it is increasingly common for individual= security protocols such as OpenID Connect and SAML to define their own pro= tocol-specific subject identifiers and related functionality. In some cases= (e.g., SAML) this material has been explicitly informed by, and is a react= ion to, problems or limitations arising from the application of the eduPers= on-defined identifiers to federated authentication.
In most cases, it is advisable to defer to a particular protocol's= specifications to understand what constitutes best practice in that partic= ular context. It may often be reasonable to map usage of eduPerson identifi= ers into a protocol, but be aware that there may be subtle differences to a= ccount for when mapping to multiple protocols such as SAML and OpenID Conne= ct.
Identifiers have a number of characteristics that help to determin= e appropriate usage. The following comments are offered to help clarify som= e points of definition for these various identifiers. These concepts are al= so referred to in various attribute descriptions. Deployers are urged to ca= refully consider the characteristics (e.g., case sensitivity, reassignment)= for each identifier.
Persistence
Persistence is a measure of the length of time during which an identifie= r can be reliably associated with a particular principal. A short-term iden= tifier might be associated with an application session. A permanent identif= ier is associated with its entry for its lifetime.
Privacy
Some identifiers are designed to preserve the principal's privacy and in= hibit the ability of multiple unrelated recipients from correlating princip= al activity by comparing values. Such identifiers are therefore REQUIRED to= be opaque, having no particular relationship to the principal's other iden= tifiers. Note that this definition permits sharing of the identifier among = multiple recipients if they are deemed by the attribute provider to be equi= valent to a single recipient for privacy purposes.
Uniqueness
Unique identifiers are those which are unique within the namespace of th= e identity provider and the namespace of the service provider(s) for whom t= he value is created. A globally-unique identifier is intended to be unique = across all instances of that attribute in any provider.
Identifiers may define specific rules for comparing values, princi= pally whether case matters in alphabetic characteristics. A mix of case-mat= ching approaches can be observed across different identifiers. Many applica= tions assume case-insensitive matching. It is therefore a security risk to = rely on identifiers that require case-sensitive matching.
Reassignment
Many identifiers do not specifically guarantee that a given value will n= ever be reused. Reuse would mean assigning an identifier value to one princ= ipal, and then assigning the same value to a different principal at some po= int in the (possibly distant) future. There will be some sets of requiremen= ts 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, eduPersonScoped= Affiliation, and eduPersonUniqueId attribute definitions found below make u= se of the concept of scope. The meaning of scope is specific to the attribu= te to which it is attached and can vary from one attribute to another.
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
NAME 'eduPerson'
AUXILIARY
MAY ( eduPersonAffiliation $&nbs=
p;
&n=
bsp; eduPersonNickname $
&n=
bsp; eduPersonOrgDN $
&n=
bsp; eduPersonOrgUnitDN $
&n=
bsp; eduPersonPrimaryAffiliation $
&n=
bsp; eduPersonPrincipalName $
&n=
bsp; eduPersonEntitlement $
&n=
bsp; eduPersonPrimaryOrgUnitDN $
&n=
bsp; eduPersonScopedAffiliation $
&n=
bsp; eduPersonTargetedID $
&n=
bsp; eduPersonAssurance $
&n=
bsp; eduPersonPrincipalNamePrior $
&n=
bsp; eduPersonUniqueId )
&n=
bsp; eduPersonOrcid )
)
Attributes in the following section were newly defined for eduPerson. Ea= ch entry specifies the version in which 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
RFC4512 definition
( 1.3.6.1.4.1.5923.1.1.1.1
NAME 'eduPersonAf= filiation'
DESC 'eduPerson p= er Internet2 and EDUCAUSE'
EQUALITY caseIgno= reMatch
SYNTAX '1.3.6.1.4= .1.1466.115.121.1.15' )
Application utility class:standard; # of values: = multi
Definition
Specifies the person's relationship(s) to the institution in broad categ= ories such as student, faculty, staff, alum, etc. (See controlled vocabular= y).
Permissible values
faculty, student, staff, alum, member, affiliate, employee, library-walk= -in
Notes
If there is a value in eduPersonPrimaryAffiliation, that value MUST be a= sserted 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 va= lue. The list of allowed values in the current version of the object class = is certainly incomplete, especially in terms of local institutional use. Th= e editors felt that any additional values should come out of discussions wi= th the stakeholder communities. Any agreed-upon additional values will be i= ncluded in later versions of eduPerson.
"Member" is intended to include faculty, staff, student, and other perso= ns with a full set of basic privileges that go with membership in the unive= rsity community (e.g., they are given institutional calendar privileges, li= brary privileges and/or vpn accounts). It could be glossed as "member in go= od standing of the university community."
The "member" affiliation MUST be asserted for people carrying one or mor= e of the following affiliations:
faculty orstaff or
student or
employee
Note: Holders of the affiliation "alum" are not typically "members" sinc= e 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 i= dentity providers in the way they define faculty, staff and employee and th= e logical relationships between the three. In particular there are conflict= ing 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 fa= culty, staff, student, employee, alum and/or member. Typical examples might= include event volunteers, parents of students, guests and external auditor= s. There are likely to be widely varying definitions of "affiliate" across = institutions. Given that, "affiliate" is of dubious value in federated, int= er-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 ac= cording to the above definitions, the recommendation is simply not to asser= t eduPersonAffiliation values for those individuals.
"Library-walk-in:" This term was created to cover the case where physica= l presence in a library facility grants someone access to electronic resour= ces typically licensed for faculty, staff and students. In recent years the= library walk-in provision has been extended to cover other cases such as l= ibrary users on the campus network, or those using on-campus workstations. = Licensed resource providers have often been willing to interpret their cont= racts 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 eduPersonEntit= lement 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-ma= ce-dir-entitlement.html.
The presence of other affiliation values neither implies nor precludes t= he 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 student= s. Organizations have a variety of business practices and institutional spe= cific uses of common terms. Therefore each institution will decide the crit= eria for membership in each affiliation classification. What is desirable i= s that a reasonable person should find an institution's definition of the a= ffiliation plausible.
Semantics
Each institution decides the criteria for membership in each affiliation= classification.
A reasonable person should find the listed relationships plausible.
Example applications for which this attribute would be useful <= /em>
white pages, controlling access to resources
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
RFC4512 definition
( 1.3.6.1.4.1.5923.1.1.1.7
NAME 'eduPersonEn= titlement'
DESC 'eduPerson p= er Internet2 and EDUCAUSE'
EQUALITY caseExac= tMatch
SYNTAX '1.3.6.1.4= .1.1466.115.121.1.15' )
Application utility class:extended; # of values: = multi
Definition
URI (either URN or URL) that indicates a set of rights to specific resou= rces.
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 ass= ert such entitlements, the business rules that evaluate a person's attribut= es to determine eligibility are evaluated there. The target resource provid= er does not learn characteristics of the person beyond their entitlement. T= he 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 subscribin= g institutions. Assertions of entitlement from institutions not on this lis= t 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 Comm= ittee for Education) affiliates may opt to register with MACE as a naming a= uthority, enabling them to create their own URN values. See the second exam= ple below.
The driving force behind the definition of this attribute has been the M= ACE Shibboleth project. Shibboleth defines an architecture for inter-instit= utional sharing of web resources subject to access controls. For further de= tails, see the project's web pages at https://www.shibboleth.net= .
Examples:
eduPersonEntitlement: http://xstor.com/contracts/HEd123<= /p>
eduPersonEntitlement: urn:mace:washington.edu:confocalMicroscope
Example applications for which this attribute would be useful <= /em>
controlling access to resources
Example (LDIF Fragment)
eduPersonEntitlement: urn:mace:washington.edu:confocalMicroscope
Syntax: directoryString; Indexing:No recomme= ndation
2.2.3. eduPersonNickname (defined in e= duPerson 1.0); OID:1.3.6.1.4.1.5923.1.1.1.2
RFC4512 definition
( 1.3.6.1.4.1.5923.1.1.1.2
NAME 'eduPersonNi= ckname'
DESC 'eduPerson p= er Internet2 and EDUCAUSE'
EQUALITY caseIgno= reMatch
SYNTAX '1.3.6.1.4= .1.1466.115.121.1.15' )
Application utility class:standard; # of values: = multi
Definition
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 t= he 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 t= his a self-maintained attribute If it were merely one of the multiple value= s of the cn attribute, this would be harder to do. A review step by a respo= nsible 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 f= unctions more "user friendly."
Example applications for which this attribute would be useful <= /em>
white pages
Example (LDIF Fragment)
eduPersonNickname: Spike
Syntax: directoryString;Indexing:pres, eq, sub
2.2.4. eduPersonOrgDN (defined in eduPers= on 1.0); OID:1.3.6.1.4.1.5923.1.1.1.3
RFC4512 definition
( 1.3.6.1.4.1.5923.1.1.1.3
NAME 'eduPersonOr= gDN'
DESC 'eduPerson p= er Internet2 and EDUCAUSE'
EQUALITY distingu= ishedNameMatch
SYNTAX '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 inst= itution 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, eduPerso= nOrgDN, 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 i= s 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 add= ing the labeledURIObject auxiliary object class to the organization object = pointed to by this dn, which endows it with a labeledURI attribute. Some di= rectory servers implement this object class by default. For others, the sch= ema may need to be extended using this definition (using the syntax specifi= ed by RFC4512):
( 1.3.6.1.4.1.250.3.15 NAME 'labeledURIObject' SUP top AUXILIARY
MAY labeledURI )<= /p>
Example applications for which this attribute would be useful <= /em>
white pages
Example (LDIF Fragment)
eduPersonOrgDN: o=3DHogwarts, dc=3Dhsww, dc=3Dwiz
Syntax: distinguishedName;Indexing:No recommendat= ion
2.2.5. eduPersonOrgUnitDN (defined in= eduPerson 1.0); OID:1.3.6.1.4.1.5923.1.1.1.4
RFC4512 definition
( 1.3.6.1.4.1.5923.1.1.1.4
NAME 'eduPersonOr= gUnitDN'
DESC 'eduPerson p= er Internet2 and EDUCAUSE'
EQUALITY distingu= ishedNameMatch
SYNTAX '1.3.6.1.4= .1.1466.115.121.1.12' )
Application utility class:standard; # of values: = multi
Definition
The distinguished name(s) (DN) of the directory entries representing the= person's Organizational Unit(s). May be multivalued, as for example, in th= e case of a faculty member with appointments in multiple departments or a p= erson 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 u= nit(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 organizationa= lUnitName, this object class has the same optional attribute set as the org= anization 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 add= ing the labeledURIObject auxiliary object class to the organization object = pointed to by this dn, which endows it with a labeledURI attribute. Some di= rectory servers implement this object class by default. For others, the sch= ema may need to be extended using this definition (using the syntax specifi= ed by RFC4512):
( 1.3.6.1.4.1.250.3.15 NAME 'labeledURIObject' SUP top AUXILIARY
MAY labeledURI )<= /p>
Example applications for which this attribute would be useful <= /em>
white pages
Example (LDIF Fragment)
eduPersonOrgUnitDN: ou=3DPotions, o=3DHogwarts, dc=3Dhsww, dc=3Dwiz
Syntax: distinguishedName;Indexing:eq
2.2.6. eduPersonPrimaryAffiliation (defined in eduPerson 1.0);
OID:1.3.6.1.4.1.5923.1.1.1.5
RFC4512 definition
( 1.3.6.1.4.1.5923.1.1.1.5
NAME 'eduPersonPr= imaryAffiliation'
DESC 'eduPerson p= er Internet2 and EDUCAUSE'
EQUALITY caseIgno= reMatch
SYNTAX '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 voca= bulary).
Permissible values
faculty, student, staff, alum, member, affiliate, employee, library-walk= -in
Notes
Appropriate if the person carries at least one of the defined eduPersonA= ffiliations. 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 p= erson were to attend a general institutional social gathering. Note that th= e single-valued eduPersonPrimaryAffiliation attribute assigns each person i= n the directory into one and only one category of affiliation. There are ap= plication scenarios where this would be useful.
See eduPersonAffiliationfor further details.
Example applications for which this attribute would be useful <= /em>
controlling access to resources
Example (LDIF Fragment)
eduPersonPrimaryAffiliation: student
Syntax: directoryString;Indexing:pres, eq, sub
2.2.7. eduPersonPrimaryOrgUnitDN (d= efined in eduPerson 200210); OID:1.3.6.1.4.1.5923.1.1.1.8
RFC4512 definition
( 1.3.6.1.4.1.5923.1.1.1.8
NAME 'eduPersonPr= imaryOrgUnitDN'
DESC 'eduPerson p= er Internet2 and EDUCAUSE'
EQUALITY distingu= ishedNameMatch
SYNTAX '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 pers= on's primary Organizational Unit(s).
Notes
Appropriate if the person carries at least one of the defined eduPersonO= rgUnitDN. The choices of values are the same as for that attribute.
Semantics
Each institution populating this attribute decides the criteria for dete= rmining which organization unit entry is the primary one for a given indivi= dual.
Example applications for which this attribute would be useful <= /em>
white pages
Example (LDIF Fragment)
eduPersonPrimaryOrgUnitDN: ou=3DMusic Department, o=3DNotre Dame, dc=3Dn= d, dc=3Dedu
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
RFC4512 definition
( 1.3.6.1.4.1.5923.1.1.1.6
NAME 'eduPersonPr= incipalName'
DESC 'eduPerson p= er Internet2 and EDUCAUSE'
EQUALITY caseIgno= reMatch
SYNTAX '1.3.6.1.4= .1.1466.115.121.1.15' SINGLE-VALUE )
Application utility class:standard; # of values: = single
Definition
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 wher= e the "scope" portion MUST be the administrative domain of the identity sys= tem where the identifier was created and assigned. Each value of 'scope' de= fines a namespace within which the assigned identifiers MUST be unique. Giv= en 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
Values of eduPersonPrincipalName are often, but not required to be= , human-friendly, and may change as a result of various business processes.= Possibilities of changes and reassignments make this identifier unsuitable= for many purposes. As a result, eduPersonPrincipalName is NOT RECOMM= ENDED for use by applications that provide separation between low-level ide= ntification and more presentation-oriented data such as name and email addr= ess. Common identity protocols provide for a standardized and more stable i= dentifier for such applications, and these protocol-specific identifiers sh= ould be used whenever possible; where using a protocol-specific identifier = is not possible, the eduPersonUniqueId attribute may be an appropriate "neu= tral" form. Syntactically, ePPN looks like an email address but is not inte= nded to be a person=E2=80=99s published email address, or to be used as an = email address. Consumers must not assume this is a valid email address for = the individual.
Example applications for which this attribute would be useful <= /em>
controlling access to resources and other cases where a human friendly i= dentifier 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 characte= rs 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, t= he specific encoding depends on the technology involved, and may not be lim= ited to UTF-8 when more than LDAP is involved.
Indexing:pres, eq, sub
2.2.9. eduPersonPrincipalNamePrior (defined in eduPerson 201211);OID:1.3.6.1.4.1.5923.1.1.1.12
RFC4512 definition
( 1.3.6.1.4.1.5923.1.1.1.12
NAME 'eduPersonPr= incipalNamePrior'
DESC 'eduPersonPr= incipalNamePrior per Internet2'
EQUALITY caseIgno= reMatch
SYNTAX '1.3.6.1.4= .1.1466.115.121.1.15' )
Application utility class:standard; # of values: = multi
Definition
Each value of this multi-valued attribute represents an ePPN (eduPersonP= rincipalName) value that was previously associated with the entry. The valu= es 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 v= alues are ever reassigned to a different entry (after, for example, a perio= d 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 rea= ssignment. It is permissible to reassign ePPN values, but doing so preclude= s the use of this attribute; consumers must be able to assume that a histor= ical ePPN value is associated with exactly one entry for all time. As an id= entifier 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 exp= erience in such cases, applications may be enhanced to leverage this attrib= ute to identify renamed accounts. Applications that support automated renam= ing can be enhanced to do so, while those that do not could be enhanced wit= h logging or exception reporting that identifies the problem. It is strongl= y 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 eduPersonPr= incipalNamePrior values. This could reflect, for example, a deprovisioning = scenario.
Example (LDIF Fragment)
eduPersonPrincipalName: baz@hsww.wiz
eduPersonPrincipalNamePrior: foo@hsww.wiz
eduPersonPrincipalNamePrior: bar@hsww.wiz
Syntax: directoryString;
Indexing: pres, eq, sub
2.2.10. eduPersonScop= edAffiliation (defined in eduPerson (200312)); OID:1= .3.6.1.4.1.5923.1.1.1.9
RFC4512 definition
( 1.3.6.1.4.1.5923.1.1.1.9
NAME 'eduPersonSc= opedAffiliation'
DESC 'eduPerson p= er Internet2 and EDUCAUSE'
EQUALITY caseIgno= reMatch
SYNTAX '1.3.6.1.4= .1.1466.115.121.1.15' )
Application utility class:standard; # of values: = multi
Definition
Specifies the person's affiliation within a particular security domain i= n broad categories such as student, faculty, staff, alum, etc. The values c= onsist of a left and right component separated by an "@" sign. The left com= ponent is one of the values from the eduPersonAffiliation controlled vocabu= lary.This right-hand side syntax of eduPersonScopedAffiliation intentionall= y matches that used for the right-hand side values for eduPersonPrincipalNa= me. The "scope" portion MUST be the administrative domain to which the affi= liation applies. Multiple "@" signs are not recommended, but in any case, t= he first occurrence of the "@" sign starting from the left is to be taken a= s the delimiter between components. Thus, user identifier is to the left, s= ecurity 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 ar= e allowed to the left of the "@" sign. The values to the right of the "@" s= ign shouldindicate a security domain.
Notes
Consumers of eduPersonScopedAffiliation will have to decide whether or n= ot they trust values of this attribute. In the general case, the directory = carrying the eduPersonScopedAffiliation is not the ultimate authoritative s= peaker for the truth of the assertion. Trust must be established out of ban= d 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 affilia= tion of type "x" within the security domain "y."
Example applications for which this attribute would be useful <= /em>
white pages, controlling access to resources
Example (LDIF Fragment)
eduPersonScopedAffiliation: faculty@cs.berkeley.edu
Syntax: directoryString;Indexing:pres, eq
2.2.11. eduPersonTargetedID (defined in e= duPerson 200312); OID:1.3.6.1.4.1.5923.1.1.1.10
RFC4512 definition
( 1.3.6.1.4.1.5923.1.1.1.10
NAME 'eduPersonTa= rgetedID'
DESC 'eduPerson p= er Internet2 and EDUCAUSE'
EQUALITY caseExac= tMatch
SYNTAX '1.3.6.1.4= .1.1466.115.121.1.15' )
Application utility class:extended; # of values: = multi
NOTE: eduPersonTargetedID is DEPRECATED and will be marked as = obsolete in a future version of this specification. Its equivalent definiti= on in SAML 2.0 has been replaced by a new specification for standard Subjec= t Identifier attributes [https://docs.oasis-open.org/security/saml-subject-id-= attr/v1.0/saml-subject-id-attr-v1.0.html], one of which ("urn:oasis:nam= es:tc:SAML:attribute:pairwise-id") is a direct replacement for this identif= ier with a simpler syntax and safer comparison rules. Existing use of this = attribute in SAML 1.1 or SAML 2.0 should be phased out in favor of the new = Subject Identifier attributes."
Definition
A persistent, non-reassigned, opaque identifier for a principal.
eduPersonTargetedID is an abstracted version of the SAML V2.0 Name Ident= ifier format of "urn:oasis:names:tc:SAML:2.0:nameid-format:persistent" (see= http://www.oasis-open.org/committees/dow= nload.php/35711). In SAML, this is an XML construct consisting of a str= ing value inside a <saml:NameID> element along with a number of XML a= ttributes, of most significance NameQualifier and SPNameQualifier, which id= entify the source and intended audience of the value. It is left to specifi= c profiles to define alternate syntaxes, if any, to the standard XML repres= entation 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 ident= ifier, and a name for the intended audience of the identifier. The source o= f 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 re= fer 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 or= dinary eduPerson use of the term).
Per the SAML format definition, the identifier portion MUST NOT exceed 2= 56 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 no= t refer to a single application or physical system. As a result, and becaus= e service providers may be grouped arbitrarily into "Affiliations" for poli= cy purposes, the intended audience of an eduPersonTargetedID may be (and of= ten 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 dif= ferent "audience" values, but this is also at the discretion of the identit= y provider.
This attribute may or may not be stored in a typical Directory Service b= ecause of its potential variance by relying party, but it is defined here f= or use in other service contexts such as Security Assertion Markup Language= (SAML) assertions. It is typically used in federated scenarios in which mo= re 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 consumin= g services. Protocols might also be used to refresh (or "roll-over") an ide= ntifier 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 th= e event that the association between the principal and the identifier becom= es public, if privacy requirements are involved.
Privacy
This attribute is designed in part to aid in the preservation of user pr= ivacy. It is therefore REQUIRED to be opaque, having no particular relation= ship 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 pr= incipal-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 abilit= y of multiple unrelated services to correlate user activity by comparing va= lues. 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 a= n assumption of non-correlation from the relying party's perspective outsid= e 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 theref= ore MUST be unique within the namespace of the identity provider and the na= mespace 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 i= t prohibits re-assignment. Since the values are opaque, there is no meaning= attached to any particular value beyond its identification of the principa= l. Therefore particular values created by an identity provider MUST NOT be = reassigned such that the same value given to a particular relying party ref= ers to two different principals at different points in time. It is allowabl= e (though perhaps confusing) for a given value to refer to two or more diff= erent principals when scoped to different audiences.
Human Palatability
This attribute does not meet requirements for human palatability or read= ability. It is ill-suited for display to end users or administrators, and i= s not useful for provisioning accounts ahead of initial access by users sin= ce the value will rarely be known by users or administrators. It may be acc= ompanied by other attributes more suited to such purposes, in which case it= s privacy properties are presumably of no interest, but the lack of reassig= nment often is.
Example applications
Service providers or directory-enabled applications with the need to mai= ntain a persistent but opaque identifier for a given user for purposes of p= ersonalization 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 acc= ount linking relationship between an identity provider and service provider= (s) (or other identity/attribute provider).
2.2.12. eduPersonAssurance (defined in edu= Person 200806); OID:1.3.6.1.4.1.5923.1.1.1.11
RFC4512 definition
( 1.3.6.1.4.1.5923.1.1.1.11
NAME 'eduPersonAs= surance'
DESC 'eduPerson p= er Internet2 and EDUCAUSE'
EQUALITY caseExac= tMatch
SYNTAX '1.3.6.1.4= .1.1466.115.121.1.15' )
Application utility class:extended; # of values: = multi
Definition
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, ba= sed on the Identity Provider's identity management processes, the type of a= uthentication 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 documentatio= n 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 a= pplications to understand the various strengths of different identity manag= ement systems and authentication events and the processes and procedures go= verning their operation and to be able to assess whether or not a given tra= nsaction meets the requirements for access.
Example applications for which this attribute would be useful <= /em>
Determining strength of asserted identity for on-line transactions, espe= cially those involving more than minimal institutional risk resulting from = errors in authentication.
A system supporting access to grants management in order to provide assu= rance for financial transactions.
Example (LDIF Fragment)
eduPersonAssurance: urn:mace:incommon:IAQ:sample
eduPersonAssurance: http://idm.example.org/LOA#sample
Syntax: directoryString;Indexing:No recommendatio= n
2.2.13. eduPersonUniqueId (defined in eduPe= rson 201305); OID:1.3.6.1.4.1.5923.1.1.1.13
RFC4512 definition
( 1.3.6.1.4.1.5923.1.1.1.13
NAME 'eduPersonUn= iqueId'
DESC 'eduPersonUn= iqueId per Internet2'
EQUALITY caseIgno= reMatch
SYNTAX '1.3.6.1.4= .1.1466.115.121.1.15' )
Application utility class:standard; # of values: = single
Definition
A long-lived, non re-assignable, omnidirectional identifier suitable for= use as a principal identifier by authentication providers or as a unique e= xternal key by applications.
This identifier represents a specific principal in a specific identity s= ystem. Values of this attribute MUST be assigned in such a manner that no t= wo values created by distinct identity systems could collide. This identifi= er is permanent, to the extent that the principal is represented in the iss= uing identity system. Once assigned, it MUST NOT be reassigned to another p= rincipal. This identifier is meant to be freely sharable, is public, opaque= , and SHOULD remain stable over time regardless of the nature of associatio= n, interruptions in association, or complexity of association by the princi= pal with the issuing identity system. When possible, the issuing identity s= ystem SHOULD associate any number of principals associated with a single pe= rson with a single value of this attribute.
This identifier is scoped (see section 1.3) and of the form uniqueID@sco= pe. 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 ch= aracters. The "scope" portion MUST be the administrative domain of the iden= tity system where the identifier was created and assigned. The scope portio= n MAY contain any Unicode character. The length of the scope portion MUST b= e less than or equal to 256 characters. Note that the use of characters out= side 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.
Example (LDIF Fragment)
eduPersonUniqueId: 28c5353b8bb34984a8bd4169ba9= 4c606@foo.edu
Syntax: directoryString;
Indexing: pres, eq
2.2.14. eduPersonOrcid (defined in eduPerson 2= 01602); OID:1.3.6.1.4.1.5923.1.1.1.16
RFC4512 definition
( 1.3.6.1.4.1.5923.1.1.1.16
NAME 'eduPersonOr= cid'
DESC 'ORCID resea= rcher identifiers belonging to the principal'
EQUALITY caseIgno= reMatch
SYNTAX '1.3.6.1.4= .1.1466.115.121.1.15' )
Application utility class:standard; # of values: = multi
Definition
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 maintain= ed by the ORCID organization.
Permissible values (if controlled)
Values MUST be valid ORCID identifiers in the ORCID-preferred URL repres= entation (see Example given below)
Semantics
Each value represents an ORCID identifier registered with ORCID.org as be= longing to the principal.
Example applications
NIH/NLM SciENcv self-service web application.
Example (LDIF Fragment)
eduPersonOrcid: http://orcid.org/0000-0002-1825-0097<= /p>
Syntax: directoryString;
Indexing: pres, eq
3. Comments on Other Common Pers= on Attributes
The attributes in the following section are from other standard object c= lasses or attribute definitions. It is not a complete list of such attribut= es, 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 ca= n be found here. For details on the syntax and other aspects of these attri= butes, see the appropriate standards documents.
3.1. audio (defined in RFC2798); OID:0.9.2342.19200300.100.1.55
Application utility class:no recommendation;
Definition
RFC1274 notes that the proprietary format they recommend is "interim" on= ly.
Notes
Avoid. Not clearly defined, no de facto standard.
3.2. cn (commonName), (defined in RFC4519, included i= n '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 c= ontains names of an object. Each name is one value of this multi-valued att= ribute. 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 d= istinguished 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 a= ct as if this were "their" attribute, and therefore add values to this attr= ibute as they see fit. Because of that it is impossible to give a precise a= nd accurate definition of what this field means.
Example applications for which this attribute would be useful <= /em>
all
Example (LDIF Fragment)
cn: Mary Francis Xavier
3.3. description (defined in RFC4519); O= ID:2.5.4.13
Application utility class:standard; # of values: = multi
Definition
Open-ended; whatever the person or the directory manager puts here. Acco= rding to RFC4519, "The 'description' attribute type contains human-readable= descriptive phrases about the object. Each description is one value of thi= s multi-valued attribute."
Notes
Can be anything.
Example applications for which this attribute would be useful <= /em>
white pages
Example (LDIF Fragment)
description: A jolly good felon
3.4. displayName (defined in RFC2798); = 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 RFC2798 description: "preferred name of a person to be used when di= splaying entries."
Notes
Cn (common name) is multi-valued and overloaded to meet the needs of mul= tiple 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 <= /em>
white pages, email client
Example (LDIF Fragment)
displayName: Jack Dougherty
3.5. facsimileTelephoneNumber (defin= ed in RFC4519); OID:2.5.4.23
Application utility class:extended; # of values: = multi
Definition
According to RFC4519: "The 'facsimileTelephoneNumber' attribute type con= tains telephone numbers (and, optionally, the parameters) for facsimile ter= minals. Each telephone number is one value of this multi-valued attribute."=
Notes
Attribute values should comply with the international format specified i= n ITU Recommendation E.123: e.g., "+44 71 123 4567."
Semantics
A fax number for the directory entry.
Example applications for which this attribute would be useful <= /em>
white pages
Example (LDIF Fragment)
facsimileTelephoneNumber: +44 71 123 4567
3.6. givenName (defined in RFC4519); = OID:2.5.4.42
Application utility class:standard; # of values: = multi
Definition
From RFC4519 description:"The 'givenName' attribute type contains name s= trings that are the part of a person'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 <= /em>
Example (LDIF Fragment)
givenName: Stephen
3.7. homePhone (defined in RFC4524); = OID:0.9.2342.19200300.100.1.20
Application utility class:extended; # of values: = multi
Definition
From RFC1274 description: "The [homePhone] attribute type specifies a ho= me telephone number associated with a person."
Notes
Attribute values should comply with the international format specified i= n ITU Recommendation E.123: e.g., "+44 71 123 4567."
In RFC1274, this was originally called homeTelephoneNumber.
Example applications for which this attribute would be useful <= /em>
white pages
Example (LDIF Fragment)
homePhone: +1 608 555 1212
3.8. homePostalAddress (defined in RFC= 4524); OID:0.9.2342.19200300.100.1.39
Application utility class:extended; # of values: = multi
Definition
From RFC1274 description: "The Home postal address attribute type specif= ies 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 attrib= ute.
Example applications for which this attribute would be useful <= /em>
white pages
Example (LDIF Fragment)
homePostalAddress: 1212 Como Ave.$Midton, SD 45621$USA
3.9. initials (defined in RFC4519); OI= D:2.5.4.43
Application utility class:extended; # of values: = multi
Definition
From RFC4519 description: "The 'initials' attribute type contains string= s 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."
Example applications for which this attribute would be useful <= /em>
Example (LDIF Fragment)
initials: f x
3.10. jpegPhoto (defined in RFC2798); OID:0.9.2342.19200300.100.1.60
Application utility class:extended; # of values: = multi
Definition
Follow inetOrgPerson definition of RFC2798: "Used to store one or more i= mages of a person using the JPEG File Interchange Format [JFIF]."
Semantics
A smallish photo in jpeg format.
Example applications for which this attribute would be useful <= /em>
white pages
3.11. l (localityName), (defined in RFC4519= ); OID:2.5.4.7
Application utility class:extended; # of values: = multi
Definition
locality name.
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 geo= graphic region. Each name is one value of this multi-valued attribute."
X.520(2000) reads: "The Locality Name attribute type specifies a localit= y. When used as a component of a directory name, it identifies a geographic= al area or locality in which the named object is physically located or with= which it is associated in some other important way."
Example applications for which this attribute would be useful <= /em>
white pages
Example (LDIF Fragment)
l: Hudson Valley
3.12. labeledURI (defined in RFC2798); <= em>OID:1.3.6.1.4.1.250.1.57
Application utility class:extended; # of values: = multi
Definition
Follow inetOrgPerson definition of RFC2079: "Uniform Resource Identifier= with optional label."
Notes
Commonly a URL for a web site associated with this person. Good candidat= e for a self-maintained attribute. Note, however, that the vocabulary for t= he label portion of the value is not standardized.
Note from RFC2079: "The labeledURI attribute type has the caseExactStrin= g syntax (since URIs are case-sensitive) and it is multivalued. Values plac= ed in the attribute should consist of a URI (at the present time, a URL) op= tionally 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 ambigu= ity 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 t= hat are all related to the X.500 object, but may indicate different locatio= ns 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 doe= s 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 caseExactS= tring syntax, but that the use of non-IA5 (non-ASCII) characters is discour= aged as not all directory clients may handle them in the same manner. If no= n-IA5 characters are included, they should be represented using the X.500 c= onventions, not the HTML conventions (e.g., the character that is an "a" wi= th 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 "å").
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 charact= er 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.
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 useful <= /em>
white pages
Example (LDIF Fragment)
labeledURI: http://www.hsww.wiz/%7Eputter = Harry's home page
3.13. mail (defined in RFC4524); OID:= 0.9.2342.19200300.100.1.3
Application utility class:standard; # of values: = multi
Definition
From RFC4524: The 'mail' (rfc822mailbox) attribute type holds Internet m= ail 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 for further guidance on email addresses, rou= ting, etc. (http://middleware.internet2.= edu/dir/docs/ldap-recipe.htm).
Semantics
Preferred address for the "to:" field of email to be sent to this person= .
Example applications for which this attribute would be useful <= /em>
white pages, email client
Example (LDIF Fragment)
mail: dumbledore@hsww.wiz
3.14. manager (defined in RFC4524); OID= :0.9.2342.19200300.100.1.10
Application utility class:no recommendation; # of valu= es: multi
Definition
From RFC4524: "The 'manager' attribute specifies managers, by distinguis= hed name, of the person (or entity).
Notes
This attribute carries the DN of the manager of the person represented i= n this entry.
Example applications for which this attribute would be useful <= /em>
white pages
Example (LDIF Fragment)
manager: uid=3Dtwilliams, ou=3Dpeople, dc=3Dhobart, dc=3Dedu
3.15. mobile (defined in RFC4524); OID:<= /em>0.9.2342.19200300.100.1.41
Application utility class:extended; # of values: = multi
Definition
From RFC4524: "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= international format specified in ITU Recommendation E.123: e.g., "+44 71 = 123 4567."
Semantics
cellular or mobile phone number.
Example applications for which this attribute would be useful <= /em>
white pages
Example (LDIF Fragment)
mobile: +47 22 44 66 88
3.16. o (organizationName), (defined in= RFC4519); OID:2.5.4.10
Application utility class:standard; # of values: = multi
Definition
Standard name of the top-level organization (institution) with which thi= s person is associated.
Notes
Likely only one value.
Meant to carry the TOP-LEVEL organization name. Do not use this attribut= e to carry school college names.
Example applications for which this attribute would be useful <= /em>
white pages
Example (LDIF Fragment)
o: St. Cloud State
3.17. ou (organizationalUnitName), (defined in RFC451= 9); OID:2.5.4.11
Application utility class:standard; # of values: = multi
Definition
Organizational unit(s). According to X.520(2000), "The Organizational Un= it Name attribute type specifies an organizational unit. When used as a com= ponent 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 organi= zation 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 th= e organization of which it is a part."
Example applications for which this attribute would be useful <= /em>
white pages
Example (LDIF Fragment)
ou: Faculty Senate
3.18. pager (defined in RFC4524); OID:0.9.2342.19200300.100.1.42
Application utility class:extended; # of values: = multi
Definition
From RFC4524: "The 'pager' (pagerTelephoneNumber) attribute specifies pa= ger telephone numbers (e.g., "+1 775 555 5555") for an object."
Notes
Attribute values should comply with the international format specified i= n ITU Recommendation E.123: e.g., "+44 71 123 4567."
Semantics
pager number.
Example applications for which this attribute would be useful <= /em>
white pages
Example (LDIF Fragment)
pager: +1 202 555 4321
3.19. postalAddress (RFC4519); OI= D:2.5.4.16
Application utility class:extended; # of values: = multi
Definition
Campus or office address. inetOrgPerson has a homePostalAddress that com= plements this attribute. X.520(2000) reads: "The Postal Address attribute t= ype specifies the address information required for the physical postal deli= very to an object."
Notes
Campus or office address. inetOrgPerson has a homePostalAddress that com= plements this attribute.
Semantics
Campus or office address. X.520(2000) reads: "The Postal Address attribu= te type specifies the address information required for the physical postal = delivery to an object."
Example applications for which this attribute would be useful <= /em>
white pages
Example (LDIF Fragment)
postalAddress: P.O. Box 333$Whoville, WH 99999$USA
3.20. postalCode (RFC4519); OID:2.5.4.17
Application utility class:extended; # of values: = multi
Definition
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." Zipco= de 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 <= /em>
white pages
Example (LDIF Fragment)
postalCode: 54321
3.21. postOfficeBox (RFC4519); OI= D:2.5.4.18
Application utility class:extended; # of values: = multi
Definition
From RFC4519: "The 'postOfficeBox' attribute type contains postal box id= entifiers that a Postal Service uses when a customer arranges to receive ma= il at a box on the premises of the Postal Service. Each postal box identifi= er is a single value of this multi-valued attribute."
Notes Example applications for which this attribute wo= uld be useful
white pages
Example (LDIF Fragment)
postOfficeBox: 109260
3.22. preferredLanguage (format for a = language specification defined in RFC2069, attribute defined in RFC2798);&n= bsp;OID:2.16.840.1.113730.3.1.39
Application utility class:extended; # of values: = single
Definition
Follow inetOrgPerson definition of RFC2798: "preferred written or spoken= language for a person."
Permissible values (if controlled)
See RFC2068 and ISO 639 for allowable values in this field. Esperanto, f= or 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 useful <= /em>
white pages
Example (LDIF Fragment)
preferredLanguage: EO
3.23. seeAlso (RFC4519); OID:2.5.4= .34
Application utility class:standard; # of values: = multi
Definition
From RFC4519: The 'seeAlso' attribute type contains the distinguished na= mes 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 useful <= /em>
white pages
Example (LDIF Fragment)
seeAlso: cn=3DDepartment Chair, ou=3Dphysics, o=3DUniversity of Technolo= gy, dc=3Dutech, dc=3Dac, dc=3Duk
3.24. sn (surname), (RFC4519); OID:2.5.= 4.4
Application utility class:core; # of values: multi
Definition
Surname or family name. From RFC4519: "The 'sn' ('surname' in X.500) att= ribute type contains name strings for the family names of a person. Each st= ring 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 eduPer= son's three "core application utility" attributes. The third is eduPersonOr= gDN.
If the person has a multi-part surname (whether hyphenated or not), stor= e both 1) the whole surname including hyphens if present and 2) each compon= ent of a hyphenated surname as a separate value in this multi-valued attrib= ute. That yields the best results for the broadest range of clients doing n= ame searches.
Example applications for which this attribute would be useful <= /em>
all
Example (LDIF Fragment)
sn: Carson-Smith
sn: Carson
sn: Smith
3.25. st (stateOrProvinceName), (RFC4519); O= ID:2.5.4.8
Application utility class:extended; # of values: = multi
Definition
Abbreviation for state or province name.
Format: The values should be coordinated on a national level. If well-kn= own shortcuts exist, like the two-letter state abbreviations in the US, the= se 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 t= his multi-valued attribute."
Permissible values(if= controlled)
For states in the United States, U.S. Postal Service set of two-letter s= tate 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, othe= r 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 <= /em>
white pages
Example (LDIF Fragment)
st: IL
3.26. street (RFC4519); OID:2.5.4.9=
Application utility class:extended; # of values: = multi
Definition
From RFC4519: "The 'street' ('streetAddress' in X.500) attribute type co= ntains 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-val= ued attribute."
Example applications for which this attribute would be useful <= /em>
white pages
Example (LDIF Fragment)
street: 303 Mulberry St.
3.27. telephoneNumber (RFC4519);
Application utility class:standard; # of values: = multi
Definition
Office/campus phone number. Attribute values should comply with the inte= rnational format specified in ITU Recommendation E.123: e.g., "+44 71 123 4= 567."
Example applications for which this attribute would be useful <= /em>
white pages
Example (LDIF Fragment)
telephoneNumber: +1 212 555 1234
3.28. title (RFC4519); OID:2.5.4.12<= /p>
Application utility class:extended; # of values: = multi
Definition
From RFC4519: "The 'title' attribute type contains the title of a person= in their organizational context. Each title is one value of this multi-val= ued attribute."
Notes
No controlled vocabulary, may contain anything.
Example applications for which this attribute would be useful <= /em>
white pages
Example (LDIF Fragment)
title: Assistant Vice-Deputy for Redundancy Reduction
3.29. uid (RFC4519); OID:0.9.2342.1920= 0300.100.1.1
Application utility class:standard; # of values: = multi
Definition
From RFC4519: "The 'uid' ('userid' in RFC1274) attribute type contains c= omputer system login names associated with the object. Each name is one val= ue of this multi-valued attribute."
Notes
Likely only one value. See the extensive discussion in the "LDAP Recipe"= (http://middleware.internet2.edu/dir/do= cs/ldap-recipe.htm).
A number of off-the-shelf directory-enabled applications make use of thi= s inetOrgPerson attribute, not always consistently.
RFC1274 uses the longer name 'userid'.
Example applications for which this attribute would be useful <= /em>
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 valu= es:
Definition
From RFC4524: "The 'uniqueIdentifier' attribute specifies a unique ident= ifier for an object represented in the Directory. The domain within which t= he identifier is unique and the exact semantics of the identifier are for l= ocal definition. For a person, this might be an institution- wide payroll n= umber. 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 th= e identifier are for local definition."
3.31. userCertificate (RFC4523);
Application utility class:extended; # of values: = multi
Definition
A user's X.509 certificate
Notes
RFC2256 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 the userCertificate attribute is in certificate syntax (1= .3.6.1.4.1.1466.115.121.1.8).
Example applications for which this attribute would be useful <= /em>
email clients, controlling access to resources
3.32. userPassword (RFC4519); OID:= 2.5.4.35
Application utility class:extended; # of values: = multi
Definition
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 bi= nd operation must be done over SSL to avoid sending clear text passwords ov= er the wire or through the air.
Example applications for which this attribute would be useful <= /em>
controlling access to resources
3.33. userSMIMECertificate (RFC2798);&nb= sp;OID:2.16.840.1.113730.3.1.40
Application utility class:extended; # of values: = multi
Definition
An X.509 certificate specifically for use in S/MIME applications (see RF= Cs 2632, 2633 and 2634).
Notes
An X.509 certificate specifically for use in S/MIME applications. Accord= ing to RFC2798, "If available, this attribute is preferred over the userCer= tificate attribute for S/MIME applications."
RFC2798 states that this attribute is to be stored and requested in the = binary form, as 'userSMIMECertificate;binary.'
Semantics
Following userSMIMECertificate in RFC2798, "A PKCS#7 [RFC2315] SignedDat= a."
Example applications for which this attribute would be useful <= /em>
email clients
3.34. x500uniqueIdentifier (RFC4519);&nb= sp;OID:2.5.4.45
Application utility class:no recommendation; # of valu= es:
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 valu= e choices, especially as part of the DN.
This section lists changes that have been made from version to version o= f eduPerson.
The following list shows changes in version (202001) relative to version= (201602).
The following list shows changes in version (201602) relative to version= (201310).
1. Section 2.2.14 "eduPersonOrcid" added
The following list shows changes in version (201310) relative to version= (201203).
1. Section 1.3 "Scope" revised due to additional scoped attribu= tes
2. Section 2.1.1 "eduPersonAffiliation" definition of the "memb= er" affiliation clarified.
3. Section 2.2.8 "eduPersonPrincipalName" Refined the definitio= n of "scope" and specified allowable characters in eduPersonPrincipalName v= alues
4. Section 2.2.9 "eduPersonPrincipalNamePrior" added as a new e= duPerson attribute type
5. Section 2.2.10 "eduPersonScopedAffiliation" Refined the defi= nition of "scope".
6. Section 2.2.13 "eduPersonUniqueId" added as a new eduPerson = attribute type
7. Section 3.8 "homePostalAddress" example updated to include c= ountry by appending "$USA"
8. Section 3.19 "PostalAddress" example updated to include coun= try by appending "$USA"
9. Section 3.5 "facsimileTelephoneNumber" text updated to speci= fy use of international format
10. Section 3.7 "homePhone" text updated to specify use of inte= rnational format
11. Section 3.15 "mobile" text updated to specify use of intern= ational format
12. Section 3.18 "pager" text updated to specify use of interna= tional format
13. Section 3.27 "telephoneNumber" text updated to specify use = of international format
14. Section 3.30 "uniqueIdentifier" reference updated
15. Section 5 "References" now include X.520.
The following list shows changes in version (201203) relative to version= (200806).
1. Section 2.2.1 "eduPersonAffiliation" text updated to clarify= its definition and comment on its usage
2. Section 2.2.6 "eduPersonPrimaryAffiliation" text updated to = point to eduPersonAffiliation for detailed definitions
3. Section 2.2.10 "eduPersonTargetedID" text updated to better = describe properties and uses of eduPersonTargetedID
4. Section 2.2.8 "eduPersonPrincipalName" text significantly ed= ited and shortened to update content and to eliminate guidelines that are m= ore properly defined by identity federations.
The following list shows changes in version (200806) relative to version= (200712).
1. In section 1.1, changed RFC2256 to RFC4512.
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 docume= nt on information models"
4. In section 2.1, restructured attribute list to one per line for i= mproved 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 "RFC2252 definition" to "RFC45= 12 definition".
8. In section 2.2.5, changed reference from "RFC2252" to "RFC4512".<= /p>
9. In section 3.2, 3.3, changed reference from "RFC2256" to "RFC4519= " and updated text.
10. In section 3.5, added reference to RFC4519 and updated text. Add= ed notes section.
11. In section 3.6, changed reference from "RFC2798" to "RFC4519" an= d 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 "RFC2256" t= o "RFC4519" and updated text.
14. In section 3.11, changed reference from "RFC2256" to "RFC4519" a= nd updated text.
15. In section 3.13, changed reference from "RFC2798" to "RFC4524" a= nd 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/ld= ap-recipe.htm".
18. In section 3.13, removed notation about RFC1274 and rfc822Mailbo= x
19. In section 3.14, 3.15, changed reference from "RFC2798" to "RFC4= 524" and updated text.
20. In section 3.15, removed notation regarding RFC1274. 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 "RFC4524" a= nd updated text. Removed notation regarding RFC1274. Added notation that IT= U Recommendation E.123 should be used.
22. In section 3.21, changed to RFC4519 and removed redundant notati= on.
23. In section 3.23, added reference to RFC4519
24. In section 3.24, added reference to RFC4519. Changed example to = show recommended usage with a hyphenated name.
25. In section 3.25, added reference to RFC4519
26. In section 3.26, changed reference from RFC2256 to RFC4519 and u= pdated text.
27. In section 3.27, changed international 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 RFC4519 and updated text.
29. In section 3.29, changed reference from "RFC2798" to "RFC4519" a= nd update text.
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/ld= ap-recipe.htm".
31. In section 3.30, changed reference from "RFC1274" to "RFC4524" a= nd updated text.
32. In section 3.32, added reference to RFC4519. Text was not update= d because it is significantly different than RFC4519.
33. In section 4, added indention to all subsections to improve read= ability and added line break after section.
The following list shows changes in version (200712) relative to version= (200604).
1. In section 2.2.1, "eduPersonAffiliation" and section 2.2.6, "eduP= ersonPrimaryAffiliation," added "library-walk-in" to Permissible v= alues
2. In section 2.2.1, "eduPersonAffiliation" and section 2.2.6, "eduP= ersonPrimaryAffiliation," 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 eduPersonScopedAffiliati= on modified. A "first match from the left" rule is invoked such that the tw= o components are the substrings found on either side of the first "@" sign.=
2. Definition of eduPersonTargetedID revised to align with current r= ecommended 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 eduPersonAffiliati= on
3. New section added for attributes not included in the eduPerson ob= ject class. Includes one attribute in this version: eduPersonTargetedID.&nb= sp;
4. Introduction altered to include description of this new section.<= /p>
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 surname= s.
7. Various typographical errors corrected.
The following lists the changes (other than typographical corrections) t= hat 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 im= proved and corrected in many cases.
5. The syntax notes for the eight eduPerson attributes have been cor= rected and they now match the LDIF file. DirectoryString is used for five e= duPerson attributes. The other three contain distinguished names, so they u= se distinguishedName syntax.
6. RFC2252 style definitions have been included for the eduPerson ob= ject class itself and for each of the eduPerson attributes.
7. Two new attributes are defined: eduPersonEntitlement and eduPerso= nPrimaryOrgUnitDN.
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, unique= Identifier and x500UniqueIdentifier.
10. Notes on userCertificate and userSMIMECertificate have been rewr= itten.
11. Clarifying text added in sections 1.3 and 2.2.8
MACE members and others who contributed many hours to the definition of = this object class include Rob Banz, Tom Barton, Brendan Bellina, Scott Cant= or, Steven Carmody, Michael Gettes, Paul Hill, Ken Klingenstein, RL "Bob" M= organ (RIP), Todd Piket, David Wasley, Ann West, Ignacio Coupeau, Leif Joha= nnson, Hallvard Furuseth, Diego Lopez, Roland Hedberg, Ingrid Melve, Alista= ir Young, Peter Gietz, Mark Jones, Nathan Dors, Tom Scavo, Lynn McRae, Chad= La Joie, Katheryn Strojny, Kathryn Huxtable, Digant Kasundra, Gabriel Srok= a, Jon Saperia, David Bantz, Mikael Linden, Marlena Erdos, Peter Schober an= d others. The editor of the MACE-Dir working group, Keith Hazelton, would l= ike to thank them and the many others who helped bring this effort to compl= etion. This version also had the benefit of comments from several of the NM= I Testbed institutions. Three that deserve special mention are Georgia Stat= e University, the University of Alabama at Birmingham and the University of= Michigan. Special thanks to Internet2 staff members for their invaluable a= ssistance over the years, Ben Chinowsky, Renee Frost, Lisa Hogeboom, Nate K= lingenstein, Steve Olshansky, Jessica Bibbee, Ellen Vaughan and Emily Eisbr= uch.
This material is based in whole or in part on work supported by EDUCAUSE= , Internet2, and the National Science Foundation under the NSF Middleware I= nitiative - NSF 02-028, Grant No. ANI-0123937. Any opinions, findings and c= onclusions or recommendations expressed in this material are those of the a= uthor(s) and do not necessarily reflect the views of the National Science F= oundation (NSF).