If You Don't Plan For User Enrollment Now, You'll Hate Federation Later

User enrollment (a.k.a. user activation, user provisioning, account mapping) into a relying party (RP) application is one of those pesky details that is often glossed over in identity federation conversations. But this piece of the last mile integration with the relying party is fundamental to making identity federation work. This blog post describes this critical step and its components.

Enrollment is defined here as the process by which a link is established between the (credential) identifier of a person and the identifier used within an RP to uniquely identify the record of that person. For the rest of this blog post, I am going to use the term Program Identifier (PID) to refer to this RP record identifier [A hat tip to our Canadian colleagues].

Especially when it comes to government services, a question that needs to be asked is if the citizen has an existing relationship with the government agency. If it exists, the Gov RP should have the ability to use some shared private information as a starting point to establish the link between a citizen's (credential) identifier (obtained from the credential verifier) and the PID. e.g. Driver's License Number (DL#) if visiting the Motor Vehicle Administration (MVA) or Social Security Number if visiting the Social Security Administration.

It is important to note that this information is already known to the RP, used only as a claim of identity by the citizen, and providing just this information does not constitute proof of identity. i.e. When I provide my DL# to the MVA, I am saying that "Here is DL# XX-XXXXXXX; I claim that I am the Anil John you have on record as being the owner of that DL#". Before enrollment, the MVA would still need to verify that it is indeed me making this claim using an identity proofing process, and not an identity thief who has obtained my DL#.

So for enrollment to work, the RP needs two sets of data:

1. A shared private piece of data that represents a claim of identity by the citizen
2. A set of information that can be used to prove that claim to the satisfaction of the RP

If the identity verification is successful, the RP can establish a link the between credential identifier (OpenID PPID, SAML NameID, X.509 SubjectDN etc.) and the PID.

In cases where shared private information does not exist between the citizen and the agency, some options to consider are:

1. In-person identity proofing
2. Attestation from a trusted third-party
3. Shared service for enrollment across multiple RPs (Privacy implications would have to be carefully worked through)
4. No linking possible; treat as new record

Are there variations or additions to this step that I have not captured above?

RELATED POSTS

• How to Verify Citizen Identity Easily and Effectively
• Assurance Level Escalation and Government Relying Parties
• How To Collect and Deliver Attributes to a Relying Party for User Enrollment

:- by Anil John