C4DT Demonstrator using the Swiss Public Sandbox Trust Infrastructure
This is our third article about the Swiss e-ID Journey. An overview of the system can be found in our first article, Switzerland’s e-ID journey so far [1a], and an introduction to the first steps of using the sandbox [8] in our second article, The Swiss e-ID Journey [1b].
In this article we present the demo we wrote to get to know the Public Sandbox Trust Infrastructure [8] from the Swiss government. The last article in this series will finish off with an overview of the currently existing protocols and developments around Self-Sovereign Identity (SSI) [7].
C4DT Demo
In order to join the journey of the Swiss e-ID project, we started with the Public Sandbox Trust Infrastructure (hereafter called sandbox [8]) that was offered publicly on github. Our goal, as described in our 1st blog post, was to implement a simple use-case in order to get to know the sandbox [8] and better understand the e-ID challenges. Starting from there, we then identified research challenges, which we are pursuing with our affiliated labs and our partners.
EPFL Diploma
As mentioned in our first blog post, we decided to work on a demo of how to issue diplomas for our Bachelor and Master degrees. The system includes the whole cycle of the diplomas:
- Registering EPFL as issuer
- Registering the diploma scheme
- Issuing a diploma
- Storing it on a student’s phone
- Verifying the diploma (or parts of it) by a company who wants to hire the student
From the beginning, we made it clear that this was in no way supposed to be a production system. For one, the sandbox was always declared to be shut down by the FOITTafter some time. Furthermore EPFL itself plans to use another electronic system for its diplomas in the future.
The diplomas to be issued followed the schema, which is stored like this on Hyperledger Indy [6b]:
 |
| The entry of our schema on the sandbox [8] Hyperledger |
And it can be inspected in more details on the ledger scanner here: https://explorer.sandbox.ssi.ch/tx/SANDBOX/domain/340
Implementation
Here is a short overview of how we implemented and configured the different elements of the sandbox:
The public ledger for holding the public data of the issuers utilizes Hyperledger Indy [6b], which is provided by the sandbox [8]. Storing the public key of the EPFL issuer was a straightforward process, and storing the schemas for the diplomas was equally simple.
The issuer of new verified credentials is described in the sandbox [8] using a docker-based installation. Thanks to its docker-based nature, the installation process was easy. We had a technical issue with CORS which made it impossible to use the demo on Chrome.
As mentioned in the first technical part, the only secure wallet that worked with the sandbox was the esatus [4] wallet. This was because different wallets follow different workflows or expect data in different formats or send requests in a specific order. Ultimately, the esatus [4] wallet was the only one that worked with the sandbox [8]. The app is publicly available, but not the code.
Since the sandbox does not provide a web app for the verifier, we developed a simple verifier web app [1c] that allowed us to interact with the wallet. By using this verifier web app [1c], it is possible to obtain a selected set of information from the diploma stored in the wallet, enabling selective disclosure.
In the following figure, you can see how the different parts of our implementation work together.
 |
| Overview of our implementation |
Screenshots
Here you can see how “Leo Inc.”, a potential employer, checks whether a given diploma is valid or not. We do not show here how the user got his diploma in the first place and assume that the Verified Credential representing his diploma is already stored in the app.
 |
| Step 1: This is the diploma stored in the esatus [4] app on the user’s device. |
 |
| Step 2: To verify the diploma, the user is presented with this QRCode from Leo Inc. |
 |
| Step 3: After scanning the QRCode, the user is presented with the request from Leo Inc. Here we can see that Leo Inc. did not request all fields from the VC representing the diploma. |
 |
| Step 4: Once the user accepts the request, the HR department of Leo Inc. can visualize the diploma, complete with the verification of the signatures. On the right, one can see the different steps performed, which include a verification of the public key used to sign the VC. |
Challenges
In order to write the verifier web app [1c] and the issuer, we had to use the Hyperledger Aries [6a] documentation. Unfortunately it was hard to follow, as the relationships between the components were not clear.
As described earlier, the search for the wallet also took some time. Some of the wallets had a list of pre-configured ledgers, without the possibility to add new ones. Others were not compatible with the version of the Hyperledger Indy [6b] used in the sandbox [8].
EPFL Research Subjects
With some of our affiliated labs, we are currently involved in looking at new cryptographic algorithms like BBS+, popularizing how the different parts of e-ID work, and looking into zero-knowledge proofs [2c] applied to e-IDs.
We are also active in the DIDAS Educational Working Group [3], keeping an eye on possible usage there of our sandbox [8].
Next steps for the Swiss e-ID
In January 2024, the team responsible for proposing the technical details of the Swiss e-ID system proposed two scenarios for the definition of the upcoming Swiss e-ID. Both scenarios are based on Self-Sovereign Identities (SSI) [2a] and respect the privacy of the users. While scenario A proposes to follow the upcoming ARF [5] from the EU, scenario B proposes a more privacy-friendly technology which is not EU-compatible, at least in the initial phases.
Scenario A
 |
| Scenario A taken from the Discussion Paper Proposal (for an overview of the abbreviations, see The SSI Protocol Landscape) |
From the paper:
Scenario A would mean 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. The following technologies would be used in particular: SD-JWTs for credentials and OID4VCI/OID4VP as an issuing and presentation protocol.
The ARF provides a pragmatic technical approach to implementing digital identities and digital identity wallets. It is based on well-known and proven technologies and cryptography. While the proposed communication protocols are new, they offer easy integration for ecosystem participants and transparency for software developers.
The main downside with this approach is the lack of two privacy preserving technologies: zero-knowlege proofs (ZKP) [2c] and unlinkability [2b].
Scenario B
 |
| Scenario B taken from the Discussion Paper Proposal
(for an overview of the abbreviations, see The SSI Protocol Landscape) |
From the Discussion Paper Proposal:
Scenario B would use a technology stack that aims to offer a higher level of privacy for holders in the ecosystem than that provided in Scenario A. At the current time, this would mean choosing an independent technological path for the Swiss trust infrastructure and the national e-ID.
[…]
By using alternative but less common cryptography, credentials can be issued that enable holders to navigate the future trust ecosystem while leaving fewer digital traces behind. The properties regarding “unlinkability” […] are met by this technology stack. Credentials would use signature schemes that allow wallets to generate unique proofs for each verification. These proofs contain no constants and therefore do not link back to the originally issued credential. […]
[…]
The e-ID team has ascertained that the technology employed in Scenario B, despite promising improved privacy preservation, exhibits a lower level of maturity compared to Scenario A, which could result in more effort and resources being required to provide the e-ID.
In this scenario, it might be possible to create ZKP [2c] on the data in the e-ID. ZKP [2c] is more privacy preserving because it could be used to create expressions like “is over 18”, “works in the canton de Vaud” without revealing the exact age or the exact address.
Outlook
Together with our affiliated labs and our partners, we’re looking forward to exploring this fascinating journey on e-ID in Switzerland and beyond. We hope that our participation will help create a privacy-preserving, trustworthy, and useful e-ID for Switzerland, and inspire other e-ID efforts.
For an overview of the current available technologies regarding SSI [2a], you can read our fourth article of the series: The SSI Protocol Landscape.