The trust infrastructure of self-sovereign identity ecosystems.
The trust infrastructure is concerned with the question of how and why the presented information can be trusted. It defines the rules for all stakeholders and enables legally binding relationships with the combination of governance frameworks, which are built on top of trust frameworks.
But before we dive deeper into the part of the trust infrastructure, we need to understand the core components and the different types of identity architecture first.
Core components of identity architecture
There are three core components within an identity system, which in general mainly manage relationships. These are identifiers enabling the means for “remembering, recognizing, and relying on the other parties to the relationship” as explained by Phil Windley. In the case of SSI, these are decentralized Identifiers (DIDs), which are created by a controller, which might be a person, organization or software system. Controllers can use different authentication factors, which according to the Guidance for the application of the level of assurance for eIDAS (CEF DIGITAL), can be possession-based factors (e.g. hardware), knowledge-based factors (e.g. keys or passwords) or inherent factors (e.g. biometrics like a fingerprint). Oftentimes a combination of different authentication factors is used to demonstrate the authority of an identifier.
Phil Windley distinguishes between administrative, algorithmic and autonomic systems, which are illustrated in the image above. We are of course quite familiar with administrative systems such as e-mail, mobile or social network services. Algorithmic systems in contrast leverage some sort of distributed ledger as verified data registry to register a public key / decentralized identifier on a ledger. This gives the controller more sovereignty of the identifier among other perks. However, due to privacy concerns, keys or identifiers of individuals should not be stored on a publicly accessible database. Hence, autonomic identity architecture was developed to enable the “controller to use her private key to authoritatively and non-repudiably [sic] sign statements about the operations on the keys and their binding to the identifier, storing those in an ordered key event log” as Phil Windley states. Current SSI implementations tend to use a combination of algorithmic and autonomic architecture.
Governance frameworks
The Business Dictionary defines governance as the “establishment of policies, and continuous monitoring of their proper implementation, by the members of the governing body.” It includes the mechanisms required to balance powers and defines their primary duties to enhance the prosperity and viability of the organization. The objective for governance entities is to ensure the alignment of involved stakeholders, the definition of the implementation and the processes and use-cases executed on top of it. The purpose of a governance framework is to define the different stakeholders, determine their rights and duties as well as defining the policies under which the network is operated. Therefore, it serves as a legal foundation for the operation of the particular network. It consists of several legal documents, which are published by the governing authority.
The governance of the network (the verifiable data registry also referred to as ledger or trust anchor) itself is only a small part of the total governance required. According to the Trust over IP (ToIP) foundation there are four layers, which require an adapted governance framework matching the needs of the particular layer.
As illustrated in the figure above, the Trust over IP stack is not only separated in layers, but also in technical and governance stacks within the layers. The stack is indented to provide the certainty for higher levels that the underlying ones can be trusted.
Layer one includes the verifiable data registries, which can be implemented on different technology frameworks. The Sovrin Foundation is an example of a governance authority, which published a governance framework for layer one. Other public utilities include IDunion, Indicio and Bedrock among others. While the mentioned networks align their efforts particularly to the ToIP stack there are countless others, which can be used as a public utility as the W3C DID specification registry discloses. These range from generic public permissionless networks such as Ethereum or Bitcoin to networks with permissioned write access, which serve a particular use-case.
Tim Bouma (Senior policy analyst for identity management at the treasury board secretariat of Canada) does not see the need of the government to build and operate a verifiable data registry and highlights the importance of a plurality of operators. However, he points out that the involvement and participation of governments is crucial in defining how the infrastructure is used and relied on as stated in a personal interview.
The second layer describes the communication between agents. Within the ToIP stack, this communication is indented to be executed via a hybrid of an algorithmic and atomic architecture such as peer DIDs or KERI implementations of self-certifying identifiers as described by Ph.D. Samuel M. Smith. This means that publicly resolvable DIDs are used for public entities and private peer DIDs for individuals. The following illustration provided by Lissi provides an overview of these interactions.
However, not all SSI implementations use peer DIDs. For instance, the ESSIF-MVP1 does not currently use peer DIDs but might add them later as deemed appropriate according to the technical specification of DID modelling. Hence, the same type of DID is used for both issuer and holder. The governing authority of layer two is highly dependent on the communication protocols used by the implementation in question. For implementations, which use peer DIDs according to the DIDcomm protocol the governing entity is the DIDcomm working group at the Decentralized Identity Foundation (DIF). Both layer one and layer two define technical or rather cryptographic trust, in contrast to layer three and four, which define human trust.
Layer three protocols support the exchange of data such as verified credentials with different types of signatures, which enable a holder to create verifiable presentations as explained in the ToIP Aries-RFC. It states that one of the goals of the ToIP Foundation is “to standardize all supported credential exchange protocols so that any ToIP-compatible agent, wallet, and secure data store can work with any other agent, wallet, and secure data store.” An issuer can issue any set of claims to any holder, which can then prove them to any verifier. The verifier can decide, which issuers and which claims it trusts.
Layer four of the stack defines the rules for a particular digital trust ecosystem such as healthcare, finance, food products, education etc. These are led by a governance authority, which already exists or is established for this particular purpose. It consists of a variety of different stakeholders such as business entities, government agencies, individuals or other interested parties. These ecosystem frameworks also define the semantics of verified credentials. The semantic of a verified credential defines, which attributes are part of it and their meaning in the particular context. If you want to join an existing ecosystem or want to know more about their work you can find the public ToIP confluence documentary hub here.
Trust frameworks
A trust framework sets the overall legal framework for digital interactions. These trust frameworks are technology agnostic and are uniquely adapted to the jurisdiction they serve. They set the rules for the recognition of electronic identification and authentication and specify the requirements to achieve a certain level of assurance (LoA).
The combination of the different governance frameworks as illustrated in the ToIP stack is sometimes also referred to as trust framework. However, jurisdictions have their own requirements for electronic authentication, which serve as the underlying trust framework. In the case of Europe, the eIDAS regulation clearly defines the requirements for authentication factors to achieve a certain level of assurance. For instance, to achieve the LoA substantial, two factors are necessary. According to the Guidance for the application of the LoA published by the CEF Digital, one out of the two factors needs to be either:
I) a presentation of an identity document or
II) verification of the possession of evidence representing the claimed identity recognized by a member state or
III) a previous procedure executed by the same member state not related to the issuance of electronic identification, which provides the equivalent assurance or
IV) presenting a valid notified electronic identification mean with the LoA substantial or high.
While these requirements can in theory also be defined in a governance framework, the incorporation of such requirements into statutory law facilitates the creation and enforcement of legally binding relationships. Hence, existing statutory law (or case-law depending on the jurisdiction) needs to be incorporated by different governance frameworks to achieve a holistic approach and enforce legal liability.
According to Tim Bouma as one of the main contributor to the Pan Canadian Trust Framework (PCTF) these frameworks intertwine and complement each other as stated in a personal interview. He suggests that policymakers have to go back to the drawing board and take a look at all the concepts to evaluate if they have the right concepts to build out a suitable framework and regulation. The PCTF “is not a ‘standard’ as such, but is, instead, a framework that relates and applies existing standards, policies, guidelines, and practices, and where such standards and policies do not exist, specifies additional criteria. It’s a tool to help assess a digital identity program that puts into effect the relevant legislation, policy, regulation, and agreements between parties.” PCTF V1.1
While the eIDAS regulation itself aims to be technology agnostic there are some aspects, which complicate the adherence of the regulation for SSI implementations. However, this is a topic for its own article. In the eIDAS SSI legal report, Dr. Ignacio Alamillo Domingo describes the potential shift of the eIDAS regulation as trust framework on Page 22 as followed: „Adopting the SSI principles imply, generally speaking, an increased complexity in trust management and a shifting from hierarchical or federated trust assurance frameworks (…) to network-based socio- reputational trust models or accumulative trust assurance frameworks that use quantifiable methods to aggregate trust on claims and digital identities.” Hence, we can already observe the suggestions and considerations to adapt the regulation to suit new innovative solutions.
Key takeaways:
- Governance frameworks and trust frameworks need to be combined to form a holistic approach.
- Governance frameworks of SSI implementations need to respect the requirements and specifications of trust frameworks of the jurisdiction in which use-cases with regulatory obligations are carried out.
- Regulators need to evaluate existing regulations concerning electronic identification and authentication and their suitability with new identity architecture.
- Governments should engage with the public sector to collaboratively explore the requirements for a legally binding trust infrastructure.
Disclaimer: This article does not represent the official view of any entity, which is mentioned in this article or which is affiliated with the author. It solely represents the opinion of the author.
SSI Ambassador
Adrian Doerk
Own your keys
