Skip to main content

Wallets

Learn how to hold and use credentials.

This page explains the basics of using Procivis One as a wallet to recieve credentials and make presentations.

Types of wallets​

The system enables two basic types of wallets: mobile and organizational.

Mobile wallets​

Use the SDK to build a wallet for mobile devices.

Related guide: SDK reference

Organizational wallets​

Use the Desk to build a server-based wallet for an organization. The workflows for issuance and presentation in an organizational wallet are largely the same as with mobile devices. The key differences:

  • Proximity-based flows are unavailable: server-based wallets do not support the transport protocols, such as Bluetooth Low Energy (BLE), required for proximity-based flows.
  • Permissions management is required: mobile devices are presumed to have one owner, so permissions do not need management. By contrast, organizational wallets require careful consideration of permissions. The Desk adds the required layer of user permissions to the Core functionality.

Wallet workflow​

The workflows for issuance and presentation follow a general pattern:

Related guides:

Interaction endpoints​

Wallet operations

Use the interaction endpoints as the primary tools to receive credentials and share presentations.

transport array​

For mobile wallets with multiple transport protocols enabled, use the transport array of handleInvitation to specify which transport protocol should be used. Together with the order of transport protocols in the configuration, the array enables dynamic protocol choice.

The table below describes how the system uses the array and the configuration to determine which transport protocol to use. The table assumes the values being passed are supported. See the supportedTransports capability of the verificationProtocol object of the configuration for supported transport protocols.

transport array valueSystem action
[]Of available transports from the configuration, uses highest order
[one value]Uses the specified transport
[multiple values]Following the order from the configuration, uses first supported transport found

Related guide: Transport order configuration

Issuer notification​

Some issuers using OpenID4VCI send an optional notification_id during credential issuance. This enables wallets to send an update informing the issuer what happened with the offer. This feature has privacy implications since the wallet must accept the credential offer — sending unique identifiers back to the issuer — before it can send the notification. If the wallet holder rejects the credential offer they may not want the issuer to possess potentially correlatable unique identifiers.

In order to preserve privacy, the system can generate temporary identifiers automatically to use for rejection. When enabled and the wallet user rejects an offer, the system generates a key pair and a DID and "accepts" the offer before sending notice of credential deletion. The key pair and DID are not stored in the database and not used for further interactions.

To enable this feature, configure the key algorithm and DID method used for generating temporary identifiers:

issuanceProtocol:
  { { INSTANCE_NAME } }:
    params:
      private:
        rejectionIdentifier:
          didMethod: KEY        // Reference the configured instance name
          keyAlgorithm: ECDSA   // Reference the configured instance name

If this is not enabled in the configuration the wallet will be unable to send a rejection notice to the issuer and calls to the reject endpoint will return an error.

You can confirm this ability to reject an issuance by checking the capabilities of your issuance protocol for feature.SUPPORTS_REJECTION.