OpenID for Verifiable Presentations

IBM® Verify Identity Access Digital Credentials supports the OpenID for Verifiable Presentations V1.0 specification. For more information, see the specification https://openid.net/specs/openid-4-verifiable-presentations-1_0.html.

About this task

The verifying application serves as the primary point of contact for user interaction and wallet engagement. The verifying application uses the DC Agency Service to support key functions such as wallet engagement, credential exchange, and verification. As defined in the OpenID for Verifiable Presentations V1.0 specification:
  • The wallet acts as an OpenID Provider (OP) or Authorization Server.
  • The verifier, configured and hosted by the DC Agency, acts as the OAuth client.

The following diagram below illustrates the main components of a deployed solution that supports verifiable credential issuance using the OpenID for Verifiable Presentations specification. Components shown in blue are provided as Docker container images at the following locations:

Table 1. Components and container location
Component Container Location
DC Agency Service icr.io/ivia/ivia-digital-credentials:<tag>
IVIA OpenID Provider icr.io/isva/verify-access-oidc-provider:<tag>
Figure 1. OpenID for Verifiable Presentations main components

OpenID for presentation components

Procedure

  1. Create an agent with a verifier profile. The profile includes the verifier’s root of trust certificate and associated private key. These are used to sign JWT-secured authorization requests, which are conveyed to the wallet either by value or by reference. An exchange template is also created to define the presentation authorization request and exchange properties.
  2. After the configuration in step 1 is complete, the verifying application interacts with the user.
  3. During the interaction, the verifying application initiates an OpenID for Verifiable Presentation exchange session. The DC Agency service returns a wallet engagement URL and QR code, which the application uses to invoke the wallet.
  4. The wallet is invoked and presents a user experience to the user.
  5. If the exchange template defines a “by reference” JWT-secured authorization request model, the wallet fetches the authorization request JWT from the DC Agency service. The wallet may also send wallet metadata and an exchange none to the verifying agent, as specified by the OpenID for Verifiable Presentation specification. These data are incorporated into the authorization request.
  6. The wallet presents a user experience that allows the user to review the requested credentials and attributes. If the user consents, the wallet sends the credentials, using the vp_token to the verifying agent within the DC Agency service. The verifying agent cryptographically verifies the payload, and the verifying application retrieves the presented credential data from the DC Agency service.