kunji

FOR DEVELOPERS

Verified credentials

Beyond anonymous sign-in, an app can issue a credential to a user and later verify a fact from it — selective disclosure, holder-bound, and unlinkable: the issuer never learns where the holder presents it. kunji speaks the standard rails — OpenID4VCI for issuance, OpenID4VP for presentation, over IETF SD-JWT VC — so it interoperates with the wider wallet ecosystem.

Try it live

Get a demo age credential into your kunji wallet, then prove age_over_18 from it — nothing else is revealed.

Open the live demo → Get the wallet

Issuance — OpenID4VCI

Your issuer mints an SD-JWT VC bound to the holder's key and offers it via an openid-credential-offer:// link (QR or deep link). The wallet redeems the pre-authorized code, sends a holder proof-of-possession, and stores the credential. Predicate pre-baking keeps it minimal — issue age_over_18: true, never a date of birth, so disclosing it leaks the answer, not the birthday. The issuer publishes its keys at /.well-known/kunji-issuer.json (the verifier's trust anchor — HTTPS, not kunji).

Presentation — OpenID4VP

Your verifier publishes a signed request (a JAR verified against its /.well-known/kunji-verifier.json key — the HTTPS-anchored client_id scheme, so the wallet shows a cryptographically-proven requester) asking for exactly the claim you need via DCQL. The wallet builds a vp_token bound to your client_id + nonce and posts it straight back to your response_uri — no kunji backend in the path. You verify it locally against the issuer's published keys + StatusList.

Standards & interop

  • OpenID4VCI — pre-authorized_code and authorization_code + PKCE (S256).
  • OpenID4VP — direct_post, signed (JAR) requests, request_uri by-reference, and an encrypted response (direct_post.jwt, ECDH-ES / A256GCM).
  • DCQL + presentation_definition queries; selective disclosure per claim.
  • SD-JWT VC (EdDSA) — accepts both vc+sd-jwt and the renamed dc+sd-jwt. Plus an unlinkable BBS (vc+bbs) format with holder binding.
  • DPoP (RFC 9449) sender-constrains the issuance token.
  • client_id schemes — HTTPS-anchored .well-known (default), did:web / did:jwk, and x509_san_dns (a scoped cert profile — see the docs for the trust boundary).

Full protocol notes live in docs/oid4vc.md and verified-credentials.md. The demo issuer mints to anyone for the demo — a real issuer authenticates the subject first.

← Back to the guide