Identity Assurance — Registration Process

4th in a series [ <- previous ] [ <- first ]

Registration is the “process by which a person obtains an identity credential, such as a user name or digital certificate, for subsequent authentication.”  All users of applications supported by an IAM solution must be identified and be registered in order to create an electronic credential.

As I’ve blogged about a few times in the past, the identity proofing that takes place in the Registration Process is critical for sensitive transactions.  In the same way that real-world credentials, such as driver’s licenses, require rigorous registration processes, so too does identity proofing for establishing electronic credentials.

Of course, the strength of the identity proofing process must be in keeping with the overall Identity Assurance required.  For access to a blog or creation of an Instagram or Gmail account, the identity proofing standard can be quite low.  To register for systems that access health or other sensitive information, identity proofing must be much more stringent.

For this reason, the Pan-Canadian assurance model (left-most column) calls for different levels of registration depending on the degree to which an identity needs to be substantiated:

1. Low — Pseudo-anonymous.  Identity is registered with little or no verification of identity.  User supplied information is taken at face value.  If validation is performed, it is cursory.

2. Medium — Identity Validated.  Identity is validated to a moderate level of assurance, and registration is typically performed via an online registration process.  Shared secrets are exchanged to validate the identity during the process.

3. High — Verified Identity.  Identity is verified against information held by an authoritative party.  The process is managed and typically delivered in-person (e.g. a counter service).  A third-party physical credential (e.g. picture ID) may be presented and compared to an organization-held data source.

4. Very High — Corroborated Identity.  Identity is not only verified by an authoritative party via an in-person process, it is corroborated by a trusted third party.  The rigour of this approach provides the highest level of registration possible and is typical of critical process such as passport issuance.

The Pan-Canadian model notes that the identity proofing can be supported by either:

  • evidence supplied by the user (driver’s license, military service card, passport, etc.), or
  • by validating a shared secret that the user supplies and that can be retrieved for comparison from a trusted source (such as a government registry).

In assessing the quality of the identity proofing process, two aspects needs to be considered:

1. The Method of Verification.  In person verification is stronger than online verification; corroborated information is better than information supplied by the user alone; and, identity information verified by multiple sources is better than information that is confirmed by only a single source.

2. The Strength of the Evidence.  Quick — which is more trustworthy: a Canadian passport or a college ID card?   The identity evidence presented by people varies in quality and strength, and the registration process needs to be designed with appropriately strong identity evidence.

In Practice:

I’ve been involved with the design and implementation of dozens of identity proofing and registration processes over the past ten years, and each assignment required a careful review of identity proofing processes. (Note: There are different terms used to describe this functionality of an IAM system, including ‘Identification’ and ‘Enrolment, but for this discussion the general term ‘Registration’ will be used.)

The first step is to determine which of the four Registration levels are required.  If your solution will be enterprise in nature, or it is already known that a large number of applications will be integrated, then it is probably safe to assume that Levels 1, 2 and 3 will all be required.  (Level 4 registration is rare and, in addition, unworkable online).

Next, inventory the potential shared secrets your organization possesses.  What information do you have on file that your clients readily know or can easily look-up?  Account numbers, birth dates and formal names are examples.  It is quite possible that both Levels 1 and 2 can be supported by data you already maintain in enterprise databases.  Some organizations, such as government departments, have numerous shared secrets to choose from.  Others may not know much about the user before the registration process is initiated — in these cases, in-person registration (supported by paper credentials such as driver’s licenses) will likely be required for access to systems containing sensitive information.

Once you have a list of potential shared secrets and paper credentials that could be used, align them with each of Registration Levels 1, 2 and 3.  For example, a client account number might be suitable for Level 1, but on its own it may not work so well for higher levels.  You may find that a combination of good quality shared secrets can help you to achieve Level 2 — the account number plus current mailing address and a recently mailed one time access code might be sufficient.  At Level 3, you will want the assurance of in-person identity verification.  (Click here for a discussion on shared secret quality.)

Finally, for pan-Canadian’s Level 4 the information supplied (in most cases via in-person visit) needs to be corroborated by a trusted party via a separate process.  In practice, this would require verification of the presented identity evidence by a third party.

One way to support Level 3 and 4 regsitration is to first have the individual supply the evidence online.  For example, a physician could provide his college identification number along with his name and date of birth.  Once verified against a trusted data source, the information can be sent to an administrator that works with the physician.  This administrator can confirm the registration event with the physician the next time they meet face-to-face.  Optionally, the administrator could have the physician sign a usage agreement as well.  In effect, this is a corroboration of the registration information, and should satisfy the requirements for a Level 3 or 4 process.

Next: Credential Strength.

Author: code

Mike Waddingham is senior Information Technology management consultant with over 30 years of industry experience. He is the owner of Code Technology Corp.