Anil John
Making Digital Services Secure and Trustworthy

Anil John

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

 Tweet  Share  Comment  Print  Email

User enrollment (a.k.a. user activation, first time user provisioning, first time account mapping) into a Relying Party (RP) application is the critical first step in making identity federation work. I’ve found this particular topic to be one that is ripe for confusion and conflation driven by the needs and motivations of both RPs and Credential Service Providers (CSP). This blog post provides some thoughts and perspectives on this critical process within the context of public sector services that require higher assurances of identity.

The RP needs a certain set of information in order to do this but often gloms together information needed for identity resolution with information needed for internal business processes. In addition, depending on whether or not the RP is utilizing the services of a [separate Token Manager and Identity Manager and binding the Token to the Identity themselves][1] or [utilizing the services of a Credential Manager that has performed the Token-Identity binding][2] brings a further level of potential confusion.

On the CSP or Identity Manager side, there is a set of information that is obtained about a person during the identity proofing process. In part, driven by the varying nature of what is asked for by the RP and in part driven by the ability to charge each RP for being a “special snow-flake”, and in the absence of standardization around what the RP is asking for, the conversation in this particular area is also ripe for introducing confusion.

So, let us start out with some assumptions about this federation scenario:

  1. We are dealing with public sector RP that has an existing relationship (off-line, but potentially online) with a person. i.e. The RP Application/Program has an existing record for the person and it can pull up the record using a unique key which we will call a Program Identifier (PID). Think of the PID as the primary key for a record in a database.
  2. The RP has done a risk analysis and determined that it requires Level 2 credentials, and that it will accept externally issued (federated) Level 2 credentials
  3. We are dealing with a Credential Service Provider offering Assurance Level 2 credentials i.e. A Credential Manager offering a CSP service who has identity proofed a person per Level 2 requirements, bound the attributes to a Level 2 (or greater) Token using secure processes, and is offering both a credential verification service and an attribute service.
  4. What the CSP brings to the front door of the RP, after verification, is (a) a Credential Identifier (CID) that uniquely identifies the credential and (b) a set of verified attributes about the person associated with the credential. How the verification takes place and how the attributes are moved (protocols etc.), whether directly between the CSP and the RP or via a Broker/Proxy is irrelevant to this particular discussion.

The steps, for user enrollment to be successful, are as follows:

  • Out of band, the RP and the CSP must agree on the verified attribute bundle that the CSP will send to the RP for identity resolution

My recommendation here would be to leverage the work that has been done by the ANSI/NASPO Identity Proofing and Verification (IDPV) Standard Development Project and [utilize one of the five attribute bundles they identified; Majority of which provide greater than 95% identity resolution for the U.S. Population][3].

  • Out of band, RP should evaluate the existing record of a person in its system and choose a locally unique shared piece of information (between it and the person) it can use to prompt the person

This information could be a personal access code that is printed on a paper based benefits mailer sent to the person, an existing account number, or if it already exists in the RP system, the Social Security Number. The key to note is that this information does not constitute proof of identity but simply allows the RP to use it to find a matching record in its data store i.e. It is a locally unique shared identifier (LUSID).

  • Use the shared piece of information to retrieve the existing record and cross-check the verified attributes provided by the CSP against what is found in the record

If the information matches, you are assured (up to Level 2) that the person who showed up at the front door of the RP is the person whose record the RP has retrieved. The RP, of course, retains the option of putting in additional compensating controls based on its risk profile.

  • Map the Credential Identifier (CID) provided by the CSP to the Program Identifier (PID) of the record that was retrieved

This is a one time event and is the crux of the user enrollment piece. The PID and LUSID may or may not be the same and if you have a choice, it should be different. The next time the same CID shows up at the RP, the RP simply looks at the mapping to identify the associated record and allows access to that account.

BTW, if the person already had an online account at the RP, this process can be further simplified provided the assurance levels of the existing account (e.g. userid/password) and the federated credential are comparable.

  • Person arrives at front door of the RP with a CID
  • RP prompts person to log in using existing credentials
  • RP maps the PID of the account accessed to the CID of the federated credential
  • RP disables userid/password access

Are there other ways of doing this? What are some of the things to watch out for if you are going down this path? Lessons learned from implementers would be very welcome.


  • [A Model for Separating Token and Attribute Manager Functions][1]
  • [Credential Manager in the Token and Attribute Manager Separation Model][2]
  • [HOW TO Choose Attributes to Uniquely Identify a Person][3]
  • [IDMGOV Info: If You Don’t Plan For User Enrollment Now, You’ll Hate Federation Later][4]
  • [IDMGOV Info: How To Collect and Deliver Attributes to a Relying Party for User Enrollment][5]
  • [Here Be Dragons - Social Security Number and Federation User Enrollment][6]
  • [How To Enroll a User, Even When There are No Shared Identifiers][7]
  • [User Enrollment Challenges with PKI Credentials][8]

[1]: “A Model for Separating Token and Attribute Manager Functions”[1] [2]: “Credential Manager in the Token and Attribute Manager Separation Model” [3]: “HOW TO Choose Attributes to Uniquely Identify a Person” [4]: “IDMGOV Info: If You Don’t Plan For User Enrollment Now, You’ll Hate Federation Later” [5]: “IDMGOV Info: How To Collect and Deliver Attributes to a Relying Party for User Enrollment” [6]: “Here Be Dragons - Social Security Number and Federation User Enrollment” [7]: “How To Enroll a User, Even When There are No Shared Identifiers” [8]: “User Enrollment Challenges with PKI Credentials”

Did you find this interesting? Don't miss any new posts. Sign up to automatically receive them now!

I will never share, rent, or sell your information to anyone. Cancel anytime.

This blog post first appeared on Anil John | Blog ( The opinions expressed here are my own and do not represent my employer’s view in any way.

By on |

Continue The Conversation ...

I would love to know your thoughts on this blog post. Please leave a comment below!

I am a Public Interest Technologist. I help technical leaders make digital services secure and trustworthy. Learn more »

Free Updates

I will never share, rent, or sell your information to anyone