Document status: Working draft
Author: Rainer Hörbe
Date: 23. March 2011
Abstract
Common Assurance Frameworks for Identity Federations provide a metric the strength of the authentication process and the underlying identification of the user. This metric is called LoA assurance level (AL). However, to provide a comprehensive metric for all protection requirements this metric needs to be extended.
Context of LoA
1. Entity Authentication Assurance vs. Trusted Path: Sign-on vs. Session
The common Level of Assurance metric was conceived for (like in NIST SP 800-63, Kantara IAF or IDABC/STORK QAA levels) defines the Entity Authentication Assurance for remote authentication. It descended from a specific legal, technical and business context and does not fulfill the requirements for a comprehensive identity assurance metric. The requirements for a more complete metric are to communication the assurance level in public and private sectors, PKI and non-PKI technologies, and serve providers and users.
When communicating policies between an assuring and a relying actor there is a conflict of goals between simplicity and a high degree of detail that provides control. A simple scale like 4 levels means to mix apples and pears, but is easy to use in a large scale. An elaborate policy provides insight for the expert, but is too complex for most parties.
So there are 2 problems to solve:
- What qualities does the assurance between actors in a trust relationship encompass?
- How to communicate a policy that assures these qualities - a simple number or more complex data?
Re 1.) Assurance scope
The qualities that need to be assured are information security and privacy, according to the scope of the TFMM. The Relying Party perspective is usually depicted with the LoA. The following picture shows LoA and an alternative reason is, that LoA is focused on the quality of the identity of a remote user to be communicated to the Relying Party by an Identity Provider, implying a backing trust relationship between IdP and Subscriber/User. In contrast, a trusted path from the user to an application has to last for the duration for a session.
2. Authentication vs. CIA + Privacy
However, trust relationships between parties in electronic communication require a comprehensive set of information security and privacy protection requirements. LoA restricted to entity authentication assurance (such as the upcoming ISO/IEC 29115) need to be put into a wider picture. The requirements for a more complete metric are like:
- provide confidentiality, integrity and availabiltiy of the communication and comply to privacy requirements;
- assure both identity and attributes;
- regard the protection requirements of all parties related to the transaction, that would include PII of third parties not part of the transaction and protection requirements of end-users, organizations that the user is affiliated with and trust service providers;
- beyond the session: regulate further processing and storage of data including hard copies, log and audit files.
Enhanced LoA based on credential life and usage cycles
The following picture shows the common LoA and an enhanced model based on credential life and usage cycles. It segregates and adds components of/to the LoA, but does not imply to communicate all these to the Relying Party. It is still possible to funnel each single metric into a common scale.
Level of Identity Assurance pertains to the quality of the identity verification and proofing process and artifacts.
Level of Credential Binding is driven by the process that binds the identity determined in the registration process to the electronic credential.
Level of Authentication Assurance is composed of the strength of the credential, authentication protocol, and related device and human security factors.
Level of Attribute Assurance depends on the standing of authoritative source, vetting process and technical security of the attribute assertion.
Level of Security Context Assurance: This is mostly a duty of the relying party, but there are a few client-side vulnerabilities that need to be protected.
Level of Authorization Assurance is a special case of an attribute assertion that requires specific management processes as periodic reviews, 4-eye principles etc. (Not sure if needed separate from attribute assertion)
In case of some attributes (like age verification or professional role) it might not make sense to mix attribute assurance with identity assurance, the other factors might be condensed into a single factor, just with a wider scope as the traditional LoA. (Need to be discussed)