How issuers can manage credential revocation
Spherity has developed an Ethereum-based credential revocation mechanism for use in the US pharmaceutical supply chain
I have previously written about the importance of managing a registry of trusted issuers in the context of enterprise Self-sovereign Identity (SSI). A credential issuer, in turn, must maintain a registry of revoked verifiable credentials (VCs).
What does that mean?
Credential management is no mean feat for a responsible issuer (see Figure 1). In brief, a credential issuer examines real-world evidence, such as a trading license, to inform their decision on granting or rejecting the request for issuance of a VC that represents the inspected evidence in the digital world. But it doesn’t end there. Due diligence processes are not only required on initial VC issuance but are an ongoing task for the length of time that a credential holder wants to keep the credential. If the issuer notices any problems during their regular monitoring, for example an underlying license appears to have been revoked by an authority, they must check whether the electronic VC can remain active or whether it should be revoked to reflect the changed business situation. This is where the credential revocation registry as a source of truth comes into effect.
Why blockchain?
When the Spherity team looked at available revocation methods in the SSI space, we noticed that the choice was limited and littered with trade-offs. Some key observations we made were that most available revocation methods rely on very centralized or complex and this far unaudited accumulator-based approaches to store and update the revocation information. For our purposes a centralized, easy-to-target revocation server would pose a serious risk. We also require a higher degree of governance and participation of multiple entities in the revocation process than offered by existing methods.
Hence, we decided to go for an Ethereum-based approach for credential revocation that meets our main acceptance criteria:
- Availability: The revocation method should always be available and not bound to the uptime of a single web server. As long as the Ethereum blockchain is running, so will the access to the registry.
- Scalability: The revocation method should be able to handle a large number of revocations.
- Auditability: Previous states of the registry can be retrieved. Thus, revocation events at any point in the past can be investigated.
- Privacy: The revocation method should include basic protection against a set of known de-anonymisation attacks like the phone home problem or correlatability.
- Security: Only authorized entities are enabled to make changes to the registry.
- Trust: The revocation method should be usable at different levels of trust. It may be owned by the issuer, a community, or no one.
- Ease of use: The revocation method should be simple to set up and use.
Guided by these points, we have built the necessary components and also submitted a public proposal to the Ethereum community, EIP-5539, that defines a set of methods for a smart contract to act as a revocation registry. An Ethereum smart contract is basically a program that executes automatically when triggered and writes information to the blockchain.
How does it work?
The Ethereum-based revocation method leverages a smart contract to store, query and modify the state of revoked VCs. The smart contract follows a lean design, as it registers only two pieces of information about a VC:
- the random unique key (basically a value out of virtually infinite pool of allowable values) assigned to each VC on issuance and
- the revocation status of each VC in the form of true/false (revoked/not revoked).
Note that the smart contract only stores references to revoked credentials in the form of unique values. It does not contain any details about the type, content, properties or usage of any VC. The exclusive assignment of a separate key per VC enables retrieval of a specific VC’s revocation status and look-ups of historical events in the registry (see Figure 2). It follows that the credential issuer needs to implement logic to store and map revocation keys to VCs.
As explained previously, digital wallets perform routine automated checks on VCs. In order to know the revocation status, a digital wallet interacts with the smart contract in two ways:
- It listens. The wallet monitors the revocation registry for instant automated notifications about status changes of the VCs it holds. This is akin to subscribing to a newsfeed with alerts on topics of interest.
- It verifies. When a wallet gets an external VC presented by another wallet, the recipient’s wallet checks whether the credential has been revoked.
In automated business processes it is essential to know the up-to-date status of a VC, as business logic may block any further interaction with a counterparty whose credential is no longer valid. Similarly, if the holder’s own credential is found to be invalid, the logic may stall any routine actions or trigger a process to apply for a new VC.
A credential issuer may operate this method independently by themselves, use a third party as facilitator, or use a publicly available registry. Spherity has implemented a revocation API for use by credential issuers that processes revocation requests and updates the revocation registry. An issuer may either choose to use our API as a relay to the Ethereum blockchain or employ their own authorisation credentials, i.e. private keys, to modify or read the revocation registry. Every interaction with the smart contract is cryptographically saved on the Ethereum blockchain, which provides a virtually immutable public audit log.
What does all this have to do with US pharma?
The US pharmaceutical supply chain is facing a massive regulatory change with the Drug Supply Chain Security Act (DSCSA) coming into full force in November 2023. Just about a year to go!
To solve one crucial piece of the compliance puzzle, an industry-wide collaboration was formed in April 2021 named the Open Credentialing Initiative (OCI). Spherity is a leading member and digital wallet provider within this ecosystem. OCI’s initial mission has been to tackle the DSCSA requirement for pharmaceutical trading partners to identify themselves as duly authorised within electronic supply chain interactions.
The developed solution employs VCs that represent the enterprise as a legitimate legal entity as well as its valid trading authorisation. In this context, the need for a robust, auditable and privacy-preserving revocation method becomes apparent.
Imagine the following scenario (see also Figure 3).
King Pharmacy has a box of drugs sitting in storage. Something seems unexpected about it; the familiar brand Fripp, sure, but hasn’t King stopped ordering their products? Why is there a full box here? King’s concerned pharmacist Crimson decides to investigate. DSCSA requires him to enquire directly with Fripp whether the box has really been produced by this manufacturer even though King Pharmacy always uses a wholesaler for any orders.
Good job King Pharmacy has signed up with service provider Toyah who helped them get a Digital Wallet along with their ATP credential not long ago. So, Crimson goes ahead, scans the barcode and sends his enquiry off to Toyah who offers a so-called Verification Router Service (VRS). Toyah fetches King Pharmacy’s Authorized Trading Partner (ATP) credential from King’s digital wallet and takes care of sending it alongside the product enquiry to the manufacturer Fripp. King’s ATP credential has to pass several tests, including the revocation check. Since King Pharmacy is properly licensed, their ATP credential passes scrutiny. Fripp sends a response back through their VRS with Fripp’s appended valid ATP credential so that Crimson knows he can trust the response. Fripp confirms that the barcode matches their records. As it turns out, Crimson wasn’t aware that a colleague had stocked up on Fripp’s drug. So, all is good.
This entire exchange between King’s Crimson and Fripp happened fully automated within seconds. Since the product verification is entirely hands-off for the manufacturer, they can handle a high throughput in part thanks to an always reachable VC revocation registry. Should King or Fripp ever get audited, they can point to the digital transaction trail stored within their VRS or digital wallet system, or even the immutable, cryptographically secured transaction trail written to the blockchain via the revocation registry. The credential issuer is entirely unaware of the VC usage and revocation checks, as the technological design separates them from these processes, thus shielding King’s and Fripp’s interactions from unwanted bystanders.
(Note that the Ethereum-based revocation method is currently not included in OCI’s Digital Wallet Conformance Criteria.)
To learn more about our pharmaceutical supply chain use case, check out our CARO product site.
Outlook
Spherity has built the described credential revocation mechanism as a practical implementation for a specific real-world use case because there was simply no off-the-shelf solution out there meeting our requirements. We hope that our EIP-5539 will spark community discussions and help standardise this method to make it broadly available.
Besides the above-mentioned benefits of an Ethereum-based revocation method, we anticipate that the costs of maintaining a reliable “traditional” server infrastructure for revocation management by the credential issuer dwarf the transaction costs associated with using an Ethereum smart contract. In effect, the latter allows the credential issuer to change from a fixed cost overhead-laden method to a variable pay-as-you-go cost structure by paying per revocation.
Disclaimer: I am currently employed by Spherity. This article was written for the company blog and first published on Medium. I have permission to reproduce it here.
Many thanks to my colleagues Philipp Bolte (Developer), Lauritz Leifermann (Developer) and Georg Jürgens (Manager Industry Solutions) for your help in preparing this article.