Let’s (actually) Share Our Verifiable Credentials
Introducing the JWT VC Presentation Profile
Co-authored by Daniel McGrogan
Verifiable Credentials (VCs)[1] give us a standard means to digitally represent information about anyone or anything such as a person’s driver’s license, a service animal certificate, or an access credential to allow entry into a building.
We are all familiar with traditional credentials — a qualification, achievement, or any aspect of your personal background. They are everywhere. Traditional credentials are only as good as the “paper” they are issued on and more often than not, are both difficult and expensive to verify.
VCs, unlike traditional credentials, are digitally signed, immutable, tamper-resistant, and verifiable.
Let’s imagine you are a dog, named Dog (end user). You are traveling at the airport with your human and you show CatAirlines (verifier) your official service animal VC that’s stored in a digital wallet on your phone. They try to confirm that your job is to support your human so you can board the flight. It shouldn’t matter if the digital wallet that holds the VC is developed by one company (Collie Corp.) and the verifier system by another (Shorthair Inc.). Each part in that credential exchange is published in a specification so it should just work. But instead, when you try to present your VC to CatAirlines, it doesn’t work. Your supposedly interoperable VC can’t be verified and you and your human can’t travel.
Since the beginning of Workday’s journey with decentralized digital identity, we have been focused on the question:
How can we share credentials?
Currently, there are many published specifications for exchanging VCs between digital wallets (holders) and verifiers. The wallet and verifier providers have to choose which standards to operate under and hope that the external parties they wish to exchange VCs with support those same standards. Dog’s wallet and CatAirlines did not choose the same set of standards and the VC couldn’t be verified.
In order to tackle the problem of how we actually share credentials, Workday teamed up with Microsoft, Ping Identity, and MATTR to develop a specification profile that outlines a list of standards and, once adopted by providers, would enable seamless verification of VCs. Development of the profile continues within the Decentralized Identity Foundation (DIF).
In this blog post, we will give an overview of why specification profiles are required, what this profile involves, and what it means for the adoption of VCs.
Specifications
Specifications and standards are central to the way we communicate, both in the physical and digital world. In the olden days of software, most of the adopted specifications came from government organizations, academic institutions, and large corporations — think DARPA, Stanford University, Bell Labs, Ericsson, etc. Today, standards are often developed as a part of community organizations or standards bodies such as the Internet Engineering Task Force (IETF), World Wide Web Consortium (W3C), and DIF. These organizations bring together interested parties to develop a common description, understanding, and solution to a domain problem. Developing specs in this way brings benefit to the community and technical space:
- A diverse group of interested parties involved allows the spec to solve for a wide range of use cases
- Collaboration provides a motivated group of advocates for the solution
- Solutions are agnostic to particular technology stack
Why The Need for a Specification Profile
We have all of these effective specifications from organizations like IETF, W3C, and DIF which can solve our VC exchange problems, right? Not quite.
A downside to developing specifications in such a collaborative way is that they tend to be very broad, flexible, and un-opinionated. This is an advantage when building use cases and providing optionality to the implementers. But, in the case of exchanging VCs, it can cause misalignment. The more optionality in the specification, the more complex and expensive it becomes to deliver code, maintain a solution, and happily verify a VC.
Consider all the legal versions of the JSON Web Token (JWT) signing algorithm — last we counted, there were 40. It would be expensive and time consuming to cater to all 40 possibilities and as a result only a subset of these algorithms are supported in any given verifier implementation. Imagine your disappointment when you try to share your VC with CatAirlines but they cannot accept it. The JWT VC was signed with an ES256K private key but the airline can only verify RSA256 signatures. You and your human can’t board the flight.
Out of this problem, the JWT VC Presentation Profile was born.
The Presentation Profile
“If you want to go fast, go alone. If you want to go far, go in a pack.”
- Adapted from Anonymous by Dog
A specification profile outlines the way in which multiple parties agree to implement a given set of specifications. A good profile will strip all but required optionality from a specification. Instead of supporting 40 different JWT signing algorithms, the JWT VC Presentation Profile, which is a type of specification profile, requires only two. That’s a 20x reduction in complexity with one constraint. More generally, the JWT VC Presentation Profile describes a standardized way to exchange VCs. It enables Dog to present a compliant VC to CatAirlines and CatAirlines to verify it.
The specifications included in the JWT VC Presentation Profile are:
- OpenID for Verifiable Presentations (OpenID4VP) [2]
- Self-Issued OpenID Provider v2 [3]
- Decentralized Identifiers (DIDs) v1.0 [4]
- W3C Verifiable Credentials Data Model v1.1 [1]
- VCs encoded as ES256K and EdDSA Signed JWTs
- Presentation Exchange v1.0.0 [5]
- OpenID Connect Dynamic Client Registration 1.0 incorporating errata set 1 [6]
- Sidetree v1.0.0 [7]
- Well Known DID Configuration [8]
- Identity Hubs (Decentralized Web Nodes v.0.0.1 predraft) [9]
- Status List 2021 [10]
The profile is based on OpenID4VP [2] which leverages the existing infrastructure and security of OpenID Connect (OIDC) and OAuth 2.0 and reduces implementation cost for existing OIDC Relying Parties to become VC verifiers. It relies on Presentation Exchange [5] for the presentation of VCs, Well Known DIDs [8] for trust establishment, and Status List 2021 [10] for revocation of VCs.
The flow begins as CatAirlines generates a QR Code that contains a request uri which allows a Self-Issued OP (SIOP) Request [3] to be passed by reference. CatAirlines displays this QR code on their website to initiate the exchange. Dog scans the QR Code using their wallet and parses it to obtain the request uri.
The wallet sends a GET request to the obtained request uri to retrieve the SIOP Request Object. The Request Object is a signed JWT that contains a set of request parameters as defined in SIOPv2 [3] and OpenID4VP [2].
Upon receiving the Request Object, the wallet confirms the identity and trust of the verifier by checking their Linked Domain (Well Known DID) [8]. It then identifies VCs that satisfy the Presentation Definition [5] and encapsulates them in a Verifiable Presentation (VP) [1]. The wallet completes the authorization response by sending an ID Token and a VP Token [2] to CatAirlines.
After receiving the ID Token and VP Token, CatAirlines performs necessary checks, including token validation, DID resolution (did:ion or did:web), signature validation (ES256K or EdDSA), Linked Domain validation for trust establishment (Well Known DID), and revocation checks (Status List 2021 [10]). The flow from end user to verifier, Dog to CatAirlines, is now complete. This process is simplified in the diagram above.
The Future
In creating this specification profile, we incorporated readily accepted and available technologies, agreeing to continue to innovate and improve as new standards emerged. We strive to balance security, usability, ease of implementation, and privacy.
We recognize that no specification profile will be universally accepted after the first iteration. Profiles will independently adapt, grow and branch as implementer needs change. Over time, successful profiles will likely converge until we have a set of universal standards that can easily be supported by issuers and verifiers across the world.
We are actively working on a specification profile for Verifiable Credential issuance and in the future will expand the scope to cover such topics as wallet portability and selective disclosure.
Using the JWT VC Presentation Profile, Dog and human seamlessly board their CatAirlines flight and fly to their destination. CatAirlines reduces engineering time, money spent, and customer support headaches. Everyone wins.
We encourage you to check out the profile, use it for your projects, and let us know what you think: https://identity.foundation/jwt-vc-presentation-profile
References
- Verifiable Credentials Data Model v1.1
https://www.w3.org/TR/2022/REC-vc-data-model-20220303 - OpenID for Verifiable Presentation https://openid.net/specs/openid-4-verifiable-presentations-1_0.html
- Self-Issued OpenID Provider v2
https://openid.net/specs/openid-connect-self-issued-v2-1_0.html - Decentralized Identifiers (DIDs) v1.0
https://www.w3.org/TR/did-core/ - Presentation Exchange v1.0.0
https://identity.foundation/presentation-exchange/spec/v1.0.0 - OpenID Connect Dynamic Client Registration 1.0 incorporating errata set 1
https://openid.net/specs/openid-connect-registration-1_0.html - Sidetree v1.0.0
https://identity.foundation/sidetree/spec/v1.0.0 - Well Known DID Configuration
https://identity.foundation/.well-known/resources/did-configuration - Identity Hubs (Decentralized Web Nodes v.0.0.1 predraft
https://identity.foundation/decentralized-web-node/spec/0.0.1-predraft - Status List 2021
https://w3c-ccg.github.io/vc-status-list-2021
