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.

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

Direct CWT issuance journey pattern 1

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.

Direct CWT issuance journey pattern 2

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.

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).