[The following document InCommon's definition of common identity attributes, as downloaded on November 2, 2004 from http://www.incommonfederation.org/docs/policies/federatedattributes.html.]

InCommon Federation: Common Identity Attributes

It is essential that InCommon Participants support and use common definitions for certain basic identity attributes. The formal specification of identity management attributes for use within InCommon is the eduPerson schema[1]. Additional elements may be added to eduPerson from time to time but the definition and meaning of existing attributes is not expected to change.

Participants need not be able to assert all attributes in the eduPerson schema but when they do assert an attribute from that schema the meaning of that attribute must match the definition provided in the eduPerson specification.

The subset of eduPerson attributes that all Participants should be able to recognize is identified in the table below. Those attributes marked "Highly Recommended" should be supported by any InCommon Participant acting as a Credential Provider[2] since they may be expected by a wide variety of Resource Providers. Those marked "Suggested" should be supported if possible. Those marked "Optional" are not known to have broad applicability at this time.

Participants may define additional attributes that are needed within their organizations or in order to interoperate properly with particular federation partners. Attributes of this type must be identified in Federation Attribute Assertions so as not to conflict with names of eduPerson elements[3]. It is strongly recommended that all such elements begin with a substring unique to the defining party, e.g. "cornell_" for elements defined by Cornell University or "UnivofCa_" for elements defined for use within the University of California system. This constraint applies only to attribute names and not to attribute values.

The table below also indicates where particular attributes were first defined in case the reader wishes to look into the original source documents. The attribute types of person and orgPerson are defined in RFC 2256[4]. The object class inetOrgPerson is defined in RFC 2798[5].

Attribute	LDAP name	Highly Recommended	Suggested	Optional	Person	orgPerson	inetOrgPerson	eduPerson
Given name	givenName	X					X
Surname	sn (surname)	X			X
Common name	cn	X			X
Preferred name	displayName		X				X
Nickname	eduPersonNickname			X				X
Initials	initials			X			X
P.O. Box	postOfficeBox			X		X
Street address	street			X		X
City	l (localityName)			X		X
State	st (stateOrProvinceName)			X		X
Zip code	postalCode			X		X
Org. postal address	postalAddress		X			X
Phone number	telephoneNumber		X		X
Cellphone number	mobile			X			X
Pager number	pager			X			X
FAX number	facsimileTelephoneNumber			X		X
Email address	mail		X				X
Web site	labeledURI			X			X
Home address	homePostalAddress			X			X
Home phone	homePhone			X			X
Org. name	o (organizationName)		X				X
Org. DN	eduPersonOrgDN		X					X
Org. unit	ou (organizationalUnitName)			X			X
Primary Org. unit	eduPersonPrimaryOrgUnitDN			X				X
Org. unit(s) DN(s)	eduPersonOrgUnitDN			X				X
Org. title	title			X		X
Boss	manager			X			X
Primary affiliation	eduPersonPrimaryAffiliation		X					X
Affiliation	eduPersonAffiliation		X					X
Scoped affiliation	eduPersonScopedAffiliation	X						X
Entitlement	eduPersonEntitlement		X					X
Login name	uid			X			X
Password	userPassword			X	X
ID certificate	userCertificate			X			X
S/MIME certificate	userSMIMECertificate			X			X
Principle name	eduPersonPrincipalName	X						X
Targeted identifier	eduPersonTargetedID	X						X
Photo	jpegPhoto			X			X
Language	preferredLanguage		X				X
Description	description			X	X
Additional info	seeAlso			X	X

Table 1: eduPerson (200312) Attributes defined for use with InCommon

Brief descriptions of the Highly Recommended InCommon Attributes

For a complete definition of the eduPerson elements, see the eduPerson development web page at http://www.educause.edu/eduperson. The following descriptions were extracted from the 200312 version on that web site.

1. eduPersonAffiliation (defined in eduPerson 1.0)

Specifies the person's relationship(s) to the institution in broad categories such as student, faculty, staff, alum, etc. (See controlled vocabulary).

2. eduPersonEntitlement (defined in eduPerson 200210)

URI (either URN or URL) that indicates a set of rights to specific resources.

3. eduPersonNickname (defined in eduPerson 1.0)

Person's nickname, or the informal name by which they are accustomed to be hailed.

4. eduPersonOrgDN (defined in eduPerson 1.0)

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

5. eduPersonOrgUnitDN (defined in eduPerson 1.0)

The distinguished name(s) (DN) of the directory entries representing the person's Organizational Unit(s). May be multivalued, as for example, in the case of a faculty member with appointments in multiple departments or a person who is a student in one department and an employee in another.

6. eduPersonPrimaryAffiliation (defined in eduPerson 1.0)

Specifies the person's PRIMARY relationship to the institution in broad categories such as student, faculty, staff, alum, etc. (See controlled vocabulary).

7. eduPersonPrimaryOrgUnitDN (defined in eduPerson 200210)

The distinguished name (DN) of the directory entry representing the person's primary Organizational Unit(s).

8. eduPersonPrincipalName (defined in eduPerson)

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

9. eduPersonScopedAffiliation (defined in eduPerson)

Specifies the person's affiliation within a particular security domain in broad categories such as student, faculty, staff, alum, etc. The values consist of a left and right component separated by an "@" sign. The left component is one of the values from the eduPersonAffiliation controlled vocabulary. The right component identifies the security domain in the form of a dotted string value on the model of DNS domain names. This right-hand side syntax of eduPersonScopedAffiliation intentionally matches that used for the right-hand side values for eduPersonPrincipalName since both identify a security domain.

10. audio (defined in inetOrgPerson) [AVOID]

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

11. cn (commonName, defined in person)

According to RFC 2256, "This is the X.500 commonName attribute, which contains a name of an object. If the object corresponds to a person, it is typically the person's full name.”

12. description (defined in person)

Open-ended; whatever the person or the directory manager puts here. According to RFC 2256, "This attribute contains a human-readable description of the object."

13. displayName (defined in inetOrgPerson)

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

From RFC 2798 description: "preferred name of a person to be used when displaying entries."

14. facsimileTelephoneNumber (defined in orgPerson)

A fax number for the directory entry. Attribute values should follow the agreed format for international telephone numbers: i.e., "+44 71 123 4567."

15. givenName (defined in inetOrgPerson)

From RFC 2256 description:" The givenName attribute is used to hold the part of a person's name which is not their surname nor middle name."

16. homePhone (defined in inetOrgPerson)

From RFC 1274 description: "The [homePhone] attribute type specifies a home telephone number associated with a person.” Attribute values should follow the agreed format for international telephone numbers: i.e., "+44 71 123 4567."

17. homePostalAddress (defined in inetOrgPerson)

From RFC 1274 description: "The Home postal address attribute type specifies a home postal address for an object. This should be limited to up to 6 lines of 30 characters each."

18. initials (defined in inetOrgPerson)

From RFC 2256 description: "The initials attribute contains the initials of some or all of an individuals names, but not the surname(s)."

19. jpegPhoto (defined in inetOrgPerson)

Follow inetOrgPerson definition of RFC 2798: "Used to store one or more images of a person using the JPEG File Interchange Format [JFIF]."

20. l (localityName, defined in orgPerson)

locality name.

According to RFC 2256, "This attribute contains the name of a locality, such as a city, county or other geographic region (localityName)."

X.520(2000) reads: "The Locality Name attribute type specifies a locality. When used as a component of a directory name, it identifies a geographical area or locality in which the named object is physically located or with which it is associated in some other important way.”

21. labeledURI (defined in inetOrgPerson)

Follow inetOrgPerson definition of RFC 2079: "Uniform Resource Identifier with optional label."

Commonly a URL for a web site associated with this person. Good candidate for a self-maintained attribute. Note, however, that the vocabulary for the label portion of the value is not standardized.

22. mail (defined in inetOrgPerson)

Follow inetOrgPerson definition of RFC 1274: "The [mail] attribute type specifies an electronic mailbox attribute following the syntax specified in RFC 822. Note that this attribute should not be used for greybook or other non-Internet order mailboxes."

23. manager (defined in inetOrgPerson)

Follow inetOrgPerson definition which refers to RFC 1274: "The manager attribute type specifies the manager of an object represented by an entry." The value is a DN.

24. mobile (defined in inetOrgPerson)

Follow inetOrgPerson definition of RFC 1274: "The [mobile] attribute type specifies a mobile telephone number associated with a person. Attribute values should follow the agreed format for international telephone numbers: i.e.,
"+44 71 123 4567."

25. o (organizationName, defined in inetOrgPerson)

Standard name of the top-level organization (institution) with which this person is associated.

26. ou (organizationalUnitName, defined in inetOrgPerson)

Organizational unit(s). According to X.520(2000), "The Organizational Unit Name attribute type specifies an organizational unit. When used as a component of a directory name it identifies an organizational unit with which the named object is affiliated.

The designated organizational unit is understood to be part of an organization designated by an OrganizationName [o] attribute. It follows that if an Organizational Unit Name attribute is used in a directory name, it must be associated with an OrganizationName [o] attribute.

An attribute value for Organizational Unit Name is a string chosen by the organization of which it is a part."

27. pager (defined in inetOrgPerson)

Follow inetOrgPerson definition of RFC 1274: "The [pager] attribute type specifies a pager telephone number for an object. Attribute values should follow the agreed format for international telephone numbers: i.e., "+44 71 123 4567."

28. postalAddress (defined in orgPerson)

Campus or office address. inetOrgPerson has a homePostalAddress that complements this attribute. X.520(2000) reads: "The Postal Address attribute type specifies the address information required for the physical postal delivery to an object."

29. postalCode (defined in orgPerson)

Follow X.500(2001): "The postal code attribute type specifies the postal code of the named object. If this attribute value is present, it will be part of the object's postal address." Zip code in USA, postal code for other countries.

30. postOfficeBox (defined in orgPerson)

Follow X.500(2001): "The Post Office Box attribute type specifies the Postal Office Box by which the object will receive physical postal delivery. If present, the attribute value is part of the object's postal address."

31. preferredLanguage (defined in inetOrgPerson)

Follow inetOrgPerson definition of RFC 2798: "preferred written or spoken language for a person.”

32. seeAlso (defined in person)

Follow person object class definition: Identifies (by DN) another directory server entry that may contain information related to this entry.

According to X.520(2000), "The See Also attribute type specifies names of other Directory objects which may be other aspects (in some sense) of the same real world object."

33. sn (surname, defined in person)

Surname or family name. According to RFC 2256, "This is the X.500 surname attribute, which contains the family name of a person."

34. st (stateOrProvinceName, defined in orgPerson)

Abbreviation for state or province name.

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

According to RFC 2256, "This attribute contains the full name of a state or province (stateOrProvinceName)."

35. street (defined in orgPerson)

According to RFC 2256, "This attribute contains the physical address of the object to which the entry corresponds, such as an address for package delivery (streetAddress)."

36. telephoneNumber (defined in person)

Office/campus phone number. Attribute values should follow the agreed format for international telephone numbers: i.e., "+44 71 123 4567."

37. title (defined in orgPerson)

Follow X.520(2001): "The Title attribute type specifies the designated position or function of the object within an organization."

38. uid (defined in inetOrgPerson)

Follow inetOrgPerson definition of RFC 1274: "The [uid] attribute type specifies a computer system login name."

39. uniqueIdentifier (defined in none) [AVOID]

Follows definition of RFC1274: "Specifies a 'unique identifier' for an object represented in the directory."

40. userCertificate (defined in inetOrgPerson)

A user's X.509 certificate

41. userPassword (defined in person)

This attribute identifies the entry’s password and encryption method in the following format:

{encryption method}encrypted password.

42. userSMIMECertificate (defined in inetOrgPerson)

An X.509 certificate specifically for use in S/MIME applications (see RFCs 2632, 2633 and 2634).

43. x500uniqueIdentifier (defined in inetOrgPerson) [AVOID]

Defined originally in X.509(96) and included in RFC2256.

44. eduPersonTargetedID (defined in eduPerson)

A persistent, opaque identifier for a principal shared between a pair of coordinating entities, denoted by the Liberty Alliance architecture overview [1] as identity provider and service provider, and by the Shibboleth architecture document as an origin site and a target application [2]. An identity provider uses the appropriate value of this attribute when communicating with a particular service provider, and does not reveal that value to any other service provider except in limited circumstances.

A given value is intended only for consumption by a specific requester, and may be derived from some function over the requester's identity and other principal-specific input(s). It might not itself be stored by the identity provider, but usually is in order to support changes to or revocation of the value. It should be considerably difficult for an observer to guess the value that would be returned to any given requester, even given knowledge of the principal-specific input(s) to that value.

This attribute is used typically to represent a long-term account linking relationship between an identity provider and a service provider. Note that such a service provider might itself also be an identity provider.

Credential Providers should be aware, and should notify their constituents, that use of eduPersonTargetedID reduces privacy by allowing the Resource Provider to correlate multiple appearances of the same individual.

[1] http://www.projectliberty.org/specs/liberty-idff-arch-overview-v1.2.pdf

[2] http://shibboleth.internet2.edu

---

[1] See http://www.educause.edu/eduperson

[2] "Credential Provider" is the same as "Identity Provider" in the SAML specification and "Origin" in older Shibboleth documentation.

[3] See Michael Gettes’s "LDAP Recipe" (http://middleware.internet2.edu/) in the section on attribute firewalling.

[4] See http://www.ietf.org/rfc/rfc2256.txt

[5] See http://www.ietf.org/rfc/rfc2798.txt