Project

General

Profile

Actions

Common Set of EDIT Federation Attributes



One of the headmost tasks setting up a Shibboleth federation is to agree on a common set of attributes to be exchanged between IdPs and SPs. Obviously, this work has been accompagnied by some more or less intense discussions. Unfortunately, the number of applications actually connected to the EDIT Federation is quite reduced. Though, reasonable experience regarding applicability and interaction between different application and institution scenarios is missing. Therefore, the current set of attributes focus on essential information to support authentication within EDIT's Community Single Sign-On (CSSO) platform.

Actually, integrating EDIT applications developed by different institutions into the CSSO platform is work in progress. Certainly, this process will influence the future development of that attribute set. Also, any modification of that attribute set calls for the common agreement of all federated partners or institions respectively. Therefore, the current attribute set may be subject to further refinement in the future.

This document concentrates any necessary information regarding attributes currently beeing defined and agreed, and those being considered or may be taken into consideration later on. Thus, this document comprises the following elements:

This document starts with a table overview of the currently used set of EDIT attributes. The table contains links to the general attribute definitions or specific attribute interpretations for EDIT when available.

Next, the documents shows a list of any attributes being discussed so far. As such, it serves as a kind of scratchpad memorising any attributes considered to be added to the current attribute set.

Finally, the general overview comprises a list of any attribute definitions taken into account during the discussions leading to the current set of attributes. It have been used (and will be used further on) as a reference for any considerable attribute definitions.

Current Set of EDIT Attributes

The following table presents an overview of the currently used EDIT attribute set. Each entry provides a link to more detailed information regarding that attribute. If there is an EDIT specific interpretation available, then the link directs to this description first. Otherwise, the link points to the description available in the general attribute overview. Furthermore, the bold formatting of the attribute name indicates its mandatory state.

| Attribute | Environment variable | Notes |
| eduPersonPrincipalName | REMOTE_USER, HTTP_SHIB_EDUPERSONPRINCIPALNAME | |
| eduPersonAffiliation | HTTP_SHIB_EDUPERSONAFFILIATION | delivered in DN-style format (e.g. cn=Developer,ou=groups,dc=opensso,dc=e-taxonomy,dc=eu) |
| eduPersonTargetedID | HTTP_SHIB_EDUPERSONTARGETEDID | Id generated by OpenSSO on user registration |
| cn | HTTP_SHIB_CN | |
| givenName | HTTP_SHIB_GIVENNAME | |
| mail | HTTP_SHIB_MAIL| required for OpenSSO password reset and Drupal user registration |
| sn | HTTP_SHIB_SN | |
| postalAddress | HTTP_SHIB_POSTALADDRESS | |
| telephoneNumber | HTTP_SHIB_TELEPHONENUMBER | |

EDIT specific interpretation of currently used attributes

Within the next sections, any necessary refinements of the general attribute definitions will be outlined. Particularly, anything specified here represents the currently committed agreement regarding the implementation model of a given attribute. If an attribute is not mentioned here, the general attribute specification should have been implemented.

However, the header of the given attribute definition includes a link to the general attribute description also.

eduPersonAffiliation (EDIT)

In contrast to the general specification, that attribute describes a person's specific relationship to EDIT or, in other terms, its group membership as it is assigned within the OpenSSO user management console. Currently, OpenSSO is used as Identity Provider middleware component which includes a simple user/group management console also.

Due to a current limitation of the attribute mapper within OpenSSO, the eduPersonAffiliation attribute is devivered as a semicolon separated list of group names formatted in an Distinguished Name (DN) like style. Thus, group memberships are denoted along the following template, representing the respective DN of the group entry in the directory service serving as user data store to OpenSSO.

  • cn=,ou=groups,dc=opensso,dc=e-taxonomy,dc=eu

So, multiple group memberships are represented as follows:

  • cn=,ou=groups,dc=opensso,dc=e-taxonomy,dc=eu, cn=;ou=groups,dc=opensso,dc=e-taxonomy,dc=eu

The current representation may be subject of change, since the eduPerson schema proposes a scoped representation. That means, a domain identifier may be appended to the group name (e.g. group@e-taxonomy.eu).

The following table provides a list of currently assignable group memberships within the EDIT Federation. Specific task descriptions will be added whenever necessary.

| Group Name | Description | Specific Tasks |
| Developer | EDIT Developers | |
| FederationManager | EDIT Federation Administrators | Managing users and groups, connecting Service Providers |
| WP1 | Staff in EDIT Workpackage 1 | |
| WP2 | Staff in EDIT Workpackage 2 | |
| WP2.Administrator | EDITExpertNet Administrators | |
| WP2.!GeneralEditor | EDITExpertNet General Editor group | |
| WP2.!SocietyEditor | EDITExpertNet Society Editor group | |
| WP2.!TaxonomicExpert | EDITExpertNet Expert group | |
| WP3 | Staff in EDIT Workpackage 3 | |
| WP4 | Staff in EDIT Workpackage 4 | |
| WP5 | Staff in EDIT Workpackage 5 | |
| WP5.Administrator | EDIT Workpackage 5 web site administrators| Administrating WP5 web sites |
| WP5.Editor | WP5-Blog Editors | |
| WP5.Librarian | EDIT GRIB Librarians | |
| WP5.!SystemAdministrator | EDIT Workpackage 5 system administrators | |
| WP6 | Staff in EDIT Workpackage 6 | |
| WP6.Chichorieae | Chichorieae Web Portal users | |
| WP6.Diptera | Diptera Web Portal users | |
| WP6.Palmae | Palmae Web Portal users | |
| WP7 | Staff in EDIT Workpackage 7 | |
| WP8 | Staff in EDIT Workpackage 8 | |
| WP9 | Staff in EDIT Workpackage 9 | |
| WP10 | Staff in EDIT Workpackage 10 | |

eduPersonPrincipalName (EDIT)

This attribute represents the login name of EDIT users, as it will be created during user registration with OpenSSO.

Currently, the attribute value is not scoped as proposed by the eduPerson schema. That means, no domain identifier (e.g. user@e-taxonomy.eu) is appended. The ladder may be subject of change.

eduPersonTargetedID (EDIT)

The eduPersonTargetedID is an identifier, uniquely representing a specific user account even if e.g. the user name may change. Currently, we the raw value, as it was generated by OpenSSO on user registration. It is unscoped, so no domain identifier (e.g. xyz12345@e-taxonomy.eu) is appended. The ladder may be subject of change.


Attribute Scratchpad

The following table shows a list of any attributes being discussed so far. As such, it serves as a kind of scratchpad memorising any attributes considered to be possibly added to the current attribute set.

Therewith, each entry provides a link to more detailed information regarding the attribute. If there are EDIT specific interpretations available, then the link directs to these descriptions first. Otherwise, the link points at the description available in the general attribute overview. Furthermore, the formatting of the attribute name indicates its current status:

  • attribute considered for usage

  • attribute must not be editable by the user himself

  • attribute is not used

Besides the attribute names, the column Experts-DB metadata denotes intersections with specific metadata entries within the Experts-DB. Authorisation marks this attribute as critical such as it is intended to be used in authorisation processes on service providers. Environment variable denotes the web server environment variable, which will be used to deliver the attribute value to the requesting service provider application. Finally, the Notes column may hold additional remarks regarding the attribute.

Regarding security policies, assigning yes to an attribute's Authorisation column, this fact implies that those attribute value must never be edited by the user itself. These attribute values must only be assigned by administrators of the given institution, because these attribute may have high impact on the security policies of service providers. Therefore, these attribute has to be protected from illegal modification in any case! Otherwise, this may result in significant damage on the trustworthiness and reputation of the issuing institution and may cause the severe restrictions on all services which might be accessed by their institutional members.

| Shibboleth attribute | Experts-DB metadata | Authorisation | Environment variable | Notes |
| editNomenclaturalCode | | | HTTP_SHIB_EDIT_NOMENCLATURALCODE | details see below |
| -editTaxonomicFocus-| | | HTTP_SHIB_EDIT_TAXONOMICFOCUS | details see below |
| editGeographicFocus | | | HTTP_SHIB_EDIT_GEOGRAPHICFOCUS | details see below |
| eduPersonAffiliation | | yes | HTTP_SHIB_EDUPERSON_AFFILIATION | |
| eduPersonNickname | Name->Nickname | | HTTP_SHIB_EDUPERSON_NICKNAME | |
| eduPersonOrgDN | | | | |
| eduPersonOrgUnitDN | | | | |
| eduPersonPrimaryAffiliation | | yes | HTTP_SHIB_EDUPERSON_PRIMARYAFFILIATION | |
| eduPersonPrimaryOrgUnitDN | | | | |
| eduPersonPrincipalName | | yes | REMOTE_USER | |
| eduPersonEntitlement | | yes | HTTP_SHIB_EDUPERSON_ENTITLEMENT | |
| eduPersonPrimaryOrgUnitDN | | | | |
| eduPersonScopedAffiliation | | yes | HTTP_SHIB_EDUPERSON_SCOPEDAFFILIATION | |
| eduPersonTargetedID | | | | To be added later |
| audio | | | | to be avoided |
| cn | | | HTTP_SHIB_CN | |
| description | | | | |
| displayName | | | | |
| facsimileTelephoneNumber | Phone/Communications->Fax | | | |
| givenName | Name->First&middle name (first part) | | HTTP_SHIB_GIVENNAME | Name->First&middle name must be concatenated of both attributes givenName and initials |
| homePhone | | | | |
| homePostalAddress | | | | |
| initials | Name->First&middle name (last part) | | HTTP_SHIB_INITIALS | |
| jpegPhoto | | | HTTP_SHIB_JPEGPHOTO | |
| l | Mailing Address->Country + Mailing Address->City | | HTTP_SHIB_L| Must be transformed somehow, because locality may describe both country and city.|
| labeledURI | Internet URL | | | In eduPerson related to the home page of the object, not its institution |
| mail | E-Mail->E-mail | | HTTP_SHIB_MAIL| Likely only one! - Used e.g. by Drupal as second mandatory item besides login name. |
| manager | | | | |
| mobile | Phone/Communications->Mobile | | | |
| o | Institution->Institution | yes | HTTP_SHIB_O| |
| ou | Institution->Division/Department | yes | HTTP_SHIB_OU | |
| pager | | | | |
| postalAddress | | | | |
| postalCode | Mailing Address->Postal or ZIP code | | | |
| postOfficeBox | | | | |
| preferredLanguage | | | HTTP_SHIB_PREFERREDLANGUAGE| |
| seeAlso | | | | |
| sn | Name->Last Name | | HTTP_SHIB_SN | |
| st | Mailing Address->State/Province | | | |
| street | Mailing Address->Street Address | | | |
| telephoneNumber | Phone/Communications->Phone | | | |
| title | Name->Title | | HTTP_SHIB_TITLE | |
| uid | | | HTTP_SHIB_UID | |
| uniqueIdentifier | | | | to be avoided |
| userCertificate | | | | |
| userPassword | | | HTTP_SHIB_USERPASSWORD | |
| userSMIMECertificate | | | | |
| x500uniqueIdentifier | | | | to be avoided |

Possible attributions to Experts Database profile

*None*.

General overview of considerable attribute definitions

With this section, an overview shall be given on attributes and their definitions which have been considered already or may be considered in the future for being part of EDIT federation's set of attributes. The attribute descriptions are subdivided into the following groupings:

While the group of EDIT specific attribute definitions result from EDIT WP5 internal discussions, the common Shibboleth attributes and other person attributes have been formatted based on the EduPerson Object Class Specification (200604a) .

The general intention of this section is to prepare the ground for quicker access to relevant attribute information when discussing possible attribute inclusion into the EDIT federation.

EDIT specific attribute definitions

The EDIT specific attributes are mainly focussing on individual taxonomic expertise and interest of the given user. As such, the following list comprises the currently considered attributes. Since, this list has to be seen as work in progress, it may be subject to further modifications.


editNomenclaturalCode

| Syntax | Number of values | Equality | Utility class |
| DirectoryString | single | caseIgnoreMatch | |

Primary nomenclatural code used.

Permissible values
  • ICBN (botany)

  • ICZN (zoology)

  • ICNCP (cultivated plants)

  • ICNB (bacteria)

  • ICTV (viruses)


editTaxonomicFocus

| Syntax | Number of values | Equality | Utility class |
| DirectoryString | multi | caseIgnoreMatch | |

A higher taxonomic group the user's work is focussed on.


editGeographicFocus

| Syntax | Number of values | Equality | Utility class |
| DirectoryString | multi | caseIgnoreMatch | |

A geographic region the user's work is focussed on.


eduPerson Attribute Definitions

The eduPerson attribute definitions may be specified for the following attributes:


eduPersonAffiliation

| Syntax | Number of values | Equality | Utility class |
| DirectoryString | multi | caseIgnoreMatch | standard |

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

Common values found in academia are: faculty, student, staff, alum, member, affiliate, employee, library-walk-in

Permissible values

faculty, student, staff, alum, member, affiliate, employee

Notes

If there is a value in eduPersonPrimaryAffiliation, that value should be stored here as well.

The list of allowed values in the current version of the object class is CERTAINLY incomplete. We felt that any additional values should come out of discussions with the stakeholder communities. Any agreed-upon additional values will be included as part of the later versions of eduPerson.

We also deliberately avoided including a value such as "other" or "misc" because it would be semantically equivalent to "none of the above." To indicate "none of the above," for a specific person, leave the attribute empty.

Member::

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

Affiliate::

is intended to apply to people with whom the university has dealings, but to whom no general set of "community membership" privileges are extended.

Library-walk-in::

This value is intended to facilitate the handling of a fairly widely encountered agreement between an institution and licensed resource providers that e-resources may be made accessible to students, faculty, staff and library walk-ins. This term originally indicated people who were physically present in a library facility. In recent years the library walk-in provision has been extended to cover other cases such as library users on the campus network, or those using on-campus workstations. Licensed resource providers have often been willing to interpret their contracts with licensees to accept this broader definition of "library-walk-in," though specific terms may vary. Under appropriate licensing terms, it is valid to assert an affiliation of "library-walk-in" for members of this broader class of users. The affiliation "library-walk-in" is independent of any other affiliation value. In other words, having the affiliation "library-walk-in" has no effect, positive or negative, on any of the other defined affiliation values. Similarly, no other affiliation value implies or precludes the affiliation "library-walk-in."

Semantics::

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

A reasonable person should find the listed relationships commonsensical

Examples

Applications for which this attribute would be useful:

  • white pages

  • controlling access to resources


eduPersonEntitlement

| Syntax | Number of values | Equality | Utility class |
| DirectoryString | multi | caseIgnoreMatch | extended |

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

Possible attributions to Experts Database profile

*None*.

Notes

A simple example would be a URL for a contract with a licensed resource provider. When a principal's home institutional directory is allowed to assert such entitlements, the business rules that evaluate a person's attributes to determine eligibility are evaluated there. The target resource provider does not learn characteristics of the person beyond their entitlement. The trust between the two parties must be established out of band. One check would be for the target resource provider to maintain a list of subscribing institutions. Assertions of entitlement from institutions not on this list would not be honored. See the first example below.

URN values would correspond to a set of rights to resources based on an agreement across the relevant community. MACE (Middleware Architecture Committee for Education) affiliates may opt to register with MACE as a naming authority, enabling them to create their own URN values. See the second example below.

The driving force behind the definition of this attribute has been the MACE Shibboleth project. Shibboleth defines an architecture for inter-institutional sharing of web resources subject to access controls. For further details, see the project's web pages at http://shibboleth.internet2.edu/.

Examples

Applications for which this attribute would be useful::

  • controlling access to resources

eduPersonNickname

| Syntax | Number of values | Equality | Utility class |
| DirectoryString | multi | caseIgnoreMatch | standard |

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

Possible attributions to Experts Database profile

*None*.

Notes

Most often a single name as opposed to displayName which often consists of a full name. Useful for user-friendly search by name. As distinct from the cn (common name) attribute, the eduPersonNickname attribute is intended primarily to carry the person's preferred nickname(s). E.g., Jack for John, Woody for Durwood, JR for Joseph Robert.

Carrying this in a separate attribute makes it relatively easy to make this a self-maintained attribute If it were merely one of the multiple values of the cn attribute, this would be harder to do. A review step by a responsible adult is advisable to help avoid institutionally embarrasing values being assigned to this attribute by would-be malefactors!

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

Examples
  • eduPersonNickname: Spike

Applications for which this attribute would be useful::

  • white pages

eduPersonOrgDN

| Syntax | Number of values | Equality | Utility class |
| distinguishedName | single | distinguishedNameMatch | core |

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

Possible attributions to Experts Database profile

*None*.

Notes

With a distinguished name, the client can do an efficient lookup in the institution's directory to find out more about the organization with which the person is associated.

Cn (common name), sn (surname, family name) and this attribute, eduPersonOrgDN, are the three attributes satisfying the "core" application utility class of eduPerson.

Semantics::

The directory entry pointed to by this dn should be represented in the X.521(2001) "organization" object class

The attribute set for organization is defined as follows::

o (Organization Name, required}

Optional attributes include::

description, localeAttributeSet, postalAttributeSet, telecommunicationsAttributeSet, businessCategory, seeAlso, searchGuide, userPassword

Examples
  • eduPersonOrgDN: o=Hogwarts, dc=hsww, dc=wiz

Applications for which this attribute would be useful::

  • white pages

eduPersonOrgUnitDN

| Syntax | Number of values | Equality | Utility class |
| distinguishedName | multi | distinguishedNameMatch | standard |

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.

Possible attributions to Experts Database profile

*None*.

Notes

With a distinguished name, the client can do an efficient lookup in the institution's directory for information about the person's organizational unit(s).

Semantics::

The directory entry pointed to by this dn should be represented in the X.521(2001) "organizational unit" object class.

In addition to organizationalUnitName, this object class has the same optional attribute set as the organization object class::

ou (Organization Unit Name, required) Note that O is NOT required.

Optional attributes include::

description, localeAttributeSet, postalAttributeSet, telecommunicationsAttributeSet, businessCategory, seeAlso, searchGuide, userPassword

Examples
  • eduPersonOrgUnitDN: ou=Potions, o=Hogwarts, dc=hsww, dc=wiz

Applications for which this attribute would be useful::

  • white pages

eduPersonPrimaryAffiliation

| Syntax | Number of values | Equality | Utility class |
| directoryString | single | caseIgnoreMatch | standard |

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

Permissible values

faculty, student, staff, alum, member, affiliate, employee, library-walk-in

Possible attributions to Experts Database profile

*None*.

Notes

Appropriate if the person carries at least one of the defined eduPersonAffiliations. The choices of values are the same as for that attribute.

Think of this as the affiliation one might put on the name tag if this person were to attend a general institutional social gathering. Note that the single-valued eduPersonPrimaryAffiliation attribute assigns each person in the directory into one and only one category of affiliation. There are application scenarios where this would be useful.

The list of allowed values in the current version of the object class is CERTAINLY incomplete. We felt that any additional values should come out of discussions with the stakeholder communities. Any agreed-upon additional values will be included as part of future versions of eduPerson.

We also deliberately avoided including a value such as "other" or "misc" because it is semantically equivalent to "none of the above." To indicate "none of the above," for a specific person, leave the attribute unpopulated.

Member::

is intended to include faculty, staff, student, and other persons granted a basic set of privileges that go with membership in the university community (e.g., library privileges). It could be glossed as "member in good standing of the university community."

Affiliate::

is intended to apply to people with whom the university has dealings, but to whom no general set of "community membership" privileges are extended.

Library-walk-in::

This value is intended to facilitate the handling of a fairly widely encountered agreement between an institution and licensed resource providers that e-resources may be made accessible to students, faculty, staff and library walk-ins. This term originally indicated people who were physically present in a library facility. In recent years the library walk-in provision has been extended to cover other cases such as library users on the campus network, or those using on-campus workstations. Licensed resource providers have often been willing to interpret their contracts with licensees to accept this broader definition of "library-walk-in," though specific terms may vary. Under appropriate licensing terms, it is valid to assert an affiliation of "library-walk-in" for members of this broader class of users. The affiliation "library-walk-in" is independent of any other affiliation value. In other words, having the affiliation "library-walk-in" has no effect, positive or negative, on any of the other defined affiliation values. Similarly, no other affiliation value implies or precludes the affiliation "library-walk-in."

Semantics::

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

A reasonable person should find the listed relationships commonsensical.

Examples
  • eduPersonPrimaryAffiliation: student

Applications for which this attribute would be useful::

  • controlling access to resources

eduPersonPrimaryOrgUnitDN

| Syntax | Number of values | Equality | Utility class |
| distinguishedName | single | distinguishedNameMatch | extended |

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

Possible attributions to Experts Database profile

*None*.

Notes

Appropriate if the person carries at least one of the defined eduPersonOrgUnitDN. The choices of values are the same as for that attribute.

Semantics::

Each institution populating this attribute decides the criteria for determining which organization unit entry is the primary one for a given individual.

Examples
  • eduPersonPrimaryOrgUnitDN: ou=Music Department, o=Notre Dame, dc=nd, dc=edu

Applications for which this attribute would be useful::

  • white pages

eduPersonPrincipalName

| Syntax | Number of values | Equality | Utility class |
| directoryString | single | caseIgnoreMatch | standard |

The "NetID" of the person for the purposes of inter-institutional authentication. It should be represented in the form "user@scope" where scope defines a local security domain. Multiple "@" signs are not recommended, but in any case, the first occurrence of the "@" sign starting from the left is to be taken as the delimiter between components. Thus, user identifier is to the left, security domain to the right of the first "@". This parsing rule conforms to the POSIX "greedy" disambiguation method in regular expression processing. When the scope is a registered domain name, the corresponding registrant organization is to be taken as the scope. For example, francis@trinity.edu would imply that the identity behind the ePPN has the "NetID" "francis" at the instituion of higher education that registered itself with the domain name "trinity.edu." If other value styles are used, their semantics will have to be profiled by the parties involved. Each value of scope defines a namespace within which the assigned principal names are unique. Given this rule, no pair of eduPersonPrincipalName values should clash. If they are the same, they refer to the same principal within the same administrative domain.

Possible attributions to Experts Database profile

*None*.

Notes

If populated, the user should be able to authenticate with this identifier, using locally operated services. Local authentication systems should be able to adequately affirm (to both local and remote applications) that the authenticated principal is the person to whom this identifier was issued.

The initial intent is to use this attribute within the Shibboleth project, http://shibboleth.internet2.edu/. However, it has quickly become clear that a number of other applications could also make good use of this attribute (e.g. H.323 video, chat software, etc). eduPersonPrincipalName (EPPN) would be used as follows: A resource owner, A, would look at B's directory entry to discover B's EPPN. A would then tell the local authorization system that B's EPPN is allowed to use the resource. When B tries to access the resource, the application (or access control infrastructure) would validate B's identity, check with the local authorization system to ensure that B has been granted the appropriate access privileges, and then either grant or deny access.

EPPN looks like a Kerberos identifier (principal@realm). A site might choose to locally implement EPPN as Kerberos principals. However, this is not a requirement. A site can choose to do authentication in any way that is locally acceptable.

Likewise, EPPN should NOT be confused with the user's published email address, although the two values may be the same. Some sites have chosen to make the user portion of email addresses and security principals the same character string; other sites have chosen not to do this. Even when they appear to be the same, they are used in different subsystems and for different purposes, and there is no requirement that they have to remain the same.

The uid attribute of the user's object within the local white pages directory may also contain a login id, a security principal; some systems (eg NDS) may put a login id in the cn attribute. These attributes are defined within objectclasses that are universal. Unfortunately, their use is not prescribed in a sufficiently precise and consistent manner for use with cross domain authorization. A variety of systems already make conflicting use of these attributes; consequently, we have defined this new attribute.

An assumption is that EPPNs are managed on an enterprise basis by the univ of univ.edu. A particular EPPN is assigned solely to the associated user; it is not a security principal identifier shared by more than one person. Lastly, each EPPN is unique within the local security domain.

How long, if ever, before a formerly assigned EPPN is reassigned to a differrent individual is an institutional decision. Some institutions will choose never to reassign EPPNs. Others may opt for a relatively short hiatus before reassignment. While this complicates the work of the relying parties, it is unavoidable given institutional autonomy. See MACE best practice documents on identifiers for further discussion of these issues.

This attribute should prove useful in creating some applications that are based on currently deployed technologies and on code that does not currently use LDAP or require a PKI. This attribute should help to create a framework to foster interesting inter-institutional collaborations between sites that use different technologies. In short, this attribute provides a foundation for yet another abstraction layer.

Examples

Applications for which this attribute would be useful::

  • controlling access to resources

eduPersonScopedAffiliation

| Syntax | Number of values | Equality | Utility class |
| directoryString | multi | caseIgnoreMatch | standard |

Specifies the person's affiliation within a particular security domain in broad categories such as student, faculty, staff, alum, etc. The values consist of a left and right component separated by an "@" sign. The left component is one of the values from the eduPersonAffiliation controlled vocabulary. This right-hand side syntax of eduPersonScopedAffiliation intentionally matches that used for the right-hand side values for eduPersonPrincipalName since both identify a security domain. Multiple "@" signs are not recommended, but in any case, the first occurrence of the "@" sign starting from the left is to be taken as the delimiter between components. Thus, user identifier is to the left, security domain to the right of the first "@". This parsing rule conforms to the POSIX "greedy" disambiguation method in regluar expression processing.

Permissible values

See controlled vocabulary for eduPersonAffiliation. Only these values are allowed to the left of the "@" sign. The values to the right of the "@" sign should indicate a security domain.

Possible attributions to Experts Database profile

*None*.

Notes

Consumers of eduPersonScopedAffiliation will have to decide whether or not they trust values of this attribute. In the general case, the directory carrying the eduPersonScopedAffiliation is not the ultimate authoritative speaker for the truth of the assertion. Trust must be established out of band with respect to exchanges of this attribute value.

Semantics::

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

Examples

Applications for which this attribute would be useful::

  • white pages

  • controlling access to resources


eduPersonTargetedID

| Syntax | Number of values | Equality | Utility class |
| undefined | multi | undefined | extended |

A persistent, non-reassigned, privacy-preserving identifier for a principal shared between a pair of coordinating entities, denoted by the SAML 2 architectural overview (1) as identity provider and service provider (or a group of service providers). An identity provider uses the appropriate value of this attribute when communicating with a particular service provider or group of service providers, and does not reveal that value to any other service provider except in limited circumstances.

Possible attributions to Experts Database profile

*None*.

Notes

While this attribute might not be stored as such in a typical Directory Service, it may be produced by a Directory Service. In any case, it is defined here for potential use in other service contexts such as Security Assertion Markup Language (SAML) assertions.

EduPersonTargetedID values should not be reassigned.

Persistence::

eduPersonTargetedID does not require a specific lifetime, but the association SHOULD be maintained longer than a single user interaction and long enough to be useful as a key for a particular service that is consuming it. Protocols might also be used to refresh (or roll-over") an identifier to maintain the user's privacy by communicating such changes to service providers to avoid a loss of service. See "(2) for an example of such a protocol.

Privacy::

This attribute is designed to preserve the principal's privacy and inhibit the ability of multiple unrelated services from correlating principal activity by comparing values. It is therefore REQUIRED to be opaque, having no particular relationship to the principal's other identifiers, such as a username or eduPersonPrincipalName. It SHOULD be considerably difficult for an observer to guess the value that would be returned to a given service provider.

It MAY be a pseudorandom value generated and stored by the identity provider, or MAY be derived from some function over the service provider's identity and other principal-specific input(s), such as a serial number or UUID assigned by the identity provider.

It MUST NOT exceed 256 characters in length.

Uniqueness::

A value of this attribute is intended only for consumption by a specific audience of applications (often a single one). Values of this attribute therefore MUST be unique within the namespace of the identity provider and the namespace of the service provider(s) for whom the value is created. The value is qualified" by these two namespaces and need not be unique outside them. Logically, the attribute value is made up of the triple of an identifier, the identity provider, and the service provider(s). "(2) suggests a possible naming scheme for such qualifiers based on URIs.

Reassignment::

A distinguishing feature of this attribute is that it prohibits re-assignment. Since the values are opaque, there is no meaning attached to any particular value beyond its identification of the principal. Therefore particular values created by an identity provider MUST NOT be re-assigned such that the same value given to a particular service provider refers to two different principals at different points in time.

(1) http://www.oasis-open.org/committees/download.php/7521/

(2) http://www.oasis-open.org/committees/download.php/10627/

Examples

Applications for which this attribute would be useful::

  • Service providers or directory-enabled applications with the need to maintain a persistent but opaque identifier for a given user for purposes of personalization or record-keeping.

  • Identity or service providers or directory-enabled applications with the need to link an external account to an internal account maintained within their own system. This attribute is often used to represent a long-term account linking relationship between an identity provider and service provider(s). Note that such a service provider might itself also be an identity provider.


Other Common Person Attributes

The attributes in the following section are from other standard object classes or attribute definitions. It is not a complete list of such attributes, but in any case where the eduPerson working group considered that some comment was needed to clarify the meaning or utility of an attribute, it can be found here. For details on the syntax and other aspects of these attributes, see the appropriate standards documents.

audio

| Number of values | Utility class |
| undefined | none |

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

Possible attributions to Experts Database profile

*None*.

Notes

Avoid. Not clearly defined, no defacto standard.


cn

| Number of values | Utility class |
| multi | core |

Common name.

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

Possible attributions to Experts Database profile

*None*.

Notes

Required. One of the two required attributes in the person object class (the other is sn). As such it is one of three recommended "core application utility" attributes. The third is eduPersonOrgDN.

With eduPersonOrgDN and cn, the client knows the person's name and the distinguished name of the organization with which he/she is associated. The latter could help them find a directory entry for the person's organization.

This attribute is often overloaded in the sense that many applications act as if this were "their" attribute, and therefore add values to this attribute as they see fit. Because of that it is impossible to give a precise and accurate definition of what this field means.

Examples
  • cn: Mary Francis Xavier

Applications for which this attribute would be useful::

  • all

description

| Number of values | Utility class |
| multi | standard |

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

Possible attributions to Experts Database profile

*None*.

Notes

Can be anything.

Examples
  • description: A jolly good felon

Applications for which this attribute would be useful::

  • white pages

displayName

| Number of values | Utility class |
| single | standard |

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

Possible attributions to Experts Database profile

*None*.

Notes

Cn (common name) is multi-valued and overloaded to meet the needs of multiple applications. displayName is a better candidate for use in DoD white pages and configurable email clients.

Examples
  • displayName: Jack Dougherty

Applications for which this attribute would be useful::

  • white pages

  • email client


facsimileTelephoneNumber

| Number of values | Utility class |
| multi | extended |

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

Semantics::

A fax number for the directory entry.

Possible attributions to Experts Database profile

*None*.

Examples
  • facsimileTelephoneNumber: +44 71 123 4567

Applications for which this attribute would be useful::

  • white pages

givenName

| Number of values | Utility class |
| multi | standard |

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

Possible attributions to Experts Database profile

*None*.

Examples
  • givenName: Stephen

homePhone

| Number of values | Utility class |
| multi | extended |

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

Possible attributions to Experts Database profile

*None*.

Notes

In RFC 1274, this was originally called homeTelephoneNumber.

Examples
  • homePhone: +1 608 555 1212

Applications for which this attribute would be useful::

  • white pages

homePostalAddress

| Number of values | Utility class |
| multi | extended |

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

Semantics::

Home address. OrgPerson has a PostalAddress that complements this attribute.

Possible attributions to Experts Database profile

*None*.

Examples
  • homePostalAddress: 1212 Como Ave.$Midton, SD 45621

Applications for which this attribute would be useful::

  • white pages

initials

| Number of values | Utility class |
| multi | extended |

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

Possible attributions to Experts Database profile

*None*.

Examples
  • initials: f x

jpegPhoto

| Number of values | Utility class |
| multi | extended |

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

Semantics::

A smallish photo in jpeg format.

Possible attributions to Experts Database profile

*None*.

Examples

Applications for which this attribute would be useful::

  • white pages

l

| Number of values | Utility class |
| multi | extended |

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

Possible attributions to Experts Database profile

*None*.

Examples
  • l: Hudson Valley

Applications for which this attribute would be useful::

  • white pages

labeledURI

| Number of values | Utility class |
| multi | extended |

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

Possible attributions to Experts Database profile

*None*.

Notes

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

Note from RFC 2079: "The labeledURI attribute type has the caseExactString syntax (since URIs are case-sensitive) and it is multivalued. Values placed in the attribute should consist of a URI (at the present time, a URL) optionally followed by one or more space characters and a label. Since space characters are not allowed to appear un-encoded in URIs, there is no ambiguity about where the label begins. At the present time, the URI portion must comply with the URL specification.

Multiple labeledURI values will generally indicate different resources that are all related to the X.500 object, but may indicate different locations for the same resource.

The label is used to describe the resource to which the URI points, and is intended as a friendly name fit for human consumption. This document does not propose any specific syntax for the label part. In some cases it may be helpful to include in the label some indication of the kind and/or size of the resource referenced by the URI.

Note that the label may include any characters allowed by the caseExactString syntax, but that the use of non-IA5 (non-ASCII) characters is discouraged as not all directory clients may handle them in the same manner. If non-IA5 characters are included, they should be represented using the X.500 conventions, not the HTML conventions (e.g., the character that is an "a" with a ring above it should be encoded using the T.61 sequence 0xCA followed by an "a" character; do not use the HTML escape sequence "&aring").

Examples

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 r1). 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

Applications for which this attribute would be useful::

  • white pages

mail

| Number of values | Utility class |
| multi | standard |

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

Possible attributions to Experts Database profile

*None*.

Notes

Preferred address for the "to:" field of email to be sent to this person. Usually of the form localid@univ.edu. Likely 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, routing, etc. (http://www.duke.edu/~gettes/giia/ldap-recipe/).

Note: RFC 1274 uses the longer name 'rfc822Mailbox' and syntax OID of 0.9.2342.19200300.100.3.5. All recent LDAP documents and most deployed LDAP implementations refer to this attribute as 'mail' and define the IA5 String (ASCII string) syntax using using the OID 1.3.6.1.4.1.1466.115.121.1.26.

Semantics::

Preferred address for the "to:" field of email to be sent to this person.

Examples

Applications for which this attribute would be useful::

  • white pages

  • email client


manager

| Number of values | Utility class |
| multi | undefined |

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.

Possible attributions to Experts Database profile

*None*.

Notes

This attribute carries the DN of the manager of the person represented in this entry.

Examples
  • manager: uid=twilliams, ou=people, dc=hobart, dc=edu

Applications for which this attribute would be useful::

  • white pages

mobile

| Number of values | Utility class |
| multi | extended |

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

Possible attributions to Experts Database profile

*None*.

Notes

cellular or mobile phone number.

RFC 1274 uses the longer name 'mobileTelephoneNumber.'

Semantics::

cellular or mobile phone number.

Examples
  • mobile: +47 22 44 66 88

Applications for which this attribute would be useful::

  • white pages

o

| Number of values | Utility class |
| multi | standard |

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

Possible attributions to Experts Database profile

*None*.

Notes

Likely only one value.

Meant to carry the TOP-LEVEL organization name. Do not use this attribute to carry school college names.

Examples
  • o: St. Cloud State

Applications for which this attribute would be useful::

  • white pages

ou

| Number of values | Utility class |
| multi | standard |

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

Possible attributions to Experts Database profile

*None*.

Examples
  • ou: Faculty Senate

Applications for which this attribute would be useful::

  • white pages

pager

| Number of values | Utility class |
| multi | extended |

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

Possible attributions to Experts Database profile

*None*.

Notes

RFC 1274 uses the longer name 'pagerTelephoneNumber.'

Semantics::

pager number

Examples
  • pager: +1 202 555 4321

Applications for which this attribute would be useful::

  • white pages

postalAddress

| Number of values | Utility class |
| multi | extended |

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

Possible attributions to Experts Database profile

*None*.

Notes

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

Semantics::

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

Examples
  • postalAddress: P.O. Box 333$Whoville, WH 99999

Applications for which this attribute would be useful::

  • white pages

postalCode

| Number of values | Utility class |
| multi | extended |

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.

Possible attributions to Experts Database profile

*None*.

Notes

ZIP code in USA, postal code for other countries.

Semantics::

Zip code in USA, postal code for other countries.

Examples
  • postalCode: 54321

Applications for which this attribute would be useful::

  • white pages

postOfficeBox

| Number of values | Utility class |
| multi | extended |

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

Possible attributions to Experts Database profile

*None*.

Notes

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

Examples
  • postOfficeBox: 109260

Applications for which this attribute would be useful::

  • white pages

preferredLanguage

| Number of values | Utility class |
| single | extended |

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

Permissible values (if controlled)

See RFC2068 and ISO 639 for allowable values in this field. Esperanto, for example is EO in ISO 639, and

RFC2068 would allow a value of en-US for US English.

Possible attributions to Experts Database profile

*None*.

Examples
  • preferredLanguage: EO

Applications for which this attribute would be useful::

  • white pages

seeAlso

| Number of values | Utility class |
| multi | standard |

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

Semantics::

The distinguished name of another directory entry.

Possible attributions to Experts Database profile

*None*.

Examples
  • seeAlso: cn=Department Chair, ou=physics, o=University of Technology, dc=utech, dc=ac, dc=uk

Applications for which this attribute would be useful::

  • white pages

sn

| Number of values | Utility class |
| multi | core |

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

Possible attributions to Experts Database profile

*None*.

Notes

Required. One of the two required attributes in the person object class from which eduPerson derives (the other is cn). As such it is one of eduPerson's three "core application utility" attributes. The third is eduPersonOrgDN.

If the person has a multi-part surname (whether hyphenated or not), store both 1) the whole surname including hyphens if present and 2) each component of a hyphenated surname as a separate value in this multi-valued attribute. That yields the best results for the broadest range of clients doing name searches.

Examples
  • sn: Carson

Applications for which this attribute would be useful::

  • all

st

| Number of values | Utility class |
| multi | extended |

Abbreviation for state or province name.

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

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

Permissible values (if controlled)

For states in the United States, U.S. Postal Service set of two-letter state name abbreviations.

Possible attributions to Experts Database profile

*None*.

Notes

State or province name. While RFC 2256 specifies use of the "full name," it is customary to use the U.S. Postal Service set of two-letter state name abbreviations for states in the U.S. and, as noted in the definition, other nationally coordinated official abbreviations are preferred for province names.

Semantics::

Standard two-letter abbreviations for U.S. state names, other standards based abbreviations for provinces where available.

Examples
  • st: IL

Applications for which this attribute would be useful::

  • white pages

street

| Number of values | Utility class |
| multi | extended |

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)."

Possible attributions to Experts Database profile

*None*.

Examples
  • street: 303 Mulberry St.

Applications for which this attribute would be useful::

  • white pages

telephoneNumber

| Number of values | Utility class |
| multi | standard |

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

Possible attributions to Experts Database profile

*None*.

Examples
  • telephoneNumber: +1 212 555 1234

Applications for which this attribute would be useful::

  • white pages

title

| Number of values | Utility class |
| multi | extended |

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

==

Updated by Andreas Müller almost 2 years ago · 5 revisions