Switzerland’s E-ID journey so far
In 2021, the Swiss E-ID law proposition was rejected by a public referendum. The reason for the refusal was due to privacy concerns in the implementation and management of that system. In a nutshell, the idea that a private entity would be in control of users’ data was frowned upon.
Since then, there has been a new proposition in the making. From their website: “Work is underway on the e-ID project, which aims to establish a system of state-recognised, electronic credentials (e-ID) and introduce the associated legislation. This is the task of the Federal Office of Information Technology, Systems and Telecommunication (FOITT), along with the Federal Office of Justice (FOJ), the Federal Office of Police (fedpol) and the Digital Public Services Switzerland (DPSS).” All discussions and development happen in a publicly available GitHub organization: https://github.com/e-id-admin. They did this to develop a prototype solution and gain approval from the technical community before settling on a final solution / proposition for the new law.
The Swiss Confederation set up a public sandbox where more than 20 companies and organizations got in first contact with the new E-ID solution. C4DT is among those participating in this test and discussion phase. This blog post is the first in a series of three on the subject and serves as an introduction to the topic, as well as an overview of our experiences and takeaways. The two follow-up blog posts will cover the technical aspects of the subject in more depth.
The nuts and bolts of E-ID
The following concepts are important in the discussion of the CH E-ID solution:
Verifiable Credentials (VC): Digitally signed documents issued to a person or an entity that prove a claim. The authenticity of these documents can be verified through cryptographic methods. Verifiable Credentials can be seen as a superset of E-ID.
Issuer: Entity that issues credentials by signing them. The public key is stored on the ledger and can be used to verify the signed credential. This proves to a verifier that the data contained in the VC has been approved by an issuer.
Verifier: Entity that wants to verify a VC based on the information stored in the ledger.
Wallet: The wallet is an application installed by the user that stores their credentials. It also prepares the credentials and presents them to the verifier.
Ledger: The ledger is the ‘trust anchor’ of the system. It stores the public keys of the issuers, as well as the revocation registries used to invalidate VCs. It is the reference used by verifiers to verify the signature of a credential.
Swiss Confederation Public Sandbox Trust Infrastructure
The E-ID sandbox of the Swiss Confederation, released in 2023, is a system based on Hyperledger Indy. Within this system, the Swiss Confederation manages the ledger, and accepts and records the registrations of the issuers. More than 20 companies and organizations signed up to test and get to know the system.
An encryption library called “Anoncreds” is used to provide security and privacy features. The most important ones are “Selective Disclosure” and “Zero-knowledge proofs”. The former allows the wallet to only show parts of the data in a VC, while the latter allows the possibility of proofs like “I’m 18 years or older”, “I live in the canton of Vaud”, or “I work for a company with more than 10’000 employees” without disclosing additional information.
C4DT Demo: Issuing and verifying diplomas
Using this sandbox, C4DT built a proof-of-concept application to issue and verify diplomas. In our demo, we provide two websites. One website is for an issuer, in our case a school that issues diplomas for its students. A student can log onto the website to connect with the school, accept their digitally signed copy of the diploma and store it on their wallet.
The second website is for a verifier, in our case a company that advertises a job position. The company’s website requires applicants to provide a verifiable credential that proves they obtained a diploma from the aforementioned school.
You can find the code on our GitHub repo here: https://github.com/c4dt/eid-demo
Takeaways
We succeeded in creating the demo, but it was not a trivial journey. There were a number of hurdles along the way.
The Swiss Confederation provided a “cookbook” to onboard the community into the Trust Infrastructure Sandbox, which was enough to set up the services on the server. However, it didn’t provide information on how to use the libraries to write the demo.
The different projects linked to Hyperledger do have some information, but much of it is outdated or simply missing. Also, there are very few Open Source projects available that would have allowed us to understand how the Hyperledger libraries work. Luckily, one project did help us understand the libraries, the one written by Ubique.
For storing the diplomas in our demo, we needed to find a suitable wallet application. But most existing wallets are tailored to a specific use case and not generic enough. In the end, we did find one wallet, esatus, which was able to interact with the Public Sandbox Trust Infrastructure.
Taking a look at the bigger picture, while Hyperledger Indy poses some challenges, it does offer a mature system: it has many privacy features, including selective disclosure, zero-knowledge proofs, and “unlinkability”. In cryptography, “linkability” means that if you send an anonymous proof about your age to two different systems, e.g., an alcohol store and a discotheque, they can figure out it is the same person.
Compared to these systems, the current EIDAS proposition from the EU, which is the E-ID framework for the EU, has less protection of the users’ privacy: it only proposes selective disclosure, but no zero-knowledge proofs or even unlinkability.
Where do we go from here?
At their first in-person E-ID “Participations Meeting” on the 1st of December 2023, The Swiss Confederation took inputs from all users of the sandbox and started to consider the next steps. They proposed two scenarios:
- Scenario A: “Using a subset of the technologies proposed in the European Union’s Architecture Reference Framework ARF, with the aim of aligning closely with the EU’s proposal for implementation.” Switzerland would have to wait for the finalization of EIDAS and would lose some desirable privacy features, but the system would be directly compatible with the EU.
- Scenario B: Use a more advanced system based on BBS+, which offers better privacy guarantees, but is not yet as mature as Anoncreds. This scenario would also allow more research by interested EPFL professors.
C4DT believes that scenario B is preferable. It offers better privacy guarantees and the evolution of BBS+ is likely to be sped along by a cadre of EPFL professors who are keen to participate in its development.
After 3 meetings with members of a technical advisory circle, the Confederation published a technical discussion paper and carried out an informal consultation.
We hope you enjoyed the overview of our experiences with creating a demo for the Swiss Confederation Public Sandbox Trust Infrastructure. There will be two more articles going into more technical details about our work on the demo. Stay tuned!