OID4VCI journey pattern
This journey pattern is used to issue credentials of different formats to a holder via the OID4VCI protocol.
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
Receiving a credential offer
Samantha scans a QR code she has seen or received in a message, promoting her to claim a credential into her digital wallet. 2.
Reviewing the credential offer
Samantha is presented with the following information:
- What credential is offered.
- What information is included in the credential.
- Who is offering the credential, and whether that entity can be trusted.
Accepting the credential offer
Samantha elects to proceed and is redirected to authenticate with the credential issuer.
Authenticating with the issuer
Samantha’s email is already populated on the Issuer’s authentication provider’s login page. All she needs to do is enter her password to complete the authentication process.
Pre-populated fields is a configurable option that creates a more seamless user experience.
Biometric checks
As part of authentication, the credential issuer requires Samantha to undertake a biometric facial verification and/or multi-factor check to increase identity assurance. Samantha is redirected to a separate webpage to complete this check.
Different components can be plugged into the issuance workflow to accommodate different business rules and requirements.
Retrieving additional claims
Once Samantha has been successfully authenticated, additional information can be retrieved securely from a configured external source. Once the information is retrieved, it can be used as part of the issued credential.
Fetching information from external data sources is an optional step that can enrich the generated credentials, making them more useful and meaningful.
Signing a credential
The gathered information is formatted and signed as a digital verifiable credential that is ready to be sent to the requesting wallet/device.
The information can be formatted and signed in one or several available credential formats, supporting versatile and flexible credential capabilities.
Sharing the credential
The issued credential/s are sent and stored in Samantha’s wallet. On each credential, she can see:
- Indications for usage patterns they are most suited for.
- Trust marks indicating whether the credential had been issued by a trusted issuer.
Triggering downstream workflows
MATTR VII can configure a Webhook to send an event payload to subscribers whenever a credential is issued. This payload includes the wallet DID, the credential and other associated meta-data.
This is an optional step that can support and facilitate future user interactions.
The issuer stores Samantha’s wallet DID against her user profile for future interactions (e.g. offering another credential, update/re-issue a previously issued credential etc.)
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.