In SAML 1 the IdP was the sole arbiter of which name identifier was used for a user at any given point. Prior to the SAML 1 extensions for SAML metadata there wasn't a standard way for the SP to suggest which type, known as formats in SAML, of name identifiers it supported. SAML 2 however introduced not only SAML metadata, which allows entities to indicate which formats they support, but also added the ability for an SP to require a particular format.
Shibboleth 2 takes the approach that a name identifier is just one of the collective set of attributes that make up your 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:
is the same data as
<Attribute Name="urn:oid:0.9.2342.19200300.100.1.3" FriendlyName="mail"> <AttributeValue>firstname.lastname@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 the attribute filter policies. So the deployer is provided a unified model for pulling, preparing, and releasing data to the relying party.