Part 1 of this series discussed the data minimization principles of anonymity, unlinkability and unobservability and their relationship to identity federation. Part 2 of this series walked through a proxy architecture that provides those principles in a federated authentication system. In this blog post, I would like to expand the discussion of the proxy architecture to include user enrollment and see how the data minimization principles are affected by the need for verified attributes.
In the proxy architecture, when a user arrives for the first time at the relying party (RP) after being authenticated by the IdP/CSP, the RP knows:
- A trusted IdP has authenticated the user,
- The Level of Assurance (LOA) of the credential used, and
- The Persistent Anonymous Identifier (PAI) associated with the credential of the authenticated user.
Assumption: As part of the identity proofing and credential issuance process, the IdP/CSP has collected and verified information about the user (which is a requirement for LOA 2+ scenarios).
The RP starts the user enrollment process by collecting both a shared private piece of data (e.g. account #, access code, SSN etc.) that represents a claim of identity and a set of information (e.g. Name, Address, DOB etc.) that can be used to prove that claim from the user. The data elements that are collected by the RP needs to be a subset of those verified and collected by the IdP/CSP as part of the identity proofing and credential issuance process.
The RP then initiates the attribute verification process:
- The request is made via the proxy to maintain the PAI to PPID mapping and the PPID to CID mapping
- The request is for a MATCH/NOMATCH answer and NOT a "Give me all the attributes you have collected during identity proofing"
- The shared private data (e.g. Account #, Access Code, SSN etc.), which is ALREADY in the RP system, is NOT sent to the IdP/CSP
If the response that comes back from the IdP/CSP is positive, the RP:
- Uses the shared private piece of data to pull up the associated user record
- Checks to see if the verified attributes returned match those in the user record
- If they match, the RP links the PAI to the associated user record locator a.k.a. Program Identifier (PID)
Critical points to note here are that the IdP still does not know which RP the user went to, the RP still does not know which IdP the user is coming from, but the Proxy now has visibility into the attributes flowing through it. As such, it is critical to make sure that a security policy backed by an independent audit and verification regime is put in place to assure that the proxy does not collect, store or log the attribute values flowing through it.
We would be interested to hear about how this architecture can be improved or modified to enhance its privacy characteristics.
RELATED POSTS
- How to Verify Citizen Identity Easily and Effectively
- If You Don't Plan For User Enrollment Now, You'll Hate Federation Later
- Challenges in Operationalizing Privacy in Identity Federations
- Challenges in Operationalizing Privacy in Identity Federations - Part 2
- How To Implement the Technical Aspects of an Identity Oracle
- Nat Sakimura: Privacy Enhancement for Open Federated Identity/Access Management Platforms (PEOFIAMP) R&D Project
:- by Anil John
