Welcome Guest / Please Login
Chapter 1. Identity Attributes

Chapter 1. Identity Attributes

1. Overview

The Federation, purposefully, does not define an exhaustive set of identity attributes. Attribute exchange is a function of the application within the Federation, not the Federation itself. In other words, it is unreasonable for the Federation to adequately list all possible attributes needed by all applications. However, the Federation establishes standards and practices for establishing and exchanging attributes.

Federation members should take great care to not reinvent the wheel; in other words, if the attribute needed for a particular application already has an existing, widely adopted definition, then participants should use the existing standard instead of creating a custom attribute that will exist only within the scope of the application. Participants should take great care to ensure newly created attributes do not overlap with existing standards.

The remainder of this document outlines the common set of baseline attributes that each identity provider and application can use to provide distributed services to the Federation community. Again, this not an exhaustive list, but serves as a baseline of attributes that can be reliably supplied by identity providers.


These attributes are designed to be consistent with the InCommon Federation to maintain consistency with other higher education institutions. See [InCommon Federation Attribute Summary] for reference.

2. Attribute Summary

The following list represents the column headings for the subsequent summary table:


A short name for the attribute.

Formal Name

The formal name of the attribute when expressed in a SAML assertion in accordance with the [MACE-Dir SAML Attribute Profiles (PDF)].

Default HTTP Header

The default HTTP header name for the attribute, as seen by most applications using Shibboleth 2 out of the box (but this can be anything).


An informal description of the value syntax of the attribute


Indicates whether the attribute is multi-valued

Table 1.1. Attribute Summary
NameFormal NameDefault HTTP HeaderDatatypeMulti?
eduPersonScopedAffiliationurn:mace:dir:attribute-def:eduPersonScopedAffiliationHTTP_SHIB_EP_AFFILIATIONDomain-Qualified String EnumerationY
eduPersonPrincipalNameurn:mace:dir:attribute-def:eduPersonPrincipalNameHTTP_SHIB_EP_PRINCIPALNAMEDomain-Qualified StringN
eduPersonTargetedIdurn:oid:, max. 256 charactersN
campusPermanentIdfederation.northcarolina.edu.campusPermanentIdHTTP_SHIB_CAMPUSPERMANENTIDDomain-Qualified StringN

2.1. eduPersonScopedAffiliation

2.1.1. Description

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:

  • member

  • student

  • employee

  • faculty

  • staff

  • alum

  • affiliate

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.

2.1.2. Usage Notes

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.

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

2.2. eduPersonPrincipalName

2.2.1. Description

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.

2.2.2. Usage Notes

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.

2.3. eduPersonTargetedID

2.3.1. Description

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.

2.3.2. Usage Notes

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.

2.4. sn

Multiple string values containing components of the users' "family" name or surname. In other words, the individual's "last name" using western conventions.

2.5. givenName

Multiple string values containing the part of the user's name that is not their surname or middle name. In other words, the individual's "first name" using western conventions.

2.6. displayName

A single string value indicating the preferred name of a person to be used for display purposes, for example a greeting or a descriptive listing.

2.7. mail

2.7.1. Description

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.

2.7.2. Usage Notes

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

2.8. logoutURL

A Uniform Resource Locator (URL) designed to provide federated logout for applications within the UNC Federation. This is a stop-gap measure to ensure security until Shibboleth fully implements federated logout as described in the SAML 2.0 specification. For more details see: https://federation.northcarolina.edu/web/metadata.htm#SLO

Example: https://idp.northcarolina.edu/idp/logout.jsp

2.9. campusPermanentId

2.9.1. Description

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

2.9.2. Usage Notes

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.

2.9.3. Examples

  • 012345678901234567@northcarolina.edu

  • 99999999999@uncg.edu

  • 2@ecu.edu

3. Valid Domains

For each of the scoped attributes listed above, the base of the domain must be within this list:

  • appstate.edu

  • ecu.edu

  • ecsu.edu

  • uncfsu.edu

  • ncat.edu

  • nccu.edu

  • uncsa.edu (ncarts.edu as legacy)

  • ncsu.edu

  • unca.edu

  • unc.edu

  • uncc.edu

  • uncg.edu

  • uncp.edu

  • uncw.edu

  • wcu.edu

  • wssu.edu

  • ncssm.edu

  • northcarolina.edu

  • unctv.org

  • mcnc.org