Summary: Verifiable credentials have transport options other than DIDComm. In this post, I explore the OpenID4VC specification which allows credentials to be used in the OpenID ecosystem.

In my discussions of verifiable credentials, I assume DIDs are the underlying identifier. This implies that DIDComm, the messaging protocol based on DIDs, underlies the exchange of verifiable credentials. This does not have to be the case.

The OpenID Foundation has defined protocols on top of OAuth1 for issuing and presenting credentials. These specifications support the W3C Verifiable credential data model specification and support both full credential and derived credential presentations. The OpenID specifications allow for other credential formats as well, such as the ISO mobile driver’s license.

In addition to defining specifications for issuing and presenting credentials, OpenID for Verifiable Credentials (OpenID4VC) introduces2 a wallet for holding and presenting credentials. Open ID Connect (OIDC) redirects interactions between the identity provider (IdP) and relying party (RP) through a user agent under a person’s control, but there was never an OIDC-specific user agent. The addition of a wallet allows OpenID4VC to break the link that has traditionally existed between the IdP and RP in the form of federation agreements and an interaction protocol wherein the IdP always knew when a person used OIDC to authenticate at the RP. OpenID4VC offers direct presentation using the wallet.

Extending OAuth and OIDC to support the issuance and presentation of verifiable credentials provides for richer interactions than merely supporting authentication. All the use cases we’ve identified for verifiable credentials are available in OpenID4VC as well.

In addition to using the OpenID4VC wallet with a traditional OIDC IdP, OpenID has also added a specification for Self-issued OpenID Providers (SIOP). A SIOP is an IdP that is controlled by the entity who uses the wallet. A SIOP might use DIDs, KERI, or something else for identifiers. The SIOP allows Alice to control the identifiers and claims she releases to the RP. As with DIDs, a SIOP-based relationship between the RP and Alice is not intermediated by an external, federated IdP as it is in the traditional OIDC model.

When Alice uses a wallet that supports OpenID4VC and SIOP to present credentials to an RP, the Alice has a relationship with the RP based on a self-issued identity token she creates. SIOP allows Alice to make presentations independent from any specific IdP. As a result, she can present credentials from any issuer to the RP, not just information from a single IdP as is the case in traditional OIDC.

Like any other credential presentation, the RP can verify the fidelity of the credential cryptographically. This can include knowing that it was issued to the wallet Alice is using to make the presentation. The RP also gets the identifier for the credential issuer inside the presentation and must decide whether to trust the information presented.

To make fidelity and provenance determinations for the credential, the RP will need the public key for the credential issuer as is the case with any credential verification. The verifiable data registry (VDR) in an OpenID4VC credential exchange might be a ledger or other decentralized data store if the presentation uses DIDs, or it might be obtained using PKI or web-pages accessible under a domain name controlled by the issuer. Depending on how this is done, the credential issuer might or might not know which credentials the RP is verifying. The design of the VDR plays a large role in whether credential exchange has all the properties we might desire.

OpenID4VC is an important example of alternatives to DIDComm in verifiable credential exchange thanks to OIDC’s large deployment base and developers’ familiarity with its underlying protocols and procedures. Because the W3C specification for verifiable credentials does not specify an underlying mechanism for exchanging credentials, others are possible. If you find a need from an alternative, be sure to carefully vet its design to ensure it meets your privacy, authenticity, and confidentiality requirements.

Recall that OpenID Connect is based on OAuth.
For details on OpenID4VC, I recommend the introductory whitepaper from the OpenID Foundation: OpenID for Verifiable Credentials: A Shift in the Trust Model Brought by Verifiable Credentials (June 23, 2022)

Tags: identity ssi openid verifiable+credentials

Phil Windley's Technometria

Using OpenID4VC for Credential Exchange