OID4VCI Pre-authorized Code flow journey pattern

This journey pattern is used to issue credentials of different formats to a holder via the OID4VCI Pre-authorized Code flow protocol.

Overview

• Issuance channel: Remote, Unsupervised
• Device/s: On-device / Cross-device / in-person
• Formats: mDocs
• Information assurance level: High
• Identity assurance level: High (depends on the mechanism used by the issuer to authenticate the holder prior to sharing a credential offer)

Journey flow

Architecture

Logging into a provider's portal

The underlying architecture assumes that the Issuer can reliably confirm the user's identity before issuing the credential offer. This enables seamless, low-friction issuance experiences while preserving trust and security.

Scanning the QR code

The QR code used to initiate the issuance workflow is generated by the Issuer, while the Holder controls when to scan it using their digital wallet. Scanning the QR code triggers the credential issuance process.

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. When the QR code is scanned, the Holder’s digital wallet initiates the credential issuance workflow and displays the credential offer prepared by the Issuer using MATTR VII's issuance capabilities.

The offer outlines the credential formats to be issued and specifies the claims included in each credential. In a pre-authorized flow, the Issuer can gather information about the intended Holder in advance—since the offer is created for a known user—allowing the Issuer to tailor the credential with specific, user-relevant claims.

Digital trust service capabilities 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 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.

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

Transaction code

To enhance the security of the pre-authorized issuance flow, the Issuer may optionally require the Holder to provide a transaction code before the credential can be claimed. This code is generated by the Issuer as part of the credential offer and is uniquely associated with that offer.

The Issuer sends the transaction code to the user through a secure, alternative communication channel such as email or SMS. When the user initiates the issuance process by scanning the QR code, they are prompted by the wallet to enter the transaction code. The credential can only be issued if the correct code is supplied.

This optional verification step strengthens the assurance that the credential is issued to the intended recipient, helping to prevent unauthorized access in scenarios where the credential offer may have been intercepted or misdirected.

Credential issuance

The information then gets passed back through the OpenID Credential Provisioning component 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 which formats, binds and signs the data into a credential that is ready to be sent to the requesting wallet/device.

Credential management

Digital wallets 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. This can be achieved by wallets built with our MATTR Pi Wallet SDK or branded MATTR GO Hold applications.