Oct 12, 2022
How we keep track of trusted credential issuers
Spherity has built an Ethereum-based trusted issuer registry for use in the US pharmaceutical supply chain
SSI Trust Triangle
Before we get stuck in, let’s set the scene with a quick recap on Self-sovereign Identity (SSI). There are three key entities in an SSI ecosystem: Issuer, Holder, and Verifier. The relationship of this trio is often referred to as the trust triangle. The credential issuer generates and bestows the Verifiable Credential (VC); the holder has control over the use of the VC and is usually the entity to whom the VC is issued, and the verifier checks the claims within the VC. The latter trusts the legitimacy of the issuer but does not need to trust the holder thanks to the verifiability of the holder’s VC.
It follows that the credential issuer is effectively a trust anchor. This is the core entity that should really not mess up or be messed with. So, how can we trust them? More specifically… How does the verifier know that the issuer is legitimate? How does the verifier know that it was indeed the legitimate issuer who issued the VC and not an imposter? How does the verifier know that the issuer was eligible to issue the VC at the time of issuance?
The issuer in the physical world
Not everything is down to tech. That’s why there must be ways to get some degree of certainty that the credential issuer is a trustworthy entity based on real-world evidence. Who are they? Why are they suited to issue credentials? How do they issue credentials?
Let’s understand the specific ecosystem in which Spherity operates. We are a leading member of the Open Credentialing Initiative (OCI). This is an industry-wide collaboration with the initial goal of enabling US pharmaceutical supply chain actors to comply with the impending enforcement of the Drug Supply Chain Security Act (DSCSA). As it stands, in the OCI ecosystem the credential issuer is a private enterprise with a proven track record in regulatory compliance services within the US pharmaceutical supply chain. Currently, there is only one such organization within OCI, Spherity’s close partner Legisym. They have been around in the credentialing world even before OCI was born and are one of its founding members. So, you could argue that they’re good guys and the OCI ecosystem can just trust them because they have proven themselves worthy from PoC to pilot to productive implementation. However, OCI cannot just operate on handshakes and goodwill — neither with OCI veterans nor new entrants. Thus, OCI has drawn up conformance criteria for credential issuers. Whoever wants to be eligible to issue VCs within the OCI ecosystem must pass a third-party audit against these criteria. This is how OCI creates trust in the legitimacy and suitability of the issuer.
The issuer in the digital world
Now that we know the issuer is legit, we need to make sure that this is somehow represented in automated digital interactions. That’s where the trusted issuer registry comes into play. In essence, it is a living electronic register that keeps track of all issuers who have passed the OCI-mandated audit and, thus, saves the verifier the hassle of checking the issuer manually upon receipt of a VC.
In the spirit of decentralization, Spherity has built such a registry by employing an Ethereum smart contract, i.e. a program that executes automatically when triggered. This choice of technology delivers the following core benefits by design:
- Always available: As long as the Ethereum blockchain is alive and kicking, so will the access to the registry.
- Trustless: It allows OCI to design a governance structure and architecture which ensure that the registry is not owned or controlled by a single entity.
- Transparent: The code and completed interactions with the registry are public and, thus, viewable by anyone.
- Auditable: Previous states of the registry can be retrieved. Thus, events and governance decisions at any point in the past can be investigated.
- Secure: Only trusted entities are enabled to make changes to the registry. A cryptographically enforced governance protocol takes care of this.
The smart contract containing the trusted issuer registry is accessed via an Ethereum node and executes in the background. For OCI-authorized entities, so-called Statekeepers, to interact with it, they need to use a React web app that leverages web3.js to connect to a MetaMask Ethereum wallet. MetaMask basically hooks up the user interface with the smart contract, and thus the Ethereum blockchain, to allow Statekeepers to retrieve or modify the state of the contract. Any modifications to the registry are submitted as signed transactions that are routed through MetaMask to the Ethereum blockchain.
Statekeepers are subject to a governance protocol that defines the voting rules. Through the smart contract, Statekeepers vote on proposals to add or remove trusted issuers and to add or remove other Statekeepers. Once a proposal has received sufficient votes, a Statekeeper can instruct the smart contract to enforce it. Since the rules are anchored in the code, there are clear-cut execution mechanisms and enforcement is not debatable. A change to the rules, and consequently the code, would need to be managed through OCI’s change process. This is where we re-enter the human world. In a community of diverse stakeholders, the rules of interaction must be managed in some way. This is why OCI members and to a degree also outside contributors are required to abide by OCI’s Governance.
Let’s bring all of this back to the original question of how such a trusted issuer registry makes a verifier’s life easier. When a VC holder presents their credential to a verifier, both use a digital wallet (or SSI wallet) for this exchange. This is a piece of software that allows its owner to securely acquire, store, manage, and check VCs. It is the job of the verifier’s wallet to scrutinize the incoming VC for its authenticity in a fully automated process. There are several checks a VC has to pass. Here we focus solely on issuer verification. Upon receipt, the wallet finds the field containing the credential issuer’s unique decentralized identifier (DID) inside the VC, then compares this information with the entries in the trusted issuer registry and declares the issuer as legitimate only if there is a match. If the VC also passes all other checks, the wallet will accept it as legitimate and the verifier can trust its claims. In the context of OCI’s ecosystem, for example, a pharmaceutical manufacturer would receive a VC from a pharmacist claiming that they are a so-called Authorized Trading Partner (ATP) as defined by DSCSA. The manufacturer’s wallet would get busy comparing the issuer DID in the pharmacist’s VC with the DIDs in the OCI-managed trusted issuer registry. Only if there’s a match, will the manufacturer accept the pharmacist’s VC as valid. As all of this is fully automated, it happens in less than one second without any human intervention and also allows integration into all sorts of business processes that require some kind of identity or claims proofing before launching any potentially ensuing actions like information exchange, order processing and shipment, or billing.
You will have noticed that I just smuggled another essential component of the OCI ecosystem into the picture — the digital wallet (e.g. Spherity). To ensure that service users who rely on OCI-approved service providers have free choice between digital wallets, each wallet must be compliant with OCI’s conformance criteria for digital wallets, which define security and performance conditions as well as prerequisites for interoperability between different wallet providers and, consequently, the associated user systems.
Outlook
Spherity has built the described trusted issuer registry as a practical implementation for a specific real-world use case because there was simply no off-the-shelf solution out there and we needed one now. Nevertheless, the way we have constructed this registry also allows its use in many other contexts. As it happens, the topic came up at the recent annual Rebooting the Web of Trust gathering, RWOT11 in The Hague. One of our dev team members participated in this project to share our learnings and gain new insights. Find the draft document on the RWOT GitHub. The group has been discussing the potential for future standardization of trusted issuer registries. This would go a long way towards agreeing on best practice across use cases and industries, creating a qualified point of reference, and preventing incompatibilities between systems.
To learn more about our pharmaceutical supply chain use case, check out our CARO product site.
