Trust, without the data hoarding.
CredMesh is a verifiable credential platform that issues and verifies selective disclosure credentials—so users can prove what matters and keep everything else private.
Everything you need to ship VC-based trust
CredMesh supports issuance, presentation verification, and credential status checks as first-class, interoperable building blocks.
Interoperable issuance
Serve issuer metadata, credential offers, token exchange, nonce issuance, and proof validation—wired for OpenID4VCI.
Selective disclosure by default
Issue SD‑JWT VCs that reveal only what the verifier asks for. Verify disclosures and holder-binding deterministically.
Status at scale
Integrate Bitstring Status Lists for revocation/suspension at massive cardinality— without per-credential lookups.
Formats you can mix
Start with SD‑JWT (fast interop) and add ISO mdoc when you need device-authenticated presentations.
- dc+sd-jwt for day-one VC issuance and verification
- mso_mdoc for device-authenticated presentations
- Holder binding via cnf.jwk or cnf.kid
Built for production realities
Multi-replica safe flows, structured logs, and a conformance suite that keeps you honest as you evolve.
- Deterministic fixtures + negative tests for every flow
- Audit trails, correlation IDs, safe error surfaces
- Status checks with cache + freshness control
How it works
A clean pipeline from evidence → credential → privacy-preserving proofs—designed to be testable and observable at every hop.
Issue
Wallet receives a credential offer, redeems a grant, gets a nonce, and sends a proof JWT. Issuer returns dc+sd-jwt (or mso_mdoc).
Present
Wallet discloses only required attributes and binds the presentation to a verifier challenge (nonce) using holder key material.
Verify + check status
Verifier validates signatures, disclosure digests, key binding, and status list bits. You receive a structured decision for your policy engine.
Security you don’t have to bolt on later
CredMesh assumes the network is hostile. Every externally supplied value is validated, and every critical decision is auditable.
Strict protocol validation
Proof JWT checks, nonce lifetimes, replay protection, and exact audience matching— backed by fixtures and tamper tests.
Audit trails
Every issuance and verification can emit stable event codes and correlation IDs, so you can trace decisions end-to-end.
Privacy posture
Selective disclosure reduces data collection. Use short-lived tokens, avoid storing PII, and keep secrets in KMS—not in code.
Developer experience that stays fast
Strong primitives are great—until your next PR breaks interop. CredMesh prioritizes conformance automation so your implementation remains predictable.
Drop-in building blocks
Use the protocol packages directly or call the HTTP services. Add new credential types with fixtures and tests, not heroics.
- Issuer + verifier services with stable APIs
- Wallet SDK for harnesses and demos
- Golden fixtures to prevent regressions
import { verifyAuthorizationResponse } from "@credmesh/protocols-oid4vp";
const result = await verifyAuthorizationResponse({
request, // stored auth request
expectedNonce: request.nonce,
expectedState: request.state,
presentationVerifiers: [
{ format: "dc+sd-jwt", verification: sdJwtVerifier },
{ format: "mso_mdoc", verification: mdocVerifier },
],
statusList: { requireStatus: true },
});
if (!result.ok) throw new Error(result.reasons.join(", "));
console.log(result.presentations[0]?.claims);Tip: keep the decision object stable so downstream policy engines can safely consume it.
FAQ
Practical answers for teams building with digital credentials.
Do I need ISO mdoc on day one?
No—most teams start with SD‑JWT VCs for speed and interop. Add mdocs only when you need device-authenticated presentations or wallet requirements demand it.
How does revocation work at scale?
CredMesh supports bitstring-based status lists: credentials include a
statusListCredential URL and an index; verifiers resolve the list,
decompress the bitstring, and read the bit at that index.
Can I self-host?
Yes. The services are designed to be stateless and run behind a load balancer with a shared database. Prefer KMS-managed signing keys and audit everything.
What do verifiers get back?
A structured decision: pass/fail, reason codes, extracted disclosures/claims, and an audit reference—so your policy engine has clean, deterministic inputs.
Ready to ship privacy-preserving trust?
Start local, run conformance, then deploy with confidence. If you want to integrate CredMesh into your product, wire the decision output into your policy engine and keep the rest of your stack blissfully unaware.