Multiple values of the form value@domain, where domain is (typically) a DNS-like subdomain representing the organization or sub-organization of the affiliation (e.g., "northcarolina.edu") and value is one of:

Note that these values are NOT case-sensitive, and capital or mixed-case values are permitted (e.g., MEMBER, Member, MeMbEr), though all lower-case is recommended.

Affiliation is a high-level expression of the relationship of the user to the university or organization specified in the domain. A user can possess many affiliations, though some values are mutually exclusive. This attribute is often made available to any Shibboleth service provider, and is a good way to filter or block users of a given general type. In particular, "member" is an indication that the user is somebody with relatively official standing with a university at the present time, and does not apply to guests, other temporary accounts, terminated employees, unpaid/unregistered students, and other exceptional cases. For a list of valid domains please see the next section.

A single value of the formuser@domain, where the domain is (typically) a DNS-like subdomain representing the security domain of the user (e.g., "northcarolina.edu") and user is generally a username, NetID, UserID, etc. of the sort typically assigned for authentication to network services within the security domain.

EPPN is the eduPerson equivalent of a username. It typically has most of the properties usually associated with usernames (such as uniqueness and a naming convention of some sort), with the added property of global uniqueness through the use of a scope. An application that tracks information based on it can therefore interact with users via any number of identity providers without fear of duplicates, although the possibility for recycling/reassignment does still exist within the domain of a given identity provider. Note that at some Identity Providers a user can freely change their local account name (in the case of a name change due to marriage, for example), and the corresponding EPPN will typically change as well. This can cause a loss of service until name changes propagate throughout every application storing the value. For a less dynamic identifier, see also the eduPersonTargetedID attribute. For a list of valid domains please see the next section.

A single string value of no more than 256 characters that uniquely identifiers a user in an opaque, privacy-preserving fashion. In most cases, the value will be different for a given user for each service provider to which a value is sent, to prevent correlation of activity between service providers.

This attribute offers a powerful alternative to the use of eduPersonPrincipalName as a user identifier within applications and databases. Its power lies in the fact that it offers a significant degree of privacy and control for users. It also tends to be more stable than EPPN because it doesn't change merely in response to superficial name changes. It still may change, but generally in a more controlled fashion. It also requires a policy of non-reassignment. That is, while a given user may be associated with more than one value over time, a single value once assigned will never be assigned to any other user. When appropriate, the value can remain consistent across multiple service providers, if those systems have a demonstrated relationship and need to share information about the user's activities. Such sharing must be tightly controlled. Note that the values are not guaranteed to be unique except within a given identity provider's set of values.

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.

The address in this attribute cannot be assumed to represent an organizationally-assigned contact address for a user established as part of a strong identity-proofing process. This may be true of some organizations that assert this attribute, but some organizations may permit users to provide their own preferred address (e.g. an email account at an Internet mail service).

The domain-scoped, unique identifier that the IDP/campus wishes to use for all forms of electronic communication about the user in question. This identifier must be unique for each individual from the date of its initial assignment until the end of time. Furthermore, this number should not be open for augmentation by the user. In short, the unique field supplied here will be used by the service providers (applications) to store data about a particular user. In addition, this identifier will be used to initiate all data exchanges required by the application parameters (web services, etc). In this context, a data exchange implies "two-way" communication between a service provider and any potential campus data source (that may or may not be outside the scope of the IDP software).

This identifier should ABSOLUTELY NOT be considered FERPA sensitive information. As a good rule of thumb, this identifier should be considered public information about each user and should be publishable in a web directory (or any other form of public consumption) for all the world to see. Person A's knowledge of Person B's identifier should not empower Person A with the ability to perform any function (malicious or otherwise) on behalf of Person B. DO NOT POPULATE THIS FIELD WITH SSN. This identifier will likely be either the "BannerID" or "PIDM" or some other form of auto generated "UUID"; whatever the actual policy decision, the IDP must ensure this supplied identifier can be used consistently by ANY application for the purposes of electronic communication about the individual. If a campus has the capacity to implement eduPersonTargetedId, then it may release that attribute under this context.