What is a trust framework?
A trust framework is a set of requirement on a component of an identity system (eg an identity provider or a relying party). The requirements in a trust framework typically cover aspects of subject authentication, operational security, subject identity verification, credential-to-name binding, attribute management, service process and organizational maturity etc.
Trust frameworks tend to be more detailed when crossing jurisdictions or verticals since there are often unstated rules that help to build trust within a jurisdiction or vertical.
For instance, inside the R&E sector trust frameworks are often heavily elided because there is an inherent focus on collaboration in that sector which results in implicit trust.
However when the R&E sector interfaces with the Health sector, considerations of patient safety and security often result in cross-sector trust frameworks that are more detailed due to a need to “spell out the details”.
As trust frameworks are built to cover more jurisdiction and verticals they typically grow in complexity and there is a need to develop and maintain standardized trust frameworks to enable interoperability.
Standard trust frameworks
Over the last few years several industry standard trust frameworks have emerged that try to be independent of jurisdiction. The two most prominent ones are ISO 29115 and the Kantara Identity Assurance Framework (KI-IAF). The former ows much of its genes to the latter which in turn owes genes to NIST SP 800-63. There was also a signifficant amount of influence between ISO 27k and KI-IAF – partly because of a set of shared primary authors.
These 3 frameworks – ISO29115, KI-IAF and NIST SP 800-63 – all rely on the notion of 4 levels of assurance which has become a de-facto standard in the industry ever since. In practice the lowest level (LoA1) is less referenced today because there are no organizations that provide accreditation at this level.
Why are trust frameworks useful?
In an identity system, relying parties (RPs) have to made decisions about weather to trust the assertions of identity providers and attribute authorities. Such decisions are typically made on the basis of knowledge about the operational, technical and policy properties of the identity providers.
The relying party will typicall have a set of business requirements against which the properties of the identity provider is evaluated. For instance the RP may require that the subjects all have been identified to a certain degree of certainty.
As the number of business relationships grow and the number of identity providers grow accordingly the RP is spending more and more resorces evaluating IdPs for compliance with its business requirements.
The trust framework reduces this complexity by relying on standardized trust frameworks.
The role of independent audits
The requirements that make up a trust framework are often intentionally written with a certain amount of leeway to allow for technical innovation. For instance, instead of specifying that (say) subject authentication must be done using a specific technology, a requirement might specify security properties that can be fulfilled by a number of equally acceptable technology alternatives.
Having requirements (or criteria) that are less detailed typically make for trust frameworks that are easy to understand and ready but place a much higher emphasis on the independence of the function that evaluates trust frameworks. To this end it is common to employ specialist auditors that do not have ties to the services under evaluation.
The need for an eIDAS trust framework
The eIDAS directive is based on interoperability of identity systems already deployed in the member states. In many cases the MS has a trust framework that describe the requrements on identity providers approved for use in that jurisdiction. Interoperability for eIDAS implies (as a worst case) that each MS trust framework will have to be evaluated and compared to each other MS trust framework.
Since several trust frameworks in use in the EU (eg the Swedish e-ID trust framework, the UK T-scheme or the Austrian govt federation trust framework) are based on KI-IAF there is already a great deal of commonality already in place.
By creating an eIDAS trust framework as a profile of KI-IAF we achieve the following goals:
1. A set of common requirements based on an industry standard baseline
2. An easy path to interoperability with CA and US (also based on KI-IAF)
3. Reduced complexity for MS-MS interoperability
The Kantara Initiative is working actively on a new version of the IAF where the US Federal Goverment Framework (FICAM ATOS) will be a profile along side the CA goverment profile. It makes a lot of sense for this work to happen in parallell with creating an eIDAS profile.
This is the right time to get this done!