#Intro Silent Issuance & Verification

The wallet service is designed with flexibility in mind — both in terms of the types of wallets it supports (e.g., organizational or personal) and how credential exchanges are handled. While most implementations involve user-facing flows (like scanning a QR code or clicking a link), the Wallet API also supports fully programmatic interactions.

This allows developers to implement silent issuance and verification — credential exchanges that happen in the background, without requiring real-time user input.

Because the Wallet API doesn’t enforce assumptions about how it’s used, you’re free to integrate it into any architecture: from mobile apps to enterprise middleware and custom orchestration layers.

The goal of this implementation is to consider credential exchange flows with a UX-first approach, especially when considering the long term scalability of the wallet interactions as users start collecting more and more credentials.

Having to accept or reject each credential explicitly, or having to scroll through many valid credentials for a presentation request and selecting the correct ones with the right disclosures is a highly frictional experience that the average user will not tolerate.

#What Are Silent Flows?

Silent flows allow credentials to be issued or verified without immediate user interaction. Instead of asking the user to scan a QR code or manually accept an offer by clicking a link, the process happens asynchronously and programmatically — in the background.

There are two supported flows:

• Silent Issuance – Credentials are pushed directly into a wallet.
• Silent Verification – Credential data is shared automatically.

This is done simply by pushing the openid credential offer or presentation request URL to the wallet service API.

#Common Concerns & How To Address Them

#Challenge 1: Spam or unwanted credentials?

Use:

• Trust lists to block untrusted issuers
• Metadata flags like "pending": true to show credentials in a review UI (metadata body parameter in receive credential endpoint)

#Challenge 2: What if the user doesn’t want the credential?

Users can accept/reject pending credentials at a later time in the wallet UI.

#Challenge 3: Does this violate consent-first data sharing?

Silent verification respects consent through:

• Local holder policies for setting granular sharing rules
• Build first-time prompts to guide configuration

#Challenge 4: How can verifiers ensure correct data?

• Use Presentation Definitions (DIF)
• Digital Credentials Query Language (DCQL) – regex-like filtering for credentials

#Challenge 5: How do I deliver OpenID links to the wallet?

Use the REST APIs in the enterprise stack. You can:

• Call the wallet service directly via API
• Add a communication layer (e.g., internal relay)
• For decentralized delivery, expose the endpoint via the DIDDoc