# Verifiable Credentials Implementation Guide

Source: https://startwithidentity.com/guides/decentralized-identity/verifiable-credentials-implementation-guide/
Last updated: 2026-07-06
License: content by Start with Identity. Cite the source URL.

---

This guide is for teams that have decided to build with verifiable credentials and need to know how the pieces fit. For the concept first, read [decentralized identity explained](https://startwithidentity.com/guides/decentralized-identity/decentralized-identity-explained/) and the [Verifiable Credentials standard](https://startwithidentity.com/standards/verifiable-credentials/).

## Pick your role first

You are implementing one or more of the [issuer, holder, verifier](https://startwithidentity.com/glossary/issuer-holder-verifier/) roles, and each has different work:

- **Issuer:** you sign credentials and deliver them to wallets. You need signing keys, a schema, and an issuance endpoint.
- **Verifier (relying party):** you request and check presentations. This is the most common starting point and the lowest lift.
- **Holder/wallet:** usually you integrate an existing wallet rather than build one, unless the wallet is your product.

Most enterprises start as a **verifier**, because you can accept credentials others issue without standing up issuance infrastructure.

## Choose formats and protocols

Two decisions shape everything downstream:

- **Credential format.** [SD-JWT VC](https://startwithidentity.com/standards/verifiable-credentials/) is the pragmatic default: JWT-based, supported broadly, and favored by [eIDAS 2.0](https://startwithidentity.com/standards/eidas-2-eudi-wallet/). Choose **W3C VC with Data Integrity and [BBS signatures](https://startwithidentity.com/glossary/bbs-signature/)** when you need unlinkable [selective disclosure](https://startwithidentity.com/glossary/selective-disclosure/). Consider [AnonCreds](https://startwithidentity.com/glossary/anoncreds/) only inside ecosystems already built on it.
- **Transport protocol.** [OpenID4VC](https://startwithidentity.com/standards/openid4vc/) is the answer for most: [OpenID4VCI](https://startwithidentity.com/glossary/openid4vci/) for issuance, [OpenID4VP](https://startwithidentity.com/glossary/openid4vp/) for presentation. It layers on OAuth, so you extend infrastructure you already know. Align to the HAIP profile if you need EU-wallet interoperability.

## Identifiers and keys

Issuers need a resolvable identifier so verifiers can fetch the signing key. For most, a [`did:web`](https://startwithidentity.com/standards/decentralized-identifiers-did/) anchored to a domain you control is the right balance of standards compliance and operational simplicity, no ledger required. See [DID methods compared](https://startwithidentity.com/guides/decentralized-identity/did-methods-compared/) for the tradeoffs. Treat issuer key management like any high-value signing key: hardware-backed, rotated, with a tested recovery plan.

## Revocation and status

A credential outlives its issuance, so verifiers must be able to tell whether it is still valid. Publish status through a [revocation registry](https://startwithidentity.com/glossary/revocation-registry/) or status list. Design this early; retrofitting revocation is painful.

## Trust: which issuers count

A signature proves a credential was not tampered with, not that you should trust who issued it. That is the job of a [trust registry](https://startwithidentity.com/glossary/trust-registry/) and a governance framework such as [Trust over IP](https://startwithidentity.com/glossary/trust-over-ip/). Decide how your verifiers will learn which issuers are authoritative before you go past a pilot.

## A staged rollout

1. **Verifier pilot:** accept one credential type from one issuer for one flow (for example, a reusable proof at onboarding). Prove the plumbing.
2. **Add issuance** if you own credentials worth making portable.
3. **Formalize trust** with a registry and a documented governance model.
4. **Scale formats and wallets** you accept as the ecosystem matures, keeping a non-credential fallback.

## Common mistakes

- Building issuance before you have a verifier that will accept the output.
- Picking a format your target wallets do not support.
- Treating revocation and trust governance as afterthoughts.
- Assuming a ledger is required. It usually is not.

## Where to go next

Vendor selection: [choosing a decentralized identity platform](https://startwithidentity.com/guides/decentralized-identity/choosing-a-decentralized-identity-platform/). KYC angle: [reusable identity and KYC](https://startwithidentity.com/guides/decentralized-identity/reusable-identity-and-kyc-with-verifiable-credentials/). Vendors: [decentralized identity directory](https://startwithidentity.com/vendors/decentralized-identity/) and [best platforms](https://startwithidentity.com/rankings/best-decentralized-identity-platforms/).