Direct issuance journey pattern
In this journey pattern a direct API request is made to sign a provided payload as a digital credential, and then share it with its intended holder.
JSON credentials
- Issuance channel: Remote, Unsupervised
- Device/s: On-device / Cross-device
- Formats: JSON
- Information assurance level: High
- Identity assurance level: Low
Journey flow
Logging into an online portal
Samantha logs into her existing online portal.
Claiming a credential
Inside the portal she is presented with an option to claim a digital credential by sharing her unique wallet identifier.
She can do this either by entering it manually or scanning the presented QR code with her digital wallet.
Credential issuance
Upon sharing her wallet identifier, the credential is issued directly to her wallet.
The credential is pushed directly to Samantha’s wallet through a notification, and Samantha is prompted to accept the credential.
Accepting the credential
When Samantha is prompted to accept the credential, her wallet is checking that this Issuer is allowed to issue this type of credential in her current trust network.
This is an optional feature for trust network operators to increase the level of trust in the interaction.
Viewing the issued credential in the wallet
After accepting the credential, it is available in Samantha’s digital wallet.
Architecture
User Authentication
The Issuer’s own portal (1) is the starting point. As part of accessing the portal, the Issuer may have their own authentication provider (2) that is used to verify the identity of the user before providing them access to information and services.
Sharing the wallet identifier
Once authenticated, the portal can offer the user to directly claim a credential.
To allow the Issuer to issue a credential that is bound to the user’s wallet, a unique interaction identifier must be created by the user’s digital wallet and shared with the Issuer.
The digital wallet (3) has the ability to create the necessary identifier, that is cryptographically bound to the wallet. The user can share this identifier with the Issuer either by manually entering it or with the aid of a QR code-based authentication flow.
Compared to pattern 1, this approach carries a lower level of binding assurance. There isn’t the same opportunity to perform multiple authentication factors as part of the flow due to the credential provisioning being separated from the authentication flow.
Credential generation
Once the wallet identifier is obtained, the Issuer bundles the information related to the requesting user from their user data store (4).
The data is passed to the Credential Generation component (5) which formats, binds and signs the data into a credential that is ready to be sent to the requesting wallet/device.
Additional features may be enabled to support capabilities such as credential revocation or allowing the holder to respond to selective-disclosure verification requests.
Encrypting and sending the credential
The credential is then pushed through to the user’s wallet using MATTR VII’s secure messaging component (6) to encrypt the credential payload and send it directly to the wallet for the user to accept and store.
Accepting the credential
Digital trust service capabilities (7) 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 the credential from this Issuer.
Holding the credential
Digital wallets (3) can be used to manage the acceptance and secure storage of the credential for the user on their device once it is sent at the completion of the issuance flow (step 5 in the pattern above).
This can be achieved by wallets built with our MATTR Pi Wallet SDK or branded MATTR GO Hold applications.
Direct issuance journey pattern
In this method you make a direct API request to sign a provided payload as a digital credential, and then share it with its intended holder.
CWT credentials
- Issuance channel: Remote, Unsupervised
- Device/s: Cross-device
- Formats: CWT
- Information assurance level: High
- Identity assurance level: Low or High (with accompanying identification)
Journey flow
Receiving notification a credential is available
Samantha receives an email confirming the issuance of a credential that she can claim.
Unique access code
The email includes instructions along with a unique code that Samantha can use to claim a digital version of the credential into her digital wallet or device.
Providing identifying information
Samantha navigates to the provided website and enters the digital access code printed in the email, along with a piece of information that isn’t provided in the instructions, that only she would know
- like her date of birth.
Claiming the credential
Samantha is able to view the credential through the website and then select to save it as a:
- QR code.
- PDF document.
- Digital pass in her Google Pay pass, Apple Wallet pass or any 3rd party wallet.
Validating credential issuer
When Samantha is prompted to accept the credential, her wallet is checking that this Issuer is allowed to issue this type of credential in her current trust network.
This is an optional feature for network operators to increased the level of trust.
Viewing the credential in wallet
After accepting the credential, it is available in Samantha’s digital wallet.
Architecture
Logging into the portal
The Issuer’s portal (1) is the starting point. The portal could be accessed either directly by the user or some other form of digital journey that brings them to this step. Once authenticated in the portal, which could simply be through the entering of a link or piece of information, the Issuer can attempt to match the user to a record in the data store (2). The portal can then prompt the user to claim a credential.
Credential generation
The credential Issuer then retrieves and bundles the information relating to the requesting user from their own data source (2). The data is passed to the Credential Generation component (3) which formats and signs the data into a credential, ready to be shared with the user as a QR code, PDF or a digital pass. This step could include storing on a device/form of storage that doesn’t require the credential to be digitally bound to the user.
Bearer credentials
The only verifiable binding that can occur on this implementation pattern is between the credential and the Issuer, as there are no authentication or device binding attributes supplied to build into the credential.
Binding the user to the information can only occur by comparing the claims in the credential to another trusted information source (for example, comparing the details in the credential with another verifiable credential bound to the user’s device).