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
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 value | System 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
.