Community
Technology Blog Posts by SAP
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 

In the era of Self-sovereign Identity (SIS), verifiable credentials (VCs) are becoming a cornerstone. Organizations and individuals can now issue, request, and present attestations  without relying on a central authority, enabled by emerging standards and protocols such as the Decentral Claims Protocol (DCP). This blog post explores two core ways VCs are transferred from an issuer wallet tenant to a holder wallet tenant using Decentralized Identity Verification (DIV) focusing on automation options available to both issuers and holders.

 

Two VC Transfer Patterns

With DCP, there are two main patterns for moving a verifiable credential from the issuer's environment to the holder's:

Holder-Initiated Credential Request

Holder requests VCs:

  • The holder launches their VC request app and picks the issuer from which they wish to request credentials.8_1.png
  • The app pulls published credential types (from the issuer's metadata endpoint), ensuring the holder can only request credentials the issuer offers. 
    8_2.png
     
  • The users selects the credential types to be requested
  • Next, the holder selects which identity to use (think multiple DIDs or personas in their wallet).
  • A request for the selected credential type(s), tied to the chosen identity, is dispatched to the issuer.

 

API to Request VCs

This feature can also be consumed via API, enabling deep integration into other applications and seamless automation of decentralized credential workflows.

POST {srv}/api/v2.0.0/dcp/requestCredentials/{app_name}
Content-Type: application/json
Authorization: Bearer {token}
{
  "requestedCredentials": [
    {
      "credentialType": "BpnCredential",
      "format": "vcdm11_jwt"
    }
  ],
  "issuerDid": "{issuerDID}",
  "holderDid": "{holderDID}"
}

 

Issuer processes credential requests:

The issuer receives the request in their inbox. They review, approve, and send back the requested VC(s) to the holder. Alternatively, they may have to first create the credential before sending it.

Automation Option: Issuers can preconfigure their wallet to auto-respond to requests - if the VC is already ready. However, if credentials are not yet generated, or if the holder requests a set of credentials where not all are available, manual intervention is required.

Holder receives VCs:

Once complete, the holder receives the VC, visible in the credential overview section of their admin app. 
8_3.png

8_4.png

 

API to Respond to VC Requests

This feature can also be consumed via API, enabling deep integration into other applications and seamless automation of decentralized credential workflows.

Issuer Get Received Credential Requests

GET {srv}/api/v2.0.0/dcp/credentialRequestsReceived
Content-Type: application/json
Authorization: Bearer {token}

 

Response to VC Request -> Send Response to Request

POST {srv}/api/v2.0.0/dcp/credentialRequestsReceived/{requestId}/send
Content-Type: application/json
Authorization: Bearer {token}

 

Issuer-Initiated Credential Offer

Sometimes, the issuer wants to proactively notify holders that a credential is available or due for a refresh (e.g., before expiration or after key rotation). This issuing pattern is essential for refreshing credentials (e.g., after expiration or key revocation) because the issuer can push a new offer seamlessly, keeping the holder's status up to date with minimal friction.

Issuer sends offer

The issuer navigates their app to the relevant issued VC, opens the action menu, and sends a credential offer to the selected holder. The offer notifies the holder that a credential is prepped for them and can be retrieved.
8_5 offer.png

Holder receives offer

The holder's wallet receives the offer. Here, behavior depends on their wallet's configuration:

  • Manual: The holder reviews the offer and chooses to make a credential request to receive it.
  • Automated: If the holder has marked the issuer as trusted with auto-accept enabled, the wallet will automatically convert the offer into a credential request and handle the entire transfer without manual clicks.

API to Offer VCs

This feature can also be consumed via API, enabling deep integration into other applications and seamless automation of decentralized credential workflows.

 

POST {div_wallet_srv}/api/v2.0.0/dcp/credentialOffers/send
Content-Type: application/json
Authorization: Bearer {token}
{
  "credentials": [
    "{vcId}"
  ]
}

 

Flexible Automation for Different Needs

A core strength of DIV is its support for both manual and automated flows. Depending on policy, user preference, and business process, any step on either issuer or holder side can be handled by a human or managed entirely by the wallet’s auto-configuration. In highly regulated or sensitive use-cases, both sides might want maximum manual review steps before issuing or accepting credentials. In high-scale, low-touch environments, the entire process can be embedded and fully automated.

 

Summary

Decentralized identity verification, enables seamless, secure transfer of verifiable credentials across wallet tenants. Whether initiated by holders seeking new credentials or by proactive issuers keeping credentials fresh, DCP allows maximum flexibility for both manual and automated workflows letting each participant tailor the process to their risk profile and user experience needs.

Read more

Comment
Labels in this area