Issuance Processes

Description of the possible integration flows implemented by the client

How can a Verifiable Credential be issued?

Any process designed to issue a Verifiable Credential must contain always the same 3 subprocesses to guarantee that the credential is correctly issued:

• Subject identification: That is, validating the identity of the real person (or legal entity)

• Subject and holder binding: Ensuring that the user that has been identified is the rightful holder of the wallet

• Claim assertion: retrieving the information and formatting and signing it adequately

However, a process may be very different depending on a number of factors:

• the assertions performed by the issuer:

  • remote or in-person

  • automatized or human-validated

  • additional validations

  • anti-fraud mechanisms performed

• the different claims contained on the credential

  • the type of information: the media-type, if it's sensitive or not, if it is understandable in other contexts or systems...

  • the source of the information: another credential, an existing linked account, a physical document...

  • the mode of retrieval: manual input, integration with existing services or APIs, automatizations...

• the process of identifying the person as the holder of the wallet

  • Validating he has other credentials to a DID matching known information

  • Demonstrating possession of a DID key

  • Ensuring the holder wallet uses a trusted software

That process may vary also depending on the business context or the legal framework (e.g.: eIDAS 2) under which the credentials are issued.

It is always the issuer - that is, the client application integrated with Studio - who is in charge of correctly designing and implementing that flow according to his own requirements.

Depending on how you want to implement this processes and integrate them into your use case, we support different issuance flows.

Supported flows

Wallet-Authenticated flow

This is the recommended and most common and generic flow for any use case.

This process consists on the same 3 steps:

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

2. The subject provides the information requested on the id_token allowing both his identification and his binding as the holder to the wallet

3. The client application sends the appropriate information to fill the credentials, which are retrieved by the subject

There are 3 other subdivisions of the flows, depending if it's:

1. Wallet-initiated vs. Server-initiated: if it is the server who creates a specific session to issue this credential or the wallet can do it by scanning a static unique QR for the whole flow.

   Default: Server-initiated

2. DID-Authentication or Verifiable Presentation Authentication: if the user shares only proof of possession of his did or shares additionally other verifiable credentials allowing a more profound authentication.

   Default: Server-initiated

3. Automatic or Deferred issuance: if the credentials will be filled automatically after the subject is authenticated or if there is a time consuming (probably with human validation) operation required to fill the credentials

   Default: Deferred Issuance

The default examples on the documentation will always rely on the default configuration, representing a Wallet-Authenticated flow which is Server Initiated, relying on Verifiable Presentation Authentication and issued Deferred.

Pre-authorized flow

This flow is intended for a process in which the user authentication has been performed on an external process, such as a form or previous account creation in an online service or him performing a bureaucratic process physically in an office.

The issuer must know the DID to which he wants to issue a credential, and will require to provide the user with 2 things:

1. A PIN Code that can be provided in person, via email, via sms...

2. A QR or Deep Link to scan with the wallet

Instead of sharing credentials or authenticating his DID, the user would just need to introduce the received PIN Code. The wallet will use his DID at that moment to ensure that the subject is correctly bound to the holder.

As with the wallet authenticated flow, the issuance of the credentials, after the validation of the PIN Code, could be either automatic or deferred.

Direct flow (coming soon)

The direct flow is one in which the issuer wants to issue a credential to a subject directly, without any interaction from his side. For that, the issuer just needs to know the DID of the subject and the information. He will issue the credential for that Holder, which will be notified via notification to retrieve his credential; without having receive any offer or provide any information.

This flow is only intended for cases where the issuer already knows and tracks in his systems the holders identity, possibly because he has already issued credentials to him.