What is the problem?
Revocation is a fundamental function for all digital identity and credential solutions. It allows to limit the use of a credential or identity even after its initial issuance and activation, thus making it possible to correct mistakes, react on fraud attempts or simply enforce governance.
In current digital identity systems, revocation is easy, a user’s identity or digital credential gets flagged in the database or simply deleted, revocation done. In decentralized setups this is a little trickier, since the identity or digital credential handed out to the user is now on their device with the capability to cryptographically proof it towards verifiers of all sorts. This way, the issuer cannot change it anymore.
In the trust triangle, one obvious solution to the problem could be that the verifier asks the issuer directly for the status, but this is neither privacy preserving nor aligned with the decentralized identity paradigm that seeks to decouple issuers and verifiers to allow for more independent interactions, where an open ecosystem of issuers and verifiers is enabled to collaborate indirectly based on the decisions and needs of the identity and credential holder.
I was waiting 4 year for this moment...
–Andreas Freitag
In 2020, I realized that the decentralized identity technology community has no solution for scalable and privacy preserving revocation. The best thing you could find at the was the accumulator-based revocation method from the Hyperledger Indy and Aries Community, which does not scale.
I started a PhD with the goal to solve the problem and searched for a better method. Looking back, I know that my hopes to quickly solve this challenge were naïve, but that’s another story.
Two years later and after a lot of headaches I came to suggest a pretty straight forward solution that is both privacy preserving for the holder and scalable. I called it Linked Validity Verifiable Credentials.
Why is scalability important?
If we want to make decentralized identities and credentials work in the real world, the technology must support an implementation at scale. At scale means millions of users and millions of credentials with their associated lifecycle. A revocation method must support this amount of lifecycle events without creating unjustifiable effort, complexity and cost on deployments.
Why is privacy so important?
If we take a shortcut by going directly from the verifier to the issuer to request the revocation status, the identity solution will turn into a tracking system that is no longer sufficing the decentralized identity requirement aimed at decoupling issuers and verifiers, effectively circumventing other privacy features of decentralized identities and digital credentials.
What are the current revocation methods and why they are not suitable?
- Accumulator based (e.g. INDY/Aries): not scalable and not mature enough
- Other accumulator-based methods: not mature enough, still in research phase
- List based methods (e.g. bit string status list): scalable but not privacy-preserving
How does this new revocation method - Linked Validity Verifiable Credential (LVVC) work?
The concept is straightforward. When a Verifiable Credential gets issued, a Linked Validity Verifiable Credential (LVVC) is issued alongside. The LVVC only contains a cryptographic link to the associated Verifiable Credential, the issuance date and the status.
The Verifier requesting a Verifiable Credential from the holder requests both, the VC and the associated LVVC from the holder to enable the Verifier to check the cryptographic link to the VC, as well as the issuance date and status of the LVVC. If the issuance date in the LVVC fulfils the requirements of the Verifier, the associated Verifiable Credential is valid.
In the typical case, that a verifier requires a recently updated LVVC to suffice its requirement, the Holder can update the LVVC by contacting the Issuer to get a new LVVC. This newly issued LVVC will contain the cryptographic link to the associated Verifiable Credential, the new issuance date and the current status.
In our Procivis One solution, the wallet is performing this LVVC update request in the background on a regular basis to ensure that holder always has Verifiable Credentials with an up to date status in their wallet. If a Verifier requires a near real time status check for verification, the Holder can trigger an update manually in the wallet.
With this approach, there is not direct connection between the Issuer and the Verifier, thus making sure that the Issuer learns nothing about the usage of the Verifiable Credential and the Verifier learns nothing about the past and the future state of it.
What are the advantages?
- It only uses common SSI technology, no new fancy cryptography
- It is scalable, millions of updates are no problem
- The LVVC size is always under control independent from the associated Verifiable Credential
- The associated Verifiable Credential does not need to be re-issued to have a changed status
- Absolutely Privacy Preserving, with no direct interaction between Verifier and Issuer
- Usable with any protocol, while we advise to use protocols that allow for minimal disclosure to support unlinkability on the verifier side
What are the disadvantages?
So far, we have not found any. While it might look challenging to have a regular issuance of LVVCs happening on a solution, our tests have shown that this creates no significant load on the system. All other methods also need at least one communication/update/exchange interaction between two parties in addition to the credential sharing process.
What’s next?
We have implemented LVVC in our Procivis One solution now and would love to see it being widely used in the community. Ultimately, our hope is to develop this into a standard and ensure that decentralized identity solutions can be both privacy preserving and scalable.
If you want to use this new quantum-safe technology, just get in touch with us directly. Our team is looking forward to more exciting projects and partners.
This article is based on the original post of Andreas Freitag on LinkedIn.
