TNO EASSI: Solving the effort of offering support for a great variety of wallets

In SSI there are typically 3 different roles:

1. the issuer,
2. the verifier
3. the holder.

The issuer has data about or otherwise relevant to the holder, e.g. their age, and issues a credential to the holder. This credential holds a claim about the subject’s age, but also a cryptographic proof that the issuer was the data source, (a link to) the issuer’s public key and other metadata.

The holder can store this credential in an application on their phone, which we call an SSI wallet. Whenever the holder wants to prove for example that they are older than 18 while buying alcohol, the wallet transforms the credential into a presentation. A presentation contains exactly the information with assurances such that the verifier can use the information to validate and verify the holder’s age.

Is variety a recipe for disaster?

There are a lot of different approaches to forming the credential, such as how the information is structured and what cryptographic signatures are used. There are also various protocols for sending the credential . These different technological approaches lead to different implementations that in turn lead to a multitude of different SSI wallets, as can be seen in the figure below.

The variety in wallets can be a good thing for the user – they get to choose which wallet(s) they want to use, based on how privacy- and user-friendly the wallet is.

However, for the parties in the role of verifier or issuer, offering this variety to the user requires a lot of implementation and integration work, as all these wallets need to be connected to their service in a different manner.

Especially now with the new eIDAS2 regulation, stating that each EU Member State has to decide on their preferred SSI wallet and all Member States should allow the usage of the wallets picked by their fellow Member States. This means the eIDAS regulation will force parties to offer support for a variety of wallets.

The cost and manpower to reliably support all wallets would be considerable. The fact that this is the case for lots of parties (not all of whom able to keep up, resulting in uncertainty about apps working/not working), could be a recipe for disaster. We need a solution to prevent this. Ideally, if all countries choose the same wallet or if the chosen wallets work in a similar technical fashion, supporting multiple wallets doesn’t have to cost too much effort. Would such a scenario be feasible?

Standardize everything?

One way to achieve this would be to standardize the working of SSI wallets. This, however, is hard to achieve. There are different opinions on how an SSI wallet should work, for example whether a blockchain should be used. The wallets currently in use or in development each have their own pros and cons. There is no guarantee that consensus will be reached and getting to a universally supported standard will take a long time.

Meanwhile big-tech companies (both Apple and Google are very transparent about their ambition) will have come to dominate the market for wallets with proprietary solutions adhering to only their privacy standards.

This would also implicate that access to vital domestic digital infrastructure (banking, healthcare, travel, education, etc) can become dependent on (oftentimes foreign) big-tech. Especially in the current turbulent geo-political world, this may not be something to look forward to. Besides, standardizing too much too soon might stifle innovation.

One wallet to rule them all?

Another solution would be to pick one wallet such that issuers and verifiers only have to provide support for this chosen wallet. However, this is not a realistic solution, as then not only all Member States should agree on the usage of the same wallet, but also all organizations that want to exchange data with each other.

Furthermore, this is not giving the holder the freedom to pick their preferred wallet based on privacy and usability, thus reducing their self-sovereignty.

Imagine having a wallet that contains all your highly sensitive information, including your social security number. A user might prefer that they can choose to have another wallet for less important information, for example to login to some web shop. The web shop should not be able to obtain the holder’s social security number. Of course this should be handled technically or through governance structures, making sure the verifier upholds the data minimalism principle, and at the bare minimum by showing the holder the information that will be shared with the verifier.

That being said, having an extra wallet that does not contain this level of sensitive information is a fool proof solution to make it impossible to inadvertently share sensitive data with the web shop. We do not consider a singular wallet to be a viable solution. Standardization might offer relief, but will take time and there is no guarantee that everyone will adhere to one single standard.

So what then would be the alternative? Let’s take a look at an earlier successful innovation that tackles a somewhat similar problem: payment service providers (PSP), such as Mollie, Stripe and Adyen, maintain a gateway that allows you to pay online with your preferred payment method, such as PayPal, iDEAL, Creditcard, etc. An online web shop can just connect to the PSP and the PSP handles the connection with the payment services mentioned above. Could we create an analogy for SSI?

TNO EASSI – A gateway to freedom

TNO created a solution to facilitate support for all wallets by making a gateway that can interact with any wallet (regardless of the underlying technology): the TNO EASSI Gateway. Issuers and verifiers connect to this gateway and the API then handles the exchange of data with the holder.

EASSI can be used as a gateway to request or obtain qualified data , which is data along with assurances, such as the provenance and integrity. In the role of verifier, this means that you can use this data to achieve your foreseen purpose for the processing of the data, i.e. the data is fit-for-purpose. The issuer provides qualified data whereas the verifier consumes the qualified data and decides what assurances are needed for the data to be qualified.

Implications for the holder

As there is a wider acceptance of wallets, you as a holder are free to pick which wallet you prefer, as long as the wallet meets the requirements posed by the issuer or verifier. This increases the holder’s autonomy and self-sovereignty. When using EASSI to verify your credential, you can select your preferred wallet, as can be seen in the figure below.

Implication the issuer and verifier

As you only have to connect to one API, which is easy to connect to and well-documented, you can save yourself a lot of pain and effort. After connection, you immediately obtain the capability to communicate with all wallets supported by EASSI.

When a new wallet is released, you can support this wallet with barely any effort, as your connection to the EASSI API remains the same. Similarly, maintenance and dealing with major (sometimes breaking) changes after a wallet update are no longer a concern for the issuer or verifier.

Implication for the wallet provider

When trying to gain traction with a new wallet app, you normally face the following dilemma: the wallet needs to be broadly supported by issuers and verifiers before the average user is interested in using it. At the same time, issuers and verifiers will only invest in supporting apps when there is sufficient demand. Convincing these parties to offer support for your wallet can be difficult, let alone if they also have to invest time and money in supporting the wallet on a technical level. The hurdle of taking care of technical support for new wallets is taken away when using EASSI. Therefore EASSI makes it easier for new wallets to enter the SSI market.

Privacy is not compromised by using TNO EASSI

As SSI is a privacy-enhancing technology, ideally EASSI does not decrease privacy compared to not using EASSI. Within the context of SSI, privacy is often divided into the following types: data minimisation, control, transparency and issuer and multi-show unlinkability.

EASSI doesn’t need to have negative consequences with respect to transparency, control and multi-show unlinkability. Each party offering SSI can have their own instance of EASSI running locally. In this case only the party itself can see the information that is exchanged via EASSI.

Another possibility would be to have a Trusted Third Party (TTP) host the gateway, without the TTP seeing the data exchanged via EASSI. This means that the TTP hosting EASSI does not see what credentials are issued or verified. Only the issuer and holder or verifier and holder see the data exchanged, hence nothing has changed in terms of data minimisation and issuer unlinkability.

TNO EASSI is a simple solution for a complex problem

In conclusion, there are a lot of different technical solutions within the SSI ecosystem, leading to a wide variety of SSI wallets. Our gateway allows you to serve all these wallets without having to invest the time, money and manpower to offer support for these wallets yourself as issuer and/or verifier.

It is a sustainable choice, as EASSI matures and new wallets are developed, we hope that it will offer support for every new wallet, such that it will automatically be available through EASSI for issuers and verifiers running EASSI. EASSI also allows for more autonomy for the holder, as they can freely choose their wallet. So whether you want to issue or verify credentials, implementing SSI in your processes will be a lot easier with EASSI. If this interests you, feel free to contact us so we can assist you in your SSI journey and aid in setting up the EASSI gateway.