OID4VCI 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
Logging into a provider Portal
Samantha logs in to a self-service portal to check that status of driver license application.
Requesting a Driver’s License
Samantha realizes that issuer is offering an mDL as well.
Requesting a Mobile Driver’s License (mDL)
Samantha clicks on a button to ‘Get Mobile Driver License’
Displaying a QR code
Issuer presents a QR code on screen.
Scanning the QR code
Samantha scans the QR code using her wallet app.
Providing consent
Samantha is presented with a pop-up asking for a consent to collect credentials in the wallet
Transaction code
A transaction code will be sent to Samantha via email or SMS that she will enter in the wallet app to collect the credentials in her wallet.
Credential issuance
Samantha consents then receives the credential into her wallet.
Architecture
Logging into the 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 (1) 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.
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 (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 (3) 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 (4) 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.