Issuance Process

Overview of integration flows available for client implementation.

How can a Verifiable Credential be issued?

Any process designed to issue a Verifiable Credential must include three core subprocesses to ensure the credential is issued correctly:

1. Subject Identification Validate the identity of the real person or legal entity.

2. Subject and Holder Binding Ensure that the identified user is the rightful holder of the wallet.

3. Claim Assertion Retrieve the necessary information, format it correctly, and sign it.

Variations in the Issuance Process

The issuance process can vary based on several factors:

• Issuer assertions:

  • Remote or in-person

  • Automated or human-validated

  • Additional validations or anti-fraud checks

• Credential content:

  • Type of information (media type, sensitivity, compatibility with other systems)

  • Source of information (another credential, linked account, physical document)

  • Mode of retrieval (manual input, service/API integration, automated process)

• Holder verification:

  • Validating possession of other credentials or a DID

  • Demonstrating possession of a DID key

  • Ensuring the holder uses trusted wallet software

• Business or legal context: Processes may also vary depending on the regulatory framework, e.g., eIDAS 2.

The issuer (the client application integrated with Studio) is responsible for designing and implementing the flow according to their requirements.

Supported Issuance Flows

Depending on your use case, we support different issuance flows:

Wallet-Authenticated Flow (Recommended)

This is the most common flow. It follows the same three steps:

1. The subject scans a QR code with their wallet containing a credential offer.

2. The subject provides the requested information on the id_token, enabling both identification and wallet-holder binding.

3. The client application sends the necessary information to complete the credential, which the subject retrieves.

Flow Variations:

• Wallet-initiated vs. Server-initiated

  • Server-initiated: The server creates the session for issuing the credential (default).

  • Wallet-initiated: The wallet starts the session by scanning a static QR.

• DID-Authentication vs. Verifiable Presentation Authentication

  • DID-Authentication: The user shares only proof of possession of their DID. This verifies the user controls the DID but does not include additional credentials.

  • Verifiable Presentation Authentication: The user shares their DID along with other verifiable credentials (default).

• Automatic vs. Deferred Issuance

  • Automatic: Credentials are filled automatically after authentication.

  • Deferred: Credentials may require longer processing, such as human validation (default).

All default examples in the documentation use the Wallet-Authenticated flow, Server-Initiated, Verifiable Presentation Authentication, with Deferred Issuance.

Pre-Authorized Flow

This flow is for cases where the user has already been authenticated externally, such as:

• Filling a form

• Previous account creation

• In-person bureaucratic process

Requirements for the issuer:

1. Know the DID of the subject.

2. Provide the subject with:

   • A PIN code (sent in person, email, SMS, etc.)

   • A QR code or deep link to scan with the wallet

The user simply enters the PIN in the wallet. The wallet then ensures the subject is bound to the holder. Credential issuance can be automatic or deferred.

Direct Flow (Coming soon)

The Direct Flow allows the issuer to issue a credential without any user interaction.

• The issuer must know the subject’s DID and credential information.

• The credential is issued directly, and the holder receives a notification to retrieve it.

• Intended for cases where the issuer already knows and tracks the holder’s identity (e.g., previous credentials issued).