Identity Assurance, An Everyday Life Issue (Part 1)
In this 2-part article, I hope to explain the importance of identity assurance in everyday life. I will first level set on terms and definitions in part 1, and then illustrate with real-life examples in part 2.
The notion of identity assurance is to establish, with a level of certainty, that the human being represented by a credential in an electronic transaction is in fact the alleged person. Whether you realize it or not, whenever you perform an electronic transaction, you are making some kind identity assurance tradeoff.
Identity assurance does not only apply to scenarios in the extranet in which consumers or users from one organization interact with systems in another. It also applies within the enterprise where you need to view identity lifecycle management holistically, as opposed to fragmented steps, such as provisioning, authentication, single sign-on, etc.; and how they contribute to creating and maintaining identity assurance.
My Personal History
In late 2006, I was first introduced to the issue of identity assurance as a trend in identity management. It all started with the FFIEC's October 2005 guidance on Authentication in an Internet Banking Environment. It appeared on my radar as I was strategizing on the future of web access management and the product portfolio for which I was responsible. I was also wrestling with transaction assurance and access management 2.0. At the time I did not realize the profound impact that this concept would have on my career.
In late 2007, as I was managing a high-assurance digital identity service offering at a large global bank, I was introduced to Liberty Alliance Identity Assurance Expert Group. I joined the group as a co-chair which led to my current role as Chair of Kantara Initiative's Identity Assurance Work Group that is responsible for the Identity Assurance Framework. It works closely with the Kantara Initiative Identity Assurance Certification Program, which actually instantiates the framework in an actual program. So, I guess you can say I have become an identity assurance activist.
It's All About Risk
In any electronic transaction where a human is represented, an implicit identity assurance tradeoff is made. A human may be represented in a transaction by providing a user name, email address, or simply by checking off a box accepting certain terms and conditions. The question is whether we are aware of or comfortable with the tradeoff. In all instances, you and the party with whom you are transacting are agreeing that your identity can be representing in this way for this transaction, and accept the consequences of what might happen if something goes wrong (i.e. your credentials are spoofed or compromised, or you chose to share your credentials with somebody that acts on your behalf and does something wrong).
The higher the sensitivity of the transaction, the higher the confidence (i.e. assurance level) you would like to have. Therefore, an identity assurance level (AL) should map to the risk level in any given transaction.
All identity assurance documentation that I have read or been involved with converge on four basic levels of assurance:
- Level 1: Little or no confidence
- Level 2: Some confidence
- Level 3: High confidence
- Level 4: Very high confidence
OMB Memorandum M-04-04 illustrates this rationale from the perspective of the US Government. It effectively explains the application of identity assurance to transactions, considering the impact of something going wrong, and also the expected frequency of its occurrence. Below is a table I borrowed from this document that focuses on authentication.
Advice: Be aware of the sensitivity of a transaction. Think through the mechanism employed to mitigate risk and if it is sufficient enough to convey the appropriate level of confidence. Consider the intersection of identity assurance with your data and risk classification.
It's Not Just About Authentication
Another important realization, particuarly for me given my background as a product manager, was that identity assurance is not just how strongly you authenticate someone. A number of factors come into play. Moreover, identity assurance, like other facets of identity and access management (IAM), is a lifecycle process. An identity lifecycle includes stages ranging from registration (initial creation, identity verification, credentialing) to contextual access control (authentication, risk and activity monitoring, stronger authentication), renewal and termination.
An IAM solution must account for the fact that identity assurance decays over time and that lifecycle processes, such as renewal or termination, are necessary to either preserve the assurance level or eliminate the risk of a compromised identity.
Even though this concept may seem obvious, traditional IAM deployments do not incorporate identity assurance as a guideline, and thus rely on a static notion of identity.
This approach towards risk and identity assurance allows end users and organizations to gain trust in relying on online channels to conduct sensitive and higher-value transactions.
In my next blog post, I plan to illustrate these concepts with some real-life examples. In the meantime, I look forward to your comments.