Adding support for revocation of Verifiable Credentials
The MATTR team is excited to announce a critical new addition to our product capabilities. We’re continuing to build out an extensive suite of features to support the exchange of Verifiable Credentials (VCs), leveraging the best efforts of the open-source community along with a number of distinct product innovations. These innovations include our recent work related to using BBS+ signatures for privacy-preserving selective disclosure and our earlier work on the OIDC Credential Provider spec. We’ve also been busy sharing new tools for checking the syntax of a JSON-LD credential during development.
In this product release, we are focused on one of the fundamental capabilities in any credential-based system: the ability to provably revoke a credential when it’s no longer valid. Using verifiable data in combination with open standards not only improves the quality of the data exchanged in an ecosystem, it also enables the authority (issuer) on any piece of information to maintain that data throughout its lifecycle. In practice, this means that credential issuers can manage the status of a credential directly, using the same general mechanism as the one used for issuing VCs.
Credentials are typically stored by the user (subject) in some kind of digital wallet where they are able to manage their credentials and control when and how to share their data. When accessing services, the user may consent to present their VCs to a relying party (verifier). The relying party needs to be able to be able to verify the credential is genuine and tamper free. They also need to be able to easily validate whether a presented credential has been revoked or not.
For example, say you’re issued a digital driver’s license, then you go and get several speeding tickets. The department that issued your license determines you have breached the terms of your license and consequently, suspends your license. In doing so, the credential status is changed, and next time a relying party checks the status they will be able to see that you are no longer entitled to drive. If a car rental office is checking your driving status in order to loan you a vehicle, they’d like to be able to verify if the digital license is still valid and legitimate.
In general, we want to accomplish all of these goals while minimizing the burden on data issuers and verifiers, and preserving the autonomy of credential holders in deciding how to store and disclose their data. We also want to remain flexible around where the revocation list is stored and managed, so we opted to implement an approach that’s extensible to different types of infrastructure supported by the issuer. The resulting solution contrasts with others that have tended to be tightly coupled with a particular kind of infrastructure such as a distributed ledger. We believe revocation should be built in a simple, transparent, and standardizable manner, which is why we built our approach on the W3C CCG’s Credential Revocation List.
Practically, the information regarding whether a credential has been revoked is represented in the credential status property of a VC, as defined in the W3C spec. When a credential is first created, the issuer can include in the credential status field a reference to a publicly available revocation list. This list can be updated by the issuer at any time, so resolving this reference will always get you the latest revocation status. The retrieved revocation list is in the form of a JSON-LD based verifiable credential, making it straightforward to validate. Holders and verifiers can simply check this revocation list to determine if a specific VC has been revoked or not. Since the revocation list contains the revocation status of many credentials, credential subjects get “herd privacy” with regards to the issuer, meaning the issuer doesn’t know where an issued credential is being used. This protects the holder against one form of surveillance and potential leakage of their personal data. Some use cases will require solutions that offer an even greater level of privacy for credential subjects, such as cryptographic accumulators. We are actively working on a number of improvements in this area which will offer enhanced privacy for credential holders when it’s required and simplify the process of relying parties validating a credential’s status.
We’ve implemented this functionality using a simple optional flag on our VC issuance API, allowing issuers to toggle between credentials that support revocation and those that don’t. On the holder side, our Mobile Wallet App automatically checks the revocation status when opened, alerting the user of any changes and giving them a warning if it’s revoked. For verifiers, validating credential status is a standard part of our VC verification API, so validation will automatically fail if the credential is revoked.
Integrating revocation into our platform brings us one step closer to building a fully realized verifiable data ecosystem, an environment where verifiers can have more confidence and trust in the decisions they’re making and people can participate in the sharing and exchange of information without eroding their basic privacy. We look forward to continuing to collaborate with the community and gathering feedback from industry to enhance and extend different ways to accomplish revocation while respecting users’ digital rights. Sign up on our website to get access to our platform and check out MATTR Learn to start issuing revocable credentials.