Issuing verifiable credentials means running a signing service, a revocation service and a trust relationship with wallets you do not control, and most of the risk sits in those operations rather than in the issuance screen a vendor demonstrates. This vendor-neutral buyer's guide is for organisations that will issue credentials: universities issuing diplomas, employers issuing staff or role credentials, public bodies and qualified trust service providers issuing attestations of attributes under eIDAS 2, and firms issuing credentials to partners, devices or software agents. It covers formats, the OpenID4VCI issuance protocol, status and revocation, wallet support, key protection and conformance. Organisations that mainly need to accept wallets should start with the Digital Identity Wallet and Verifiable Credentials buyer's guide, which covers verifier selection; the concepts themselves are explained in the Verifiable Credentials Guide. Standards status on this page was checked on 8 November 2026.
Key takeaways
- Pick formats by ecosystem, not by preference: EU wallet ecosystems use SD-JWT VC and ISO mdoc, while W3C VC Data Model 2.0 credentials suit ecosystems built on Data Integrity or JOSE and COSE securing; many issuers need more than one.
- Know which standards are final: OpenID4VCI 1.0 and the W3C VC 2.0 family are final, but SD-JWT VC and the IETF Token Status List were still Internet-Drafts on 8 November 2026, so ask how the vendor will absorb late changes.
- The issuer signing key is the crown jewel: anyone who can use it can mint credentials every verifier will trust, so HSM-backed keys, separation of duties and signing logs are mandatory.
- Revocation is an operational service: status lists must be published, cached, kept available and sized for privacy for as long as any credential is valid.
- Test against wallets you do not own: issuance that only works with the vendor's own wallet is lock-in, not interoperability.
Define requirements
- Credential portfolio: each credential type, its attributes, validity period, expected volume per year and the population that holds it. Separate person credentials from credentials for organisations, devices or agents.
- Ecosystem and legal role: whether you issue person identification data, qualified or public-body electronic attestations of attributes, or non-qualified credentials, and which rulebooks apply. See the eIDAS 2.0 and the European Digital Identity Framework Guide and the eIDAS Qualified Trust Services Guide.
- Formats: SD-JWT VC (media type
application/dc+sd-jwt), ISO/IEC 18013-5 mdoc for mobile driving licences and similar, W3C VC 2.0 secured with Data Integrity or VC-JOSE-COSE. - Proofing and authentication before issuance: how the holder is identified (existing account, in-person check, identity verification service) and which OpenID4VCI flow fits: authorisation code for a logged-in user, pre-authorised code with a transaction code for an offline or in-person journey.
- Issuer identity and trust: X.509 certificates under a trust list, DIDs, or both; who certifies your issuer status. See the Decentralised identifiers (DIDs) guide.
- Lifecycle: re-issuance on attribute change, suspension, revocation, batch issuance for unlinkability, and retention of issuance records.
- Deployment: SaaS, private cloud or on premises; HSM or cloud KMS; data residency; integration with your system of record and identity provider.
Capability areas
| Area | What to look for |
|---|---|
| Issuance protocol | OpenID4VCI 1.0 (Final): issuer metadata at .well-known/openid-credential-issuer, credential offers by value or reference, authorisation code and pre-authorised code flows, nonce endpoint, deferred issuance, notification events, batch issuance |
| High assurance profile | OpenID4VC High Assurance Interoperability Profile (HAIP) 1.0 support where your ecosystem requires it: wallet attestation, key attestation, PKCE S256, PAR and DPoP |
| Formats and schemas | SD-JWT VC with selective disclosure per RFC 9901, mdoc, W3C VC 2.0; schema and type metadata management; versioning of credential types without breaking held credentials |
| Holder key binding | Validation of key proofs (openid4vci-proof+jwt), rejection of none and MAC algorithms, nonce and audience checks, policy on accepted key attestations |
| Status and revocation | IETF Token Status List (VALID, INVALID, SUSPENDED) for SD-JWT VC and mdoc ecosystems, W3C Bitstring Status List for VC 2.0, random index allocation, published list availability and caching headers |
| Signing key management | Keys generated and used inside an HSM or cloud KMS, separate keys per credential type or environment, rotation with overlap, dual control for key ceremonies, a log of every signature. See the HSM Deployment and Operations Guide |
| Trust publication | Issuer certificates or DID documents, signed issuer metadata, registration in the relevant trust lists or registries, expiry monitoring |
| Integration | APIs or connectors to the system of record, identity provider and identity verification service, with attributes mapped, not copied, into the platform |
| Data protection | Minimal retention of issued attribute values, records of issuance kept for audit, deletion workflows, no tracking of where credentials are presented |
Evaluation criteria
| Criterion | Illustrative weight | How to evidence it |
|---|---|---|
| Protocol and format conformance | 20% | Exact versions implemented, conformance or interoperability test results, issuance to independent wallets in the proof of concept |
| Signing key protection | 20% | HSM or KMS architecture, certification level of the key store, key ceremony procedure, access model for vendor staff |
| Status and lifecycle | 15% | Revocation and suspension visible to a verifier within an agreed time, list size and privacy settings, availability commitment for status endpoints |
| Issuance security | 15% | Single-use, short-lived pre-authorised codes, transaction code attempt limits, proof replay protection, wallet attestation checks where required |
| Integration and operations | 10% | Time to issue one credential type end to end, API quality, monitoring and alerting |
| Change readiness | 10% | How drafts moving to RFC and new rulebook versions are handled, with upgrade commitments in the contract |
| Commercials and exit | 10% | Pricing metric (credentials issued, active credentials, status checks), key and data export, continuity of status lists after exit |
A university issuing tens of thousands of diplomas a year will weight lifecycle and wallet reach higher; a qualified trust service provider will weight key protection, audit evidence and rulebook compliance highest. Small issuers can accept a SaaS platform with a cloud HSM; large or regulated issuers often need keys in their own HSM.
Questions to ask vendors
- Which versions of OpenID4VCI, HAIP, SD-JWT VC and Token Status List do you implement today, and how did you handle the last breaking change in a draft?
- Where are our issuer signing keys generated and stored, can they ever leave the key store, and which of your staff can trigger a signature?
- Show the log entry for a single issued credential: who requested it, which attributes, which key, which holder key was bound.
- How long are pre-authorised codes valid, are they single use, and how many wrong transaction codes are allowed before the offer is invalidated?
- After we revoke a credential, how soon will a verifier caching your status list see it, and what is the availability target for the status endpoint?
- How are status indexes allocated, what is the minimum list size, and how do you avoid list updates revealing which holder changed?
- Which independent wallets have received credentials from your platform, in which formats, and can we see the test evidence?
- If we leave, can we export keys or rotate to our own keys without re-issuing every credential, and who keeps the status lists running?
- Can the platform issue credentials to organisations, devices or software agents as well as people, with the same key and status controls?
Red flags
- "Supports OpenID4VC" with no version numbers, or only implementer's drafts that predate OpenID4VCI 1.0.
- Issuer keys stored in application configuration or a database, or one key shared across all credential types and environments.
- Revocation described as "delete the record", with no published status list or no availability commitment.
- Status lists far smaller than the W3C Bitstring Status List minimum of 131,072 entries, or sequential index allocation.
- Pre-authorised codes that are reusable, long lived or sent without a transaction code for sensitive credentials.
- Issuance demonstrated only into the vendor's own wallet.
- Telemetry that records where holders present credentials.
- No answer on what happens to status lists, and so to every credential you issued, if the contract ends.
Proof of concept
- Pick two credential types, one person credential and one organisational or device credential, and define attributes, validity and the issuance journey for each.
- Generate issuer keys in your HSM or KMS tenant, publish issuer metadata and certificates or a DID document in a test trust list.
- Issue each credential through OpenID4VCI using both the authorisation code flow and a pre-authorised code with a transaction code, into at least two independent wallets and both target formats.
- Run negative tests: a replayed key proof, a proof with the wrong audience or nonce, a reused pre-authorised code, repeated wrong transaction codes and an expired offer. All must fail and be logged.
- Suspend, reinstate and revoke a credential, and measure how long a test verifier takes to see each change. Inspect list size and index allocation.
- Rotate the signing key and confirm previously issued credentials still verify while new ones use the new key.
- Review the audit log and data store against your retention policy, then price three years at your expected volumes, including status hosting after exit.
Standards and references
- OpenID Foundation: OpenID for Verifiable Credential Issuance 1.0
- OpenID Foundation: OpenID4VC High Assurance Interoperability Profile 1.0
- W3C: Verifiable Credentials Data Model v2.0
- W3C: Bitstring Status List v1.0
- IETF: SD-JWT-based Verifiable Credentials (Internet-Draft)
- IETF: Token Status List (Internet-Draft)
- ISO: ISO/IEC 18013-5 Mobile driving licence (mDL) application
How NHI Mgmt Group can help
We provide independent requirements, RFP and evaluation support for credential issuers, including the signing keys, status services and machine credentials these platforms depend on. Browse vendors in our products directory or contact us.
Related NHI Mgmt Group resources: Verifiable Credentials Guide · OpenID for Verifiable Credential Issuance Guide · Digital Identity Wallet and Verifiable Credentials · Mobile Driving Licence (mDL) Guide · Cryptographic Key Management Guide