Why Are SAML Persistent Identifiers Used as a 'Privacy Protection Mechanism'?

Question

Section 8.3.7 of the SAML Core Specification states that the persistent nameID format is used for privacy protection:

Persistent identifiers are intended as a privacy protection mechanism; as such they MUST NOT be shared in clear text with providers other than the providers that have established the shared identifier. Furthermore, they MUST NOT appear in log files or similar locations without appropriate controls and protections.

I'm not certain that I understand the intent behind the use of persistent identifiers as a privacy protection mechanism - particularly in light of the fact that most of the other NameID types (email, SN, qualified name, kerb principal, etc.) will be the same across all SP's.

How is the unique NameID per-SP a 'privacy protection mechanism'? Specifically, what attack vectors would be mitigated by the use of a persistent NameID field over another type (particularly when protections like correct audience restrictions and signatures are in place)?

Answer 1

It is a privacy protection mechanism because it doesn't transfer your real identifier from the IdP to the SP. Meanwhile, the Email NameID type, for example, transfers your email from the IdP to the SP.

One online resource that I can find which explains this pretty good is http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0.html section 5.4.3 Federation Using Persistent Pseudonym Identifiers.

The processing is as follows:

1. The user attempts to access a resource on cars.example.co.uk. The user does not have any current logon session (i.e. security context) on this site, and is unknown to it. The resource that the user attempted to access is saved as RelayState information.

2. The service provider uses the HTTP Redirect Binding to send the user to the Single Sign-On Service at the identity provider (airline.example.com). The HTTP redirect includes a SAML message requesting that the identity provider provide an assertion using a persistent name identifier for the user. As the service provider desires the IdP have the flexibility to generate a new identifiier for the user should one not already exist, the SP sets the AllowCreate attribute on the NameIDPolicy element to 'true”.

3. The user will be challenged to provide valid credentials.
4. The user provides valid credentials identifying himself as john and a local security context is created for the user at the IdP.
5. The Single Sign-On Service looks up user john in its identity store and, seeing that the AllowCreate attribute allows it to, creates a persistent name identifier (61611) to be used for the session at the service provider. It then builds a signed SAML web SSO assertion where the subject uses a transient name identifier format. The name john is not contained anywhere in the assertion. Note that depending on the partner agreements, the assertion might also contain an attribute statement describing identity attributes about the user (e.g. their membership level).
6. The browser, due either to a user action or execution of an “auto-submit” script, issues an HTTP POST request to send the form to the service provider's Assertion Consumer Service.
7. The cars.example.co.uk service provider's Assertion Consumer service validates the digital signature on the SAML Response and validates the SAML assertion. The supplied name identifier is then used to determine whether a previous federation has been established. If a previous federation has been established (because the name identifier maps to a local account) then go to step 9. If no federation exists for the persistent identifier in the assertion, then the SP needs to determine the local identity to which it should be assigned. The user will be challenged to provide local credentials at the SP. Optionally the user might first be asked whether he would like to federate the two accounts.
8. The user provides valid credentials and identifies his account at the SP as jdoe. The persistent name identifier is then stored and registered with the jdoe account along with the name of the identity provider that created the name identifier.
9. A local logon session is created for user jdoe and an access check is then made to establish whether the user jdoe has the correct authorization to access the desired resource at the cars.example.co.uk web site (the resource URL was retrieved from state information identified by the RelayState information. If the access check passes, the desired resource is returned to the browser.

I do think there is a typo at step 5 though. It should be "use persistent name identifier format" instead of "use transient name identifier format".