I have a vision of a new way of working: Employees will have a wallet of digital certificates. In addition to their e-ID, it will also contain their digital driver’s license, identity card, professional certifications, health insurance certificate, maybe even loyalty cards and more. This ecosystem will be founded on self-sovereign identity and verifiable credentials. What’s behind it? Is the technology mature enough? And how customer-friendly could the system be, right now?
The current status of SSI
After the rejection of the initial concept for an e-ID, the Federal Council launched a consultation. The findings were clear: It needs to be a decentralized solution, initiated by the state. In a preliminary statement, the Federal Council then also said: “Based on the results of the consultation, the Federal Council has laid down basic principles for the design of a future state e-ID: Users of the e-ID should have as much control over their data as possible (self-sovereign identity).” The Federal Office of Justice took up the baton and launched one or two pilot projects in keeping with the draft bill: a digital driver’s license, digital federal identification card, and some infrastructure development. Within the EU, moves are already underway to provide a sample infrastructure based on the SSI principle. So for the CSS PoC, we joined up with MainIncubator GmbH’s EU-compliant project IDunion/lissi.
In SSI, there are three roles: issuer, holder, and verifier (Figure 1). In simple terms, imagine that the insurer (issuer) provides confirmation of insurance (verifiable credential), the customer (holder) keeps this in their wallet, and a hospital (verifier) requests this when they are admitted. The entire process is cryptographically secured and digitalized. Without needing to contact the insurer, the hospital can be confident that the data are authentic and have been issued by the insurer. This is ensured by means of verifiable credentials (similar to forgery-proof physical ID). Only information such as public keys and data schemes are stored in the verifiable data registry. At the moment, this is mostly achieved using a blockchain or distributed ledger technology.
Figure 1: The self-sovereign identity trust triangle
CSS PoC: Gym visit confirmation via loyalty card
The process starts with the assignment of an identity (“The holder is insured with CSS”). This happens on CSS’s secure portal. The customer must log in to CSS so they can be securely identified. A QR Code is displayed that generates a query in the customer’s wallet; this stores the insurance confirmation in the wallet as a certificate (verifiable credential, Figure 2). The second step enables the customer to use this certificate at the gym to prove that they are a CSS customer, and have the visit confirmation transferred to their wallet. Here, the gym is first in the role of verifier and then in that of issuer of a certificate. For the purpose of the example, this visit confirmation certificate includes bonus points as additional information. In the third step, the points are allocated (again by scanning a QR code in the CSS portal) and redeemed, thus confirming the visit. Here, again, the roles are reversed: CSS becomes the verifier, requesting confirmation from the customer.
As you can see from this example, the roles are constantly changing. The points can be redeemed without needing to contact the issuer (gym). However, it’s possible to perform a cryptographic check that the data have not been changed and originate from a verifiable issuer. This also works if you’re using revocable certificates.
Figure 2: The customer’s acceptance of the SSI certificate is displayed in the wallet.
Experiences and further applications
Using lissi for the implementation meant we were able to successfully implement the “Visit confirmation using loyalty card” use case. The program code that we built is well-structured and comprehensible. The data exchanged can be processed directly and digitally. The infrastructure was gener-ally reliable. Unfortunately, the revocation case has not yet been developed in lissi, so a workaround was required, which complicated the solution. However, from the client perspective, it was clear that there is a little more work to do, for the creator of the wallet in particular. What would be the best way to group certificates clearly? Might it be useful to offer the customer the time-limited opportunity to display certificates from a particular issuer (where necessary), without requiring them to “click through” a confirmation each time?
The release of a detailed insurance confirmation directly from the insurer definitely has potential. If confirmation of insurance could be read as a verifiable credential, the process of admission to hospital could be digitalized end-to-end without the need to switch between media. In other situations, it might be enough to simply know that insur-ance is in place. Yes/no questions such as these can be answered through zero-knowledge proofs without revealing the underlying data. Further applications for verifiable credentials stored in a wallet include med-ical reports (fitness to drive, fitness to dive) or confirmation that the doctor can charge a certain tariff (dignity). PoCs have already been undertaken for other confirmations, such as qualification certificates, entry permits and activation codes.