Page tree
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Next »

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 '' 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:

  • longevity - the length of time for which the name identifier is good. The lifetime of most name identifiers falls into three categories:
    • transient: the identifier is only good for a brief period of time (e.g. 5 minutes)
    • persistent: the identifier is good for a long period of time (e.g. years) but may eventually go away
    • permanent: the identifier is good for the lifetime of an account
  • transparency - the ability of a recipient to identify the user from the name identifier; the transparency of most name identifiers can be described as:
    • opaque, meaning the recipient can not determine anything about the precise user from the identifier. Type 3-5 UUIDs are an example of such an identifier.
    • transparent, meaning the recipient can easily determine the user from the identifier. An email address would be an example of this type of identifier.
  • targeted - whether the name identifier is meant for a specific relying party, or relying party group, and not for anyone else
  • revocable - whether a given name identifier can be revoked
  • reusable - whether a given name identifier, once revoked, may be reused

The Relationship of Name Identifiers and Attributes


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:

Email as a SAML 2 NameID
<NameID format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"></NameID>

is the same data as

Email as an Attribute
<Attribute Name="urn:oid:0.9.2342.19200300.100.1.3" FriendlyName="mail">

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.

  • No labels