Trust Model
A trust model defines how entities in a system establish, manage, and verify trust relationships. It outlines the mechanisms and protocols used for authentication, authorisation, and confidentiality to ensure secure interactions. Effective trust models are crucial for ensuring security and reliability in various applications, from financial transactions to digital communications.
SSI Trust Model
The SSI trust model emphasizes decentralised identity management, where individuals have control over their own identity data. In this model, identity holders (individuals or entities) manage their identities using digital wallets. These identities are verified by issuers, who provide verifiable credentials [1] that can be presented to verifiers when needed. The process is underpinned by cryptographic proofs, ensuring security and privacy.
Before a presented credential can be verified, it is essential for the verifier to gain an understanding of the issuer and determine whether they can be trusted. Additionally, the verifier must retrieve the issuer's public key to verify the authenticity of signed credentials. Furthermore, a means for checking the revocation status of a credential is required.
Decentralized Identifier (DID)
Decentralized Identifiers (DIDs) enable verifiable, self-sovereign digital identities. Unlike traditional identifiers, DIDs are not tied to centralized registries or authorities but are instead created, owned, and managed by individuals or entities themselves. Each DID is associated with a DID Document that contains public keys, service endpoints, and other metadata needed for interactions. DIDs can be used across various platforms and services, fostering interoperability and user autonomy in the digital identity landscape.
DID methods define the specific rules and protocols for creating, resolving, and managing DIDs.
Each DID method provides a standardized approach for how DIDs are generated and used within its framework, ensuring interoperability and functionality across different systems.
For example, the DID:key method allows for the creation of DIDs directly from cryptographic key pairs without relying on a blockchain or centralized registry.
This method provides a simple, lightweight way to generate DIDs that are solely derived from and resolved using the associated public key.
Further, the DID:web method enables the creation of DIDs that are linked to web domains by hosting DID documents on standard HTTPS servers.
This method leverages existing web infrastructure, allowing entities to use their domain names to manage and resolve DIDs, facilitating easier adoption and integration with web-based services.
Trust Lists and Verifiable Data Registries
In order to establish initial trust between a verifier and an issuer, it may be beneficial for the issuer to be anchored using their DIDs in shared trust lists. In accordance with the ARF, EU member states may administer such trust lists, announcing updates to the European Commission. Alternatively, issuers may be onboarded in a decentralised manner through collective management and sharing of a Verifiable Data Registry (VDR), potentially utilising blockchain technologies. VDRs may encompass trust lists and revocation status lists, thereby establishing initial trust and enabling verifiers to ascertain the revocation status of a presented credential in a privacy-preserving manner.
An example of a decentralised VDR is the European Blockchain Services Infrastructure (EBSI), which is based on a decentralised ledger designed to support the issuance and verification of verifiable credentials across Europe. It uses blockchain technology to provide a secure, tamper-proof environment for managing digital identities and credentials. The EBSI project aims to facilitate an interoperable framework for the management of digital identities and credentials within the EU. In the future, EBSI could be used to support cross-border identification as promoted by the ARF. However, there is no integration at the time of writing.
As building a trust model is a collective endeavour, it cannot be bootstrapped in a standalone manner. Therefore, this project follows a static approach, where trusted identifiers are manually inserted into the agent implementation. In addition, revocation status lists are shared directly by the issuer via a web endpoint. In future implementations, a trust list provided by the European Commission or a VDR may be used. In the following, we refer to trust lists in general, as the implementation is independent of the adapted form.
The ARF mandates the issuance of Trust Evidence (WTE) and Wallet Instance Attestation (WIA) by Wallet Providers. As the ARF deals with the identification of natural persons, the legal role and responsibilities of enterprise wallet providers remain undefined. It seems unlikely that comparable requirements will be established, given the existence of different prerequisites. Therefore, it is not intended to issue WTE and WIA in the context of the Enterprise Wallet.
Revocation
Verifiers must ensure that credentials have not been revoked during verification. In the SSI model, issuers should not be able to deduce to whom credentials have been presented by holders. Therefore, a privacy-preserving revocation mechanism is required. The Bitstring Status List [2] uses a sequence of bits to represent the status of credentials. Each bit corresponds to a specific credential, with '0' indicating a valid credential and '1' indicating a revoked one. This method is efficient because the bitstring remains compact even for large numbers of credentials, making it suitable for environments with limited storage and bandwidth. Privacy is maintained as the bitstring does not reveal specific details about individual credentials beyond their status. Verifiers can quickly check a credential's status by looking up the relevant bit, ensuring rapid and efficient verification. The bitstring can be updated regularly and protected using cryptographic techniques to ensure integrity and trustworthiness.
Trust Relationships
In this section we describe the trust that different actors have in other actors and how they provide trust.
Bundesanzeiger
The Bundesanzeiger acts mainly in the role of an issuer and provides verifiable credentials. To enable verifiers to establish a trust relationship with the Bundesanzeiger, the Bundesanzeiger can register as a trusted issuer with an EU member state or the VDR. Alternatively, the Bundesanzeiger's DID can be manually added to a verifier's local trust list.
Before verifiable credentials can be issued by the Bundesanzeiger, applicants must be authenticated. In this process, the Bundesanzeiger acts as a verifier as the PID is presented by the applicant in the form of a verifiable credential. In order to verify the presented credential, the Bundesanzeiger utilizes the encoded issuer DID to resolve the DID document and check whether the issuer is part of an approved trust list. Since the DID document contains the issuer's public key, the signed credential can be verified. In addition, the revocation status can be verified by using a VDR or any other means provided by the issuer.
Enterprise
Enterprises benefit from the trust that comes from verifiable credentials. For example, an Enterprise Credential issued by the Bundesanzeiger can be presented to business partners such as banks to prove certain claims. As a result, a bank derives a trust relationship with the company from the trust relationship with the issuer. The enterprise DID that is encoded into the credential permits the implementation of automated process where business partners need to verify claims of an enterprise to perform actions autonomously. In addition, the natural person credentials issued by the Bundesanzeiger can be used to authenticate functionaries with business partners and the presentation of the Enterprise Credential enables natural persons to provide authorisation if required. Since functionaries have registered their DID at Bundesanzeiger and authenticated themselves in this process, the Enterprise Credential also includes the functionaries' DIDs. Due to this binding, functionaries can present the Enterprise Credential to verifiers using the key material linked to their DID. As a result, the functionary can be authenticated by a verifier and authorization for certain actions can be checked according to the role specified in the Enterprise Credential.
Bank
Banks are required to carry out a KYC process and monitor customer data to ensure compliance with AML regulations. In the SSI model, all required data is provided by the applicant in the form of verifiable credentials. In order to verify the presented credentials, the bank requires a trust relationship with the issuer of each credential. Such trust relationships can be established via a trust list or a trust chain, as described in the Power of Attorney section.
Figure 1: Proof verification enables trust chains with a root of trust derived from a trust list.
The root of trust is derived from the trust list, which includes the DID of the Bundesanzeiger. When a functionary submits a verifiable presentation to a bank, the presenter's authentication proof is verified to ensure the authenticity of the presentation. In the example given, Functionary A presents a Natural Personal Credential for authentication and an Enterprise Credential to prove personal characteristics such as name and date of birth. In addition, the Enterprise Credential is presented, which includes a reference to Functionary A's DID, indicating the specific role. This allows the bank to verify that the applicant is authorised to act on behalf of the company in the role specified. Both credentials are signed by the Bundesanzeiger. Therefore, the included credentials can be verified by the bank and are trusted. Accordingly, the bank can perform the entire KYC process on the basis of the verifiable credentials submitted by the functionary due to the trust relationship with the Bundesanzeiger.
Power of Attorney
In many cases, functionaries authorise employees to act on their behalf. For this purpose, functionaries may issue powers of attorney to employees. This puts the functionary in the role of issuer. Since there is typically no direct trust relationship between functionaries and verifiers, a trust chain is introduced to establish the required trust relationship. Signatory rights are expressed by the functionary's role presented in the Enterprise Credential. When issuing the Power of Attorney Credential, the functionary creates a presentation of the Enterprise Credential and selectively discloses the functionary role. Therefore, only the role granting particular rights is revealed to verifiers. As a result, verifiers can validate the trust chain from the authorised employee to the trusted issuer, in this case the Bundesanzeiger.
Figure 2: Trust can be established through a trust chain from a root of trust to the credential subject.
Figure 2 illustrates the trust chain from a bank, acting as a verifier, towards an issuer in the form of the Bundesanzeiger. A trust relationship from the bank to the Bundesanzeiger is established through a trust list that includes the Bundesanzeiger's DID and is utilized by the bank. In this example, Employee B interacts with the Bank and is requested to authenticate, prove authorisation in terms of functionary rights and present certain attributes about the enterprise such as ultimate beneficial owners (UBOs). For this purpose, Employee B creates a verifiable presentation including a Power of Attorney Credential and an Enterprise Credential.
The bank first verifies the presentation's authentication proof to ensure it was created by Employee B. While Employee B is not listed as a functionary in the Enterprise Credential, power of attorney was granted by Functionary A, who is listed as a functionary in the Enterprise Credential. To verify this chain of trust, the bank verifies the Power of Attorney Credential's assertion proof that was issued by Functionary A. At this point, there is no trust relationship from the bank to Functionary A. Therefore, the Power of Attorney Credential includes a presentation of the Enterprise Credential that was issued the Bundesanzeiger. Note that this presentation includes only the selectively disclosed attribute necessary for proving authorisation. In this case, the functionary field is disclosed by the issuing functionary. Since a trust relationship exists from bank to the Bundesanzeiger, the verification of the Enterprise Credential creates a trust relationship to Functionary A whose DID is included in the Enterprise Credential acts as an issuer providing power of attorney to Employee B.
In addition, Employee B uses selective disclosure to provide the data that was requested by the bank in the verifiable presentation. Note that this is presentation of the Enterprise Credential is in addition to the the presentation in the PoA Credential as it serves a different purpose. Yet, the enterprise is identifiable and the information can be linked, as the enterprise DID is included in the credential subject. Since the Enterprise Credential is generated by the Bundesanzeiger which is trusted by the bank, the respective assertion proof can be verified and the credential's authenticity is trusted by the bank.
Figure 3: Trust chains enable establishing trust including multiple intermediaries.
While Figure 2 shows an example where a single intermediary is included in the trust chain, multiple credentials may be included if an extended trust chain is required. Figure 3 illustrates a trust chain including multiple Power of Attorney Credentials. To reflect the chain of trust, the provenance field contains another Power of Attorney Credential, which can be nested to any size. Therefore, the provenance field of the PoA Credential issued by Employee A in the given example includes the PoA Credential issued by the functionary. In turn, PoA Credential issued by the functionary would include the Enterprise Credential issued by the Bundesanzeiger. As a result, the bank can trace the chain of trust from Employee B to the Bundesanzeiger, which is trusted because it is on the list of trusted issuers.
References
- World Wide Web Consortium (W3C) (2024), Verifiable Credentials Data Model v2.0, Available at: https://www.w3.org/TR/vc-data-model-2.0/ (Accessed at: July 9, 2024).
- World Wide Web Consortium (W3C) (2024), Bitstring Status List v1.0, Available at: https://www.w3.org/TR/vc-bitstring-status-list/ (Accessed at: July 22, 2024).