Identity verification of citizens is critical to delivering high value government services online. Differing approaches to identity verification include front-end identification, which fits well with existing Government trust models, and back-end identification, based on widely deployed commercial practices. This blog post describes these two common models and the approach and trade-offs associated with each.
One of the reasons for trying to articulate this is that I have found myself recently in multiple settings discussing protocol flows and privacy preserving crypto. But at the end of the discussion, I often feel as though we have not asked ourselves some foundational questions regarding choices made in identity proofing and credential issuance. This in turn has resulted in a lack of clarity around the downstream impact of those choices on privacy, security and flexibility. So here goes...
The Front-End Identification is the same as the E-Authentication model that is found in
NIST SP-800-63-1 (PDF). It follows the sequence of:
- Person Registration/Identification
- Binding of Identity and Token
- Credential Registration/Issuance
- Person Enrollment at Relying Party
| Approach | Trade-Offs |
|---|
- Identity proofing is done up front by a credential provider with registration function or using a separate registration authority
- Credential incorporates assurances of identity
- User enrollment at RP based on information available from the identity proofing process and/or other sources [Enrollment is defined here as the creation of an association between the person's identifier and the index for the person within the RP application]
|
- Ability to leverage results of identity proofing across multiple relying parties
- RPs limited to approved credentials that meet assurance criteria
- May be harder to utilize a higher LOA credential in transactions that support anonymity and pseudonymity without "beautiful math" or other proxy mechanisms
|
The Back-End Identification is the E-Authentication model that is found widely deployed in the commercial space. It follows the sequence of:
- Credential Registration/Issuance
- Person Registration/Identification
- Binding of Identity and Token at Relying Party
- Person Enrollment at Relying Party
| Approach | Trade-Offs |
|---|
- Credential is often little more than a token (i.e. shared secret) and may have little to no assurances of identity
- Identity proofing done directly by the RP or by using a separate proofing capability to the level required by policy
- User enrollment at RP based on information available from the identity proofing process and/or other sources [Enrollment is defined here as the creation of an association between the person's identifier and the index for the person within the RP application]
|
- Any token and/or combination of tokens can be used depending on the “technical strength” needed
- Proofing process can be as stringent as need be, so the information in credential can be as anonymous or revealing as need be
- Inability to leverage identity proofing across multiple RPs
|
Have I accurately captured the two major approaches in play right now? Are there trade-offs that you can think of that should be added to the lists above?
UPDATED: 12/1/2012 with clarifying text and pictures re: where the token-identity binding takes place
RELATED POSTS
:- by Anil John
