OID4VCI Authorization Code flow journey pattern

This journey pattern is used to issue credentials of different formats to a holder via the OID4VCI Authorization Code flow.

Overview

• Issuance channel: Remote, Unsupervised
• Device/s: On-device / Cross-device / in-person
• Formats: mDocs, CWT, JSON
• Information assurance level: High
• Identity assurance level: High (when identity assurance checks are included)

Journey flow

Architecture

Scanning the QR code

The QR code that is used to initiate the issuance workflow is created by the Issuer, but the Holder selects when to scan it using their digital wallet (1) which triggers the issuance workflow.

This QR code can be sent to the holder via any existing communication channels, including digital and paper based channels.

Credential offer

Once the QR code is scanned it will result in the wallet displaying the credential offer that was created by the Issuer using MATTR VII issuance capabilities. The offer details the credential formats that will be issued in this workflow, and what details would each credential include.

Digital Trust Service capabilities (9) enable creating and maintaining policies that define what Issuers can be trusted and what credential types they are allowed to issue. This introduces an additional level of trust to interactions within the trust network, making it easier for Samantha to decide whether or not she wishes to claim a credential from this Issuer.

Obtaining a binding attribute

The OpenID Credential Provisioning (2) component commences the credential issuance flow by obtaining a unique binding attribute from the requesting device/wallet. This happens when the user accepts the credential offer (step 3 in the pattern above).

The binding attribute is carried through the proceeding steps to bind the intended credential holder and the data.

Authentication

The OpenID Connect Provider (IdP) is a component managed by the Issuer to authenticate users against the data they hold about them. The Issuer’s IdP (3) facilitates the authentication flow (step 4 in the pattern above) which may include multiple steps that test different factors such as:

• Basic username/password authentication.
• Proving device ownership through acknowledging a unique request sent directly to the device.
• Providing genuine presence assurance (liveness check) that the correct user is in possession of the device being used to facilitate the journey.

The issuer can configure this authentication flow requests to include login hint parameters (for example pre populating the user e-mail address) to create more seamless user experiences.

Interaction hook

Following successful authentication, the user can be redirected to a custom component (4) hosted or controlled by the Issuer (step 5 in the pattern above). This custom component can initiate additional steps for the user to perform as part of issuing the credential.

This can be used to embed enrolment within the issuance journey.

We refer to these custom components as Interaction hooks.

Claims source

As part of gathering authenticated claims that are included in the issued credential, the Issuer may want to retrieve additional information about the user from external data store/s (5).

This optional step (step 6 in the pattern above) enables issuing credentials that are more rich in information and thus provide greater value. It is achieved by configuring an external data store, which we refer to as a Claims source.

Credential generation

The information then gets passed back through the OpenID Credential Provisioning component (2) to map against an established vocabulary, and express the intended context around each piece of information it holds.

The mapped data is then passed to the Credential Generation component (6) which formats, binds and signs the data into a credential that is ready to be sent to the requesting wallet/device (step 7 in the pattern above).

The credential can be issued in multiple-formats. Additional features may be enabled to support capabilities such as credential revocation or allowing the holder to respond to selective-disclosure verification requests.

Credential management

Digital wallets (1) can be used to manage the acceptance and secure storage of the credential on the Holder’s device upon completion of the credential issuance flow (step 8 in the pattern above). This can be achieved by wallets built with our MATTR Pi Wallet SDK or branded MATTR GO Hold applications.

Webhooks

At the completion of the issuance flow, MATTR VII will trigger any configured Webhook events to configured recipients (7). These events (step 9 in the pattern above) offer additional information about the credential issuance (such as the wallet DID) back to the issuer for them to utilize or store.

This enables integrating issuance workflows into existing business processes, or creating new ones based on this capability.