Name Identifiers

A name identifier, <NameIdentifier> in SAML 1 and <NameID> in SAML 2, is generally used to identify the person that the IdP has issued an assertion about. Name identifiers can be anything; an email address or a Kerberos principal name are common, every-day examples of such information.

Name identifiers come in different types, known as formats. All formats have the following two properties: scope and reversibility. Scope means that any given identifier is issued from, and only makes sense within, a given domain. A name identifier without a scope is meaningless, because it could have come from any IdP in the world. For example, saying just the name identifier '123456' is meaningless, but saying '123456' from 'https://idp.example.org' provides the requisite scope and makes the identifier meaningful. Reversibility is the ability for an IdP to translate the identifier back into the user within the lifetime of the identifier. This is necessary to support things like attribute queries.

Name identifiers can also be described by the following characteristics:

The Relationship of Name Identifiers and Attributes

Background

In SAML 1 the IdP was the sole arbiter of which name identifier was used with a relying party. SAML 2 however introduced SAML metadata, which allows entities to indicate which formats they support, and the ability for an SP to require a particular format on a per-request basis.

Attributes and Name Identifiers

Shibboleth 2 takes the approach that a name identifier is just one of the collective set of attributes that make up a digital identity. This attribute just happens to be encoded a bit differently than some of the other attributes, but this encoding doesn't actually change the content being presented. For example:

<NameID format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">jsmith@example.org</NameID>

is the same data as

<Attribute Name="urn:oid:0.9.2342.19200300.100.1.3" FriendlyName="mail">
   <AttributeValue>jsmith@example.org</AttributeValue>
</Attribute>

It naturally followed that a deployer should then have the full power of the attribute resolution process available when constructing name identifiers. This has two main benefits. First, it allows the deployer to use arbitrarily complex, or specialized, logic for the creation of the name identifier, allowing them to tailor it to their particular environment. Second, it allows the deployer to determine which entities get which name identifiers via attribute filter policies. So the deployer is provided a unified model for pulling, preparing, and releasing data to the relying party.