Challenges in Operationalizing Privacy in Identity Federations - Part 2

Federation implementations enabling privacy enhancing characteristics such as anonymity, unlinkability and unobservability are something that we are very interested in for Government service delivery. This blog post describes one such approach using a proxy mechanism between the identity provider and the relying party and articulates some of the trade-off's inherent in such an approach.

The typical identity federation scenario with an externalized Identity/Credential Provider and a Relying Party looks something like this:
Brokered AuthN

  • User's credential identifier (CID) is not released to RP. FICAM Identity Schemes require a Pairwise Pseudonymous Identifier (PPID) to limit the loss of anonymity and unlinkability; IdP keeps track of that mapping internally
  • The Program Identifier (PID) is a user record identifier that only the RP know about, and the RP establishes the one-time PPID to PID mapping via the user enrollment process
  • The IdP knows about the RP the user is interacting with so there is no mitigation for the loss of unobservability

If implementing this using SAML 2.0, this would be the classic SAML Web SSO Sequence Diagram with a persistent identifier for NameID:

Brokered AuthN SAML

One approach that would bring additional privacy enhancing characteristics into this mix is the implementation of a Proxy between the Identity Provider and the Relying Party:

Privacy Proxy

  • CID to PPID mapping is the same as before. Limits loss of anonymity and unlinkability
  • When a PPID comes into the proxy, it generates an associated Persistent Anonymous Identifier (PAI) which is then released to the RP. The proxy manages the persistent PPID to PAI mapping. 
  • Limits loss of unobservability, since IdP has no visibility into which RP the user has gone to or the identifier that they are using at that RP 
  • RP know that a trusted IdP authenticated the user and the associated LOA level but nothing more
  • RP manages the PAI to PID mapping
  • The proxy knows of the IdP and the RP but knows nothing other than the PPID and the PAI
  • Forensics requires coordination across IdP, Proxy and RP

As an aside, I would like to acknowledge our colleagues at TBS Canada for how they defined PAI and PID (PDF); I saw no value in coming up another term to describe the same items, so decided to simply leverage their definitions.

If implementing this in SAML 2.0, the sequence diagram with the proxy taking on both IdP and RP roles as needed would look like:

Privacy Proxy SAML

This architecture works brilliantly as a privacy enhanced credential mediation service and it can very easily be implemented using current technical protocols. But it does require the responsibility for identity proofing (before enrollment) to rest with the RP. So some questions that need to be explored are:

Any insights and lessons learned on working with this type of architecture would be appreciated.


:- by Anil John