This post is a bit of a throwback to the cultural norm we had in this community at the beginning between 2005 and 2010 – when social media was really just your own blog – and the blogs you read each day via your RSS reader. There was no Twitter and no Facebook and no professional oriented dialogues in those mediums – rather it was all blogging call and response.
Northern Block published a post last week written by their CEO Mathieu Glaude, putting out a call to action to figure out how we can have a “Digital Universal Credential [sic] Adaptor”. It is not a viable idea – I will explain why and what we can do to move forward.
The idea of a universal digital credential adapter in the post builds on analogies from the real world like electronic adapters for different electric socket shapes or voltage levels that exist around the world. It sounds great – “Sure, let’s just do that, it can’t be that hard, can it?” I used to think this too, but you can’t do it.
It is not possible because deep properties of how the cryptographic technology works and how technical trust is confirmed do not allow the wallet to be a “transformer”.
One Really Needs to Understand How it Works
During the winter of 2019-2020, I was asked to write a report for an organization who needed to communicate to upper management the key differences between different wallets and different stacks in part so they could make a decision about which path to go down. It was at this point I dug in and got much deeper into understanding the real and significant technical differences between the credential formats and different wallets. The research I did for this report became the basis of the Verifiable Credential Flavors Explained paper that I wrote a year later with Lucy Yang (who is now my business partner) to explicitly explain the key differences. We followed it up with an infographic of the four major formats of Verifiable Credentials (VCs) at that time – they all are technically within the W3C VC format specification – but are actually not technically interoperable. Both the paper and infographic were specifically designed to be simplified yet technically accurate so they would be accessible to business decision makers trying to understand the differences they had techies telling them about. I recommend people who are trying to understand the key differences look at both.
During COVID times and the work in leadership at both the COVID Credentials Initiative and Good Health Pass Collaborative, it became clear that the ONLY way to move or “adapt” from one credential format to another was via a proxy issuer that would need to read a credential proof from a holder, take the claims in that proof and package them up with new cryptographic signatures. Then the holder will be able to use the new VC issued by the proxy issuer in a different format at verifiers. Verifiers who wanted to accept credentials from a whole variety of sources figured out how to read the cryptographic signatures that came from a variety of different issuers.
If one is to use a proxy issuer, there must be an enormous amount of confidence (trust) by all parties involved that the proxy issuer won’t alter or create new facts about the holder and attest to who the issuer was as the original source of the credential. This requires a lot of governance.
In our current world, we have notaries that are licensed and keep detailed records of what they sign and attest to. They also do things like officially translate documents, say a birth certificate for a person from a foreign language into English for the purposes of submitting it to an immigration process. This is in-effect playing a proxy issuer role. And we see that we don’t trust “people” who the birth certificate is about to just translate it on their own without a third party, who the relying party (immigration authority that the document is being submitted to) having confidence in. The translation needs to be done by a third party that has governance systems in place around them to ensure that the possibility of their lying about the original document is low.
Wallets Just Can’t be a Transformer
Here is a metaphor from the physical world of credential and document security that is much more appropriate than the universal plug analogy.
Wax seals were used in medieval times to seal letters written by important people and sent to other important people. They sealed the outside of the letter folded up in a specific way and then a dab was placed on it and sealed with a metal impression from a seal or a ring. This way the recipient of the letter would know that the letter had not been opened, altered or changed in transit.
This is what we are dealing with – with VCs. Only proof of the original wax seal (cryptographic signature) from the original issuer will do to confer confidence and trust in the credential unless significant work is put into creating a proxy issuer infrastructure.**
A wallet under the possession of a holder can’t be doing the reading of the original proof and “transformation”, and then cryptographically sealing it again because holders have incentives to change the information in the credential. When a verifier gets a “transformed” credential it won’t have the original “wax seal” – but instead the seal from the transformer – the wallet of the holder acting as a proxy issuer.
Part of what VCs have power is that individuals using them generally do not self-assert (this in effect what would happen if the wallet was the transformer between format types). They are using VCs to communicate what issuers who have authority for saying something about the person do so via cryptographic signatures they (the issuing authorities) control. Issuing authorities are entities like universities asserting who graduated from law school or medical school. We don’t care who self-asserts these things, but we care that real institutions assert them.
In the Northern Block post, it is suggested that “research is required to understand and safeguard the credential’s attributes and values during the transformation [by the wallet].” This doesn’t make sense because proof that a VC was signed by the issuer is what makes it work. And the suggestion “we must focus on ensuring these frameworks can accommodate and seamlessly convert between all these formats without compromising the credential’s integrity or the issuer’s integrity” is a waste of time, because any transformation in the middle (by the wallet) fundamentally does compromise the credential integrity and the issuers integrity.
Your Choice Has Consequences
Other than the untenable wallet transformation idea, the following assertion is also made in the post:
Issuers will issue credentials in their chosen format without being forced to adhere to a specific standard, similar to the electrical socket in a specific country, which provides power according to its local standards without needing to conform to the formats used elsewhere. One issuer may pick AnonCreds and another may pick JSON-LD to issue a similar credential.
There have been established standards for electrical sockets across the world for a long time. And there is little to no governance needed around plug usage by travelers or anyone across the world. The standards are simple and readily there, and it is left for individual travelers to figure out and bring the right adapter. However, the standards and governance for credentials and wallets are still underway, especially when it comes to the preferences by the different geographic regions/countries/jurisdictions. For issuers at large who eventually need to be attuned too and comply with their regional/national/local standards, the idea of issuers can issue credentials in their chosen format without having to adhere to a specific standard is a ‘radical’ one. Issuers are likely to have options but limitations as well.
Looking beyond issuers’ choices, all choices will have consequences, even the ones made by a certain jurisdiction. For example, if jurisdiction 1 chooses a format/cryptographic algorithm that another jurisdiction 2 has evaluated and determined that it will not accept (because the math it uses isn’t well enough vetted), then the people to whom jurisdiction 1 issues credentials to – will demand that they have credentials issued that can be accepted in jurisdiction 2. There are conversations like this going on behind the scenes right now – certain jurisdictions thought they would pick signature formats and that others would just accept them – and they are not doing this. It is the right of jurisdiction 2 to reject signature formats that have not been validated by agencies tasked with certifying the security of such things.
Moving Forward
Making simple analogies for credentials and wallets without understanding the key trust features of the architecture and how all of the signature types achieve “trust” (confidence and believability) is dangerous. Our industry is at a critical juncture, and we need real thought leaders and pragmatic implementers to make headways into the mass market.
- Stop papering over format differences and pretending they can be solved with simplistic ways. Really dig in and understand the key differences between the formats and the features and trade-offs along with requirements of different parties in the ecosystem along with actual capabilities of hardware and capabilities of software and how it all works together.
- When needed, issuers can dual issue in more than one format with more than one signature type. Issuers are adopting this strategy and choosing to issue to holders the same information in two credentials in two different data formats with different signatures scheme and the public keys listed in different registries with different governance structures. Then when a verifier is asking for a credential in a particular format (hopefully one of the two they have in their wallet) they can provide it.
- Keep believing in the ideals of the community and working towards those ideals but stay grounded in what is possible technically. There is currently a trade-off that needs to be made between hardware key capabilities and the most ambitious selective disclosure and ZKP algorithms. The folks in the EU are currently dealing with this and it cannot be escaped. The solutions can’t do all things all the time. And at some point in the future, they will be more capable.
— End Post–
Foot Note:
** It is possible to create a proxy issuer based solution. This can be done and is being done for a few use cases like Tru-Age for NACS, but the “wallet” in this case is not doing the proxy issuing – it can’t for it to be trusted. A third-party witness sees the original credential and repackages just the photo and an assertion of age above (18 or 21) is issued to the holder. In fact, a stack of one time use credentials is given to the holder so they can present the same information and not have it tracked by verifier collusion. The relying parties, in this case the convenience stores, trust the proxy issuer because of the governance put in place that the creators of this particular ecosystem have stood up.
Post Script:
I will note that if I were to write the paper Verifiable Credential Flavors Explained paper now, I would add at least two more formats (ps. If you want this paper to be extended, you can sponsor our consulting firm to do that work). There is a very extensive spreadsheet tracking “all” the credential formats that you can see here; some have basically no adoption and are just early experiments, others didn’t exist when we wrote the paper and are in the EU Architecture Reference Framework.
