The Swiss E-ID Journey
This article is the second in a series of three articles which discusses C4DT’s experiences and takeaways testing the Swiss Confederation Public Sandbox Trust Infrastructure, hereafter abbreviated as “sandbox”. In the first article, we looked over all the components of the sandbox, and its setup. In this article we delve deeper into the technical details of the E-ID system and its components.
We dig into the technical aspects of Switzerland’s first proposal for an E-ID system, exploring its architecture, components, and the innovative use of decentralized identifiers and verifiable credentials. You will learn how the choice of technology preserves the privacy of the users and allows for secure usage of this system.
A short Timeline
The First E-ID Proposal
In 2019, the Swiss government proposed a law on E-ID that relied on a collaboration between private companies and the public sector. It was challenged to a referendum, and then rejected by a large majority in 2021.
“Mistrust in private companies was dominant and helped to tip the vote.”, said political scientist Urs Bieri of the GfS Bern research institute on SRF public radio, as mentioned in the article on swissinfo.ch.
Moving to Community-Driven Development
The rejection of the first E-ID proposal showed the crucial role of trust and transparency in the development of a national E-ID system. In response, Switzerland’s E-ID team prioritized these values from the early stages of their new approach. They actively sought community feedback through the creation of a sandbox environment, engaged in discussions on GitHub, and held regular online “Partizipation-Meetings” with the community.
In late 2023, the E-ID team from the Swiss government organized a one-day event in Bern, bringing together organizations to showcase their prototypes built using the sandbox. The event featured talks on E-ID-related topics by both government representatives and private companies, as well as discussion groups to foster further collaboration and exchange of ideas.
The Second E-ID Proposal
While open discussions and feedback formed the backbone of the new E-ID system’s development, the Swiss government also recognized the importance of embracing openness from a technical perspective.
The revised E-ID system’s technical foundation relies on open-source technologies and standards, moving away from proprietary software. A first set of potential solutions included Hyperledger Indy, a project hosted by the Linux Foundation, and the OpenID Foundation’s OID4VC architectures. These open-source solutions ensure greater transparency, interoperability, and community involvement in the development process. You can find more info in the Discussion Paper by Switzerland’s E-ID team.
In the following sections, we will explore the technical components of the current sandbox in greater detail and discuss how our demo was built on top of this foundation.
Current Public Sandbox Trust Infrastructure
The sandbox is a safe platform with minimal resources designed for testing and experimenting with the provided Indy system. Its primary goal is to gather quick feedback from the community early in the development process.
Onboarding
To start using the sandbox, users must complete a simple sign-up process by filling out a form available in French, German, or Italian. Access credentials are then communicated via email. A cookbook covering a basic use case is available on the GitHub repository to help users set up an agent (along with a database) and start issuing Verified Credentials.
Ledger
The trust anchor of the E-ID system, and one of the main components of the sandbox, is the ledger. It uses Hyperledger Indy, an open-source E-ID ledger built on distributed ledger technology, prioritizing trust and transparency.
The Swiss E-ID team currently manages the ledger, granting access to organizations, private entities, or individuals who wish to issue their own credentials.
Those with access can define the structure of their credentials by declaring a format and sending it to the ledger. To act as a verifier and check the validity of others’ credentials, no access rights are needed, as the ledger can be read by everybody.
Information Stored on the Ledger
The ledger stores various types of publicly accessible information, but Hyperledger’s design ensures that no personal identifiable information (PII) is stored or can be inferred from it.
Important information stored on the ledger includes:
- Decentralized Identifiers (DIDs) and public keys of issuers
- Schemas and Credential definitions describing the structure and format of credentials to be issued
All this information is publicly accessible to everyone, guaranteeing transparency and making it easy for third parties to audit the system, which increases trust.
Trust in Indy
Hyperledger Indy’s distributed ledger technology uses consensus mechanisms to ensure resilience against failures and malicious behavior. In a typical Indy network, multiple nodes operated by various organizations work together to maintain the ledger’s integrity and consistency. Trust can be achieved in Indy through decentralization, permissions, and consensus protocols.
Decentralization
To ensure no single organization controls the entire network, nodes in a Hyperledger Indy network should be operated by a diverse set of trusted entities. This way, even if some nodes act maliciously or become compromised, the network can still function correctly and maintain the ledger’s integrity.
Permissions
Hyperledger Indy is a permissioned blockchain, meaning entities wishing to participate as node operators must be granted permission, usually by a governing body or consortium.
Consensus Protocol
Consensus mechanisms are used to ensure all nodes participating in a network agree that the same transactions happened, and to prevent malicious nodes from misbehaving. Plenum, the consensus protocol used by Hyperledger Indy, enables the system to reach consensus even if some nodes fail or behave maliciously. It achieves this through a rigorous algorithm of message passing and voting, ensuring all honest nodes arrive at the same state of the ledger.
Technical details of the E-ID based on Hyperledger Indy
One huge advantage of the Hyperledger system is that it is an ecosystem in itself. This means that the Hyperledger foundation has built Indy with all the building blocks for an E-ID system.
Building Blocks of the Indy system
Ledger
The ledger is the most critical component in an E-ID system, and Hyperledger Indy serves as the ledger in this case.
Verifiable Credential format
There are several formats for verifiable credentials (VC), with AnonCreds and the W3C VC format being the most notable. AnonCreds is among the most popular VC formats by Hyperledger. The W3C format will most likely be used in the second iteration of the sandbox and will be discussed in more detail in the following article.
Privacy-Enhancing features
A good VC format should support privacy features such as Selective Disclosure and Zero-Knowledge proofs (ZKP). While AnonCreds already provides ZKP, they are still experimental in the W3C VC formats. However, the format itself doesn’t provide details about the cryptographic mechanisms used to support these features, requiring additional libraries.
- The AnonCreds library comes with the necessary cryptographic protocols built-in.
- For W3C VC, developers need to find a suitable library implementing the required cryptographic protocols (e.g., the BBS-signatures library that implements BBS+).
Agents – Issuers, Verifiers, Wallets
To implement applications on Hyperledger Indy, an agent software like Hyperledger Aries is required. Aries is a comprehensive library that facilitates the issuance, storage, and verification of verifiable credentials.
With skills in application/cloud development, it is relatively easy to start building a new application using Aries. The Aries Python implementation, which comes with Docker for easy installation and use, and an OpenAPI specification included in the repository, was used for our demo.
Conclusion
This concludes our second article on our experience building on the Swiss E-ID sandbox and working with Hyperledger Indy. Here are some links to help you get started right away on your own E-ID application:
- Apply to join the CH E-ID public sandbox
- Issue your first VC with the cookbook
- Explore diverse demos and tutorials provided by the Aries library
Additionally, C4DT has built a full demo app that supports an issuer and a verifier. To use it, simply provide a link to your personal agent, which you should have installed using the cookbook.
Appendix
These terms should help you understand all the important aspects of a discussion around E-ID.
Identity
E-ID
A digital equivalent of a physical identity card. It can be used for online identification, offline via digital peripherals (phones/ smart watches / etc.). E-IDs exist in many different formats depending on the system used.
Self-Sovereign Identity (SSI)
SSI is a type of E-ID that gives full control over the identity credential to the owner of that identity. The information of the user’s identity is only stored on their devices, and not on a central entity. This allows the user to be in full control of their information. To verify a signature, a verifier needs to refer to publicly available information.
Being decentralized makes it difficult for a central entity to track user activities. However, it also puts the responsibility on the user to securely store their wallet and credentials.
Verifiable Credential (VC)
A Verifiable Credential is a standard way to encode a digital document containing information about an individual, entity, or object. VCs follow a specific format, and the data stored inside follows a specific schema. VCs use cryptographic techniques to ensure that they are tamper-resistant and can be verified by anyone who needs to rely on the credential. VCs are a key component in an SSI system.
Privacy Properties
Selective Disclosure (SD)
Selective Disclosure allows users to share specific parts of a Verifiable Credential. For example, you might want to share only your age with games that require a certain age at FunRidesPark or only your name with an online social network. One implementation of Selective Disclosure stores hashes of each of the VC’s attributes inside the VC object. When a user wants to share specific attributes, they send the data to be revealed alongside the signed VC, and the verifier then compares the hash of the revealed data with the hash in the VC.
*https://gataca.io/blog/ssi-essentials-which-selective-disclosure-protocol-will-succeed/
Zero-Knowledge Proofs (ZKP)
Zero-Knowledge Proofs enable users to prove a specific condition on the data within their VC without divulging the data itself. For example, instead of revealing your exact age, you can prove that you’re above a certain age threshold, say 13 years old, without disclosing your actual age to the verifier (e.g., FunRidesPark IT).
Unlinkability
Unlinkability allows wallet holders to provide their VC proofs anonymously, preventing a connection between different usages of the same credential from being linked together. In the FunRidesPark example, if you ride multiple games that require age verification, Zero-Knowledge Proofs will hide your information, but FunRidesPark may still recognize that the age verifications come from the same person. Using an unlinkable algorithm, your device will generate a new signature every time to prevent the verifying entity from making links between different verifications.
Protocols and algorithms
Decentralized Identifier Communication (DidComm)
DIDComm is a secure peer-to-peer communication protocol used in E-ID systems for wallet-to-wallet, wallet-to-issuer, and wallet-to-verifier communication. It can use direct communication mechanisms like Bluetooth and NFC, as well as protocols like HTTP(S), WebSockets, and push notifications.
To increase privacy, DIDComm allows users to send “Encrypted Messages” which hide their content from all but the authorized recipients. Additionally it only proves the sender to the recipient, while the forwarding parties don’t learn any details about the sender.
OID4VC
OpenID for Verifiable Credentials is a set of specifications that extend OpenID connect systems to self-sovereign identities. OID4VC specification is maintained by W3C.
AnonCreds
AnonCreds is a library that defines a Verifiable Credential format and also provides cryptographic mechanisms for signing and validating signatures. It is created by the Hyperledger Foundation for use in Hyperledger Indy. AnonCreds supports privacy-enhancing features like Selective Disclosure and Zero-Knowledge Proofs. It also supports unlinkability.
BBS+
BBS+ is a cryptographic scheme that enables Selective Disclosure, Zero-Knowledge Proofs, and unlinkability similar to AnonCreds. However, BBS+ provides a more general cryptographic scheme that can be used with different Verifiable Credentials formats and within various E-ID systems. In contrast, AnonCreds is more targeted for the Hyperledger Indy ecosystem and tightly integrates the cryptographic scheme into the Verifiable Credential format.
One common misconception is to compare BBS+ to AnonCreds. BBS+ is only a cryptographic signature scheme, where Anoncreds is a full suite of functionality around the signature scheme and the verifiable credential format. The signature scheme used by Anoncreds is the Camenisch-Lysyanskaya (CL) signature scheme.
