| Document: refeds-eduPerson- | 201910-DRAFT202001 Home: | REFEDS Schema Board |
|---|---|---|
Released: 09 January 2020 | 17 October 2019 | |
Copyright © 2019 by Internet2 and/or the respective authors | Comments to: schema-discuss@lists.refeds.org |
eduPerson Object Class Specification (
...
202001)
Status of this document
The (201910202001) version of the eduPerson object class specification is described in this document. This version is appropriate for adoption in a production enterprise directory service environment.
0. Table of Contents
1.
| Anchor | ||||
|---|---|---|---|---|
|
1.1.
General RemarksAnchor General RemarksGeneralRemarksGeneral Remarks GeneralRemarks
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.
...
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: https://refeds.org/eduperson
1.2.
Identifier ConceptsAnchor Identifier ConceptsIdentifierConceptsIdentifier Concepts IdentifierConcepts
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.
...
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.
| Anchor | ||||
|---|---|---|---|---|
|
2.1.
| Anchor |
|---|
...
|
...
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 $
eduPersonNickname $
eduPersonOrgDN $
eduPersonOrgUnitDN $
eduPersonPrimaryAffiliation $
eduPersonPrincipalName $
eduPersonEntitlement $
eduPersonPrimaryOrgUnitDN $
eduPersonScopedAffiliation $
eduPersonTargetedID $
eduPersonAssurance $
eduPersonPrincipalNamePrior $
eduPersonUniqueId )
eduPersonOrcid )
)
...
2.2.
| Anchor |
|---|
...
|
...
Attributes in the following section were newly defined for eduPerson. Each entry specifies the version in which the attribute was first defined.
...
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 httphttps://www.shibboleth.internet2net.edu/.
Examples:
eduPersonEntitlement: http://xstor.com/contracts/HEd123
...
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. Possibilities of changes and reassignments make this identifier unsuitable for many purposes. As a result, eduPersonPrincipalName is NOT RECOMMENDED for use by applications that provide separation between low-level identification and more presentation-oriented data such as name and email address. Common identity protocols provide for a standardized and more stable identifier for such applications, and these protocol-specific identifiers should be used whenever possible; where using a protocol-specific identifier is not possible, the eduPersonUniqueId attribute may be an appropriate "neutral" form. Syntactically, ePPN looks like an email address but is not intended to be a person’s published email address, or to be used as an email address. Consumers must not assume this is a valid email address for the individual.
...
NOTE: eduPersonTargetedID is DEPRECATED and will be marked as obsolete in a future version of this specification. Its equivalent definition in SAML 2.0 has been replaced by a new specification for standard Subject Identifier attributes [httphttps://docs.oasis-open.org/security/saml-subject-id-attr/v1.0/csprd03/saml-subject-id-attr-v1.0-csprd03.pdfhtml], one of which ("urn:oasis:names:tc:SAML:attribute:pairwise-id") is a direct replacement for this identifier 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."
...
2.2.14.
eduPersonOrcid (defined in eduPerson 201910201602); OID:1.3.6.1.4.1.5923.1.1.1.16Anchor eduPersonOrcid eduPersonOrcid
...
Indexing: pres, eq
...
3.
Comments on Other Common Person AttributesAnchor CommentsonOtherCommonPersonAttributes CommentsonOtherCommonPersonAttributes Comments on Other Common Person Attributes Comments on Other Common Person Attributes
...
3.1.
audio (defined in RFC2798, inetOrgPerson); OID:0.9.2342.19200300.100.1.55Anchor audio audio
...
3.2.
cn (commonName), (defined in RFC4519, included in 'person'); OID:2.5.4.3Anchor cn cn
Application utility class:core; # of values: multi
...
3.3.
description description (included defined in personRFC4519); OID:2.5.4.13Anchor description description
Application utility class:standard; # of values: multi
...
3.4.
displayName (defined in RFC2798, inetOrgPerson); OID:2.16.840.1.113730.3.1.241Anchor displayName displayName
...
3.5.
facsimileTelephoneNumber (defined in RFC4519, included in orgPerson); OID:2.5.4.23Anchor facsimileTelephoneNumber facsimileTelephoneNumber
Application utility class:extended; # of values: multi
...
3.6.
givenName (defined in RFC4519, inetOrgPerson); OID:2.5.4.42Anchor givenName givenName
Application utility class:standard; # of values: multi
...
3.7.
homePhone (defined in RFC2798, inetOrgPersonRFC4524); OID:0.9.2342.19200300.100.1.20Anchor homePhone homePhone
...
3.8.
homePostalAddress (defined in RFC2798, inetOrgPersonRFC4524); OID:0.9.2342.19200300.100.1.39Anchor homePostalAddress homePostalAddress
...
3.9.
initials (defined in RFC4519, inetOrgPerson); OID:2.5.4.43Anchor initials initials
Application utility class:extended; # of values: multi
...
3.10.
jpegPhoto (defined in RFC2798, inetOrgPerson); OID:0.9.2342.19200300.100.1.60Anchor jpegPhoto jpegPhoto
...
Example applications for which this attribute would be useful
white pages
...
3.11.
l (localityName), (defined in RFC4519, included in orgPerson); OID:2.5.4.7Anchor #llocalityName#l localityName
Application utility class:extended; # of values: multi
...
3.12.
labeledURI (defined in RFC2798, inetOrgPerson); OID:1.3.6.1.4.1.250.1.57Anchor labeledURI labeledURI
...
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.
http://champagne.inria.fr/Unites/rennes.gif Rennes [photo]
Semantics
Most commonly a URL for a web site associated with this person
...
Example (LDIF Fragment)
labeledURI: http://www.hsww.wiz/%7Eputter Harry's home page
...
3.13.
mail (defined in RFC4524, inetOrgPerson); OID:0.9.2342.19200300.100.1.3Anchor mail mail
...
From RFC4524: The 'mail' (rfc822mailbox) attribute type holds Internet mail addresses in Mailbox [RFC2821] form (e.g., user@example.com).
Notes
Preferred address for the "to:" field of email to be sent to this person. Usually of the form localid@univ.edu. Though multi-valued, there is often only one value.
...
Example (LDIF Fragment)
mail: dumbledore@hsww.wiz
...
3.14.
manager (defined in RFC4524, inetOrgPerson); OID:0.9.2342.19200300.100.1.10Anchor manager manager
...
3.15.
mobile (defined in RFC4524, inetOrgPerson); OID:0.9.2342.19200300.100.1.41Anchor mobile mobile
...
mobile: +47 22 44 66 88
...
3.16.
o (organizationName), (defined in RFC2798, inetOrgPersonRFC4519); OID:2.5.4.10Anchor oorganizationNameo organizationName
Application utility class:standard; # of values: multi
...
3.17.
ou (organizationalUnitName), included (defined in orgPersonRFC4519); OID:2.5.4.11Anchor ou ou
Application utility class:standard; # of values: multi
...
3.18.
pager (defined in RFC4524, inetOrgPerson); OID:0.9.2342.19200300.100.1.42Anchor pager pager
...
3.19.
postalAddress (included in orgPersonRFC4519); OID:2.5.4.16Anchor postalAddress postalAddress
Application utility class:extended; # of values: multi
...
3.20.
postalCode (included in orgPersonRFC4519); OID:2.5.4.17Anchor postalCode postalCode
Application utility class:extended; # of values: multi
...
value is present, it will be part of the object's postal address." Zip code Zipcode in USA, postal code for other countries.
...
3.21.
postOfficeBox (RFC4519, included in orgPerson); OID:2.5.4.18Anchor postOfficeBox postOfficeBox
Application utility class:extended; # of values: multi
...
3.22.
preferredLanguage (format for a language specification defined in RFC2069, attribute defined in RFC2798, inetOrgPerson); OID:2.16.840.1.113730.3.1.39Anchor preferredLanguage preferredLanguage
...
3.23.
seeAlso (RFC4519, included in person); OID:2.5.4.34Anchor seeAlso seeAlso
Application utility class:standard; # of values: multi
...
3.24.
sn (surname), (RFC4519, included in person); OID:2.5.4.4Anchor sn sn
Application utility class:core; # of values: multi
...
3.25.
st (stateOrProvinceName), (RFC4519, included in orgPerson); OID:2.5.4.8Anchor st st
Application utility class:extended; # of values: multi
...
Standard two-letter abbreviations for U.S. state names, other standards-based abbreviations for provinces where available.
...
3.26.
street (RFC4519, included in orgPerson); OID:2.5.4.9Anchor street street
Application utility class:extended; # of values: multi
...
3.27.
telephoneNumber (included in personRFC4519); OID:2.5.4.20Anchor telephoneNumber telephoneNumber
Application utility class:standard; # of values: multi
...
3.28.
title (RFC4519, included in orgPerson); OID:2.5.4.12Anchor title title
Application utility class:extended; # of values: multi
...
title: Assistant Vice-Deputy for Redundancy Reduction
...
3.29.
uid (defined in RFC4519, inetOrgPerson); OID:0.9.2342.19200300.100.1.1Anchor uid uid
...
3.31.
userCertificate (defined in RFC2798, inetOrgPersonRFC4523); OID:2.5.4.36Anchor userCertificate userCertificate
Application utility class:extended; # of values: multi
...
3.32.
userPassword (RFC4519, included in person); OID:2.5.4.35Anchor userPassword userPassword
Application utility class:extended; # of values: multi
...
3.33.
userSMIMECertificate (defined in RFC2798, inetOrgPerson); OID:2.16.840.1.113730.3.1.40Anchor userSMIMECertificate userSMIMECertificate
...
3.34.
x500uniqueIdentifier (defined in RFC2798, inetOrgPersonRFC4519); OID:2.5.4.45Anchor x500uniqueIdentifier x500uniqueIdentifier
Application utility class:no recommendation; # of values:
...
Avoid. X500UniqueIdentifier syntax is specified as bit string, and that is not likely to be a good fit for many of the institutional attribute value choices, especially as part of the DN.
...
4.
| Anchor | ||||
|---|---|---|---|---|
|
This section lists changes that have been made from version to version of eduPerson.
The following list shows changes in version (202001) relative to version (201602).
- 1. Section 1.2 "Identifier Concepts" updated.
- 2. Section 2.2.8 "eduPersonPrincipalName" Notes section revised.
- 3. Section 2.2.11 "eduPersonTargetedID" deprecated.
- 4. Section 5 "References" links updated.
- 5. Section 3.* All RFCs verified.
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 attributes
2. Section 2.1.1 "eduPersonAffiliation" definition of the "member" affiliation clarified.
3. Section 2.2.8 "eduPersonPrincipalName" Refined the definition of "scope" and specified allowable characters in eduPersonPrincipalName values
4. Section 2.2.9 "eduPersonPrincipalNamePrior" added as a new eduPerson attribute type
5. Section 2.2.10 "eduPersonScopedAffiliation" Refined the definition of "scope".
6. Section 2.2.13 "eduPersonUniqueId" added as a new eduPerson attribute type
7. Section 3.8 "homePostalAddress" example updated to include country by appending "$USA"
8. Section 3.19 "PostalAddress" example updated to include country by appending "$USA"
9. Section 3.5 "facsimileTelephoneNumber" text updated to specify use of international format
10. Section 3.7 "homePhone" text updated to specify use of international format
11. Section 3.15 "mobile" text updated to specify use of international format
12. Section 3.18 "pager" text updated to specify use of international 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 edited and shortened to update content and to eliminate guidelines that are more properly defined by identity federations.
...
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.
11. Clarifying text added in sections 1.3 and 2.2.8
...
5.
| Anchor | ||||
|---|---|---|---|---|
|
...
6.
| Anchor | ||||
|---|---|---|---|---|
|
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.
...