!!! Overview 
SAML V2.0 introduces a number of new features including:

!!Pseudonyms
SAML V2.0 defines how an opaque pseudo-random identifier with no discernible correspondence with meaningful identifiers (for example, emails or account names) can be used between providers to represent principals. Pseudonyms are a key privacy-enabling technology because they inhibit collusion between multiple providers (as would be possible with a global identifier such as an email address)

!!Identifier management
SAML V2.0 defines how two providers can establish and subsequently manage the pseudonym(s) for the principals for whom they are operating.

!!Metadata
The metadata specification defines how to express configuration and trust-related data to make deployment of SAML systems easier. In doing this, it identifies the actors
involved in the various profiles, such as SSO Identity Provider and Service Provider, and Attribute Authority and Requester. The data that must be agreed on between system entities includes supported roles, identifiers, supported profiles, URLs, certificates and keys.

!! [Encryption]
[{$pagename}] permits attribute statements, name identifiers, or entire assertions to be encrypted. This feature ensures that end to-end [confidentiality] of these elements may be supported as needed.

!! Attribute Profiles
Attribute profiles simplify the configuration and deployment of systems that exchange attribute data. The attribute profiles include:

!Basic attribute profile
Basic attribute profile supports string attribute names and attribute values drawn from XML schema primitive type definitions.

!X.500/LDAP attribute profile
X.500/LDAP attribute profile supports canonical X.500/LDAP attribute names and values.

!UUID Attribute Profile
UUID Attribute Profile supports the use of UUIDs as attribute names.

! [XACML] Attribute Profile
[XACML] Attribute Profile supports formats suitable for processing by [XACML].

! Session management
Session management provides the [Single Logout Profile] in [{$pagename}] provides a [protocol] by which all sessions provided by a particular [session] authority can be near-simultaneously terminated. 

As an [example], if a principal, after authenticating at an [Identity Provider (IDP)], achieved [Single Sign-On] to multiple [Service Providers], they could be automatically [Logging Out] of all of those [Service Providers] at the request of the [Identity Provider (IDP)].

!! Devices
[{$pagename}] introduces new support for the mobile world – addressing both the challenges introduced by device and bandwidth constraints and the opportunities made possible
by emerging smart or active devices.

!! Privacy Mechanisms 
[{$pagename}] includes mechanisms that allow providers to communicate privacy policy and settings. For instance, SAML makes it possible to obtain and express a principal's consent to some operation being performed.

!! [{$pagename}] [Identity Provider (IDP)] [Discovery Mechanism]
In deployments having more than one identity provider, service providers need a [Discovery Mechanism] which [Identity Provider (IDP)](s) a principal uses. 

SAML v2 IDP Discovery Service relies on a [cookie] written in a [DNS Domain] that is common to all [Identity Provider (IDP)] and [Service Providers] in a [Circle of Trust]. This predetermined [DNS Domain] is known as the common domain, and the [cookie] containing the list of [Identity Provider (IDP)] to chose from is known as the common domain [cookie].

When a user requests access from a [Service Provider] and an entity identifier for an [Identity Provider (IDP)] is not received in the request, the service provider redirects the request to the common domain's SAML v2 IDP Discovery Service Reader URL to retrieve the identity provider's entity identifier. If more than one [Identity Provider (IDP)] entity identifier is returned, the last entity identifier in the list is the one to which the request is redirected

!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]