What do I need to issue a verifiable credential?

An issuer identity with signing keys (often a did:web), a credential schema, a signing library for your chosen format such as SD-JWT VC, and an issuance protocol, typically OpenID4VCI, to deliver the credential to a wallet.

Which verifiable credential format should I use?

SD-JWT VC is the pragmatic default in 2026 because it is favored by eIDAS 2.0 and the IETF and is well supported. Use W3C Data Integrity with BBS signatures when you need unlinkable selective disclosure, and AnonCreds only inside ecosystems that already standardize on it.

How does credential revocation work?

The issuer publishes status, commonly a status list the verifier can check, or uses a revocation registry or cryptographic accumulator. The verifier checks status at presentation time without contacting the issuer directly.

How do verifiers know which issuers to trust?

Through a trust registry or trust framework that lists which issuers may issue which credentials. Without one, verifiers fall back to manually configured issuer allowlists, which do not scale.

Verifiable Credentials Implementation Guide

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 and the Verifiable Credentials standard.

Pick your role first

You are implementing one or more of the 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 is the pragmatic default: JWT-based, supported broadly, and favored by eIDAS 2.0. Choose W3C VC with Data Integrity and BBS signatures when you need unlinkable selective disclosure. Consider AnonCreds only inside ecosystems already built on it.
Transport protocol. OpenID4VC is the answer for most: OpenID4VCI for issuance, 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 anchored to a domain you control is the right balance of standards compliance and operational simplicity, no ledger required. See 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 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 and a governance framework such as Trust over IP. Decide how your verifiers will learn which issuers are authoritative before you go past a pilot.

A staged rollout

Verifier pilot: accept one credential type from one issuer for one flow (for example, a reusable proof at onboarding). Prove the plumbing.
Add issuance if you own credentials worth making portable.
Formalize trust with a registry and a documented governance model.
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. KYC angle: reusable identity and KYC. Vendors: decentralized identity directory and best platforms.