Civitas ID White Paper White paper version 3.0 · 30 October 2026
All pages

Credential formats and exchange protocols

From the white paper: sections 2.3 and 4.7 say Civitas deploys existing standards rather than writing new ones, and is moving its credential formats and exchange protocols to the W3C Verifiable Credentials data model and the OpenID protocols; this page names those standards and states exactly which of them have code today.

The rail in service today. The credentials the platform issues and verifies today use the AnonCreds scheme over a Hyperledger Indy ledger Live. Exchange runs over the platform's own REST protocol, secured with the same cryptography: it is not DIDComm and not an OpenID flow. This is an earlier-generation self-sovereign identity stack, but it is not a capability gap. Selective disclosure works: a holder presents only the attributes a verifier asks for, and consents on the device to every presentation Live. Zero-knowledge predicates work: a verifier can require that a holder is over eighteen and receive a proof of that fact alone, without the date of birth Live. Revocation works end to end: an issuer can withdraw a credential, and a verifier receives proof at presentation that a presented credential has not been withdrawn Live. What the current rail lacks is reach, not function. A credential issued on it can be read only by a verifier connected to the same platform, because neither the format nor the exchange protocol is the one the rest of the field is converging on. The one standards-facing path in service is a W3C JSON-LD rail under a single signature type: an issuing interface that signs JSON-LD credentials, and an export of issued credentials into that form. It carries no exchange protocol, and it is removed together with the current rail.

The target profile. The migration replaces both the credential format and the exchange layer with a published standards profile. None of the following has shipped code Research: no implementation of any item in this list exists in the stack:

Institutional identifiers. Institutions get did:webvh identifiers: did:web extended with a verifiable, tamper-evident key history, so a controller cannot silently replace its DID document. Institutional issuers are already recorded under did:webvh identifiers in the trust registry contract deployed on the Stellar test network In build: on the test network, with no mainnet deployment and no mainnet date; mainnet waits on the audit of the next release of the OpenZeppelin contract library and on a key ceremony, rehearsed in advance, that places the governance keys with three separate holders. Each institution's key history is published as its DID log, kept off-chain on the institution's host: each service signs its own log, the platform stores only what it has verified against the complete log, and the log witness, an on-chain contract with no administrator and no upgrade path that records only which version of the log the institution stands behind, means a forged copy cannot pass as the genuine log without a public change on the ledger In build: live on the test network and wired to the production platform; every service with an active registry entry runs on a self-certifying identifier with an attested log, and a new service is created together with its log. Holders are different by design: they never get a published identifier. Each relationship with an institution uses its own pairwise identifier, created for that relationship and kept for its life, so a service recognises a returning holder, while the pairwise identifiers give two services nothing to match. The wallet also registers one device identity with the platform, not with any institution. How holders' keys work on the new formats is still to be decided.

Selective disclosure, and an open question about unlinkability. SD-JWT provides attribute-level selective disclosure with a simple, auditable structure. Its presentations are linkable across verifications by default, because the issuer's signature is re-presented unchanged each time. That is acceptable where a single verifier is involved, and it is not acceptable for a credential shown to many verifiers who could collude to build a composite profile. Two approaches to closing that gap are under research and neither is chosen Research: no implementation of either exists.

Approach one: an unlinkable signature scheme. A signature in the BBS+ family lets the holder present a fresh, unlinkable proof derived from one issued credential. It is the better-understood option and it needs a second credential profile alongside SD-JWT, with each credential type assigned to one of them in its schema definition. It also needs holder-side keys on a pairing-friendly curve that the secure elements of current mobile devices do not support, so those keys would be software-resident rather than enclave-backed and the first deployment has to document that key-storage tier rather than assume it.

Approach two: a zero-knowledge layer over SD-JWT. A zero-knowledge proof computed over the SD-JWT credential itself would bring unlinkability to the standard format with no second credential type and no second key curve, at the cost of proving work on the handset. Two reference implementations exist. Longfellow (Google) needs no trusted setup, is described in an individual Internet-Draft that the IRTF Crypto Forum Research Group has discussed but not adopted, and runs in production in Google Wallet for age assurance over mdoc credentials, with no production circuit for SD-JWT yet; it is the reference for this approach. Crescent (Microsoft Research) proves the same statement with Groth16, a proof system that a Soroban contract can verify on chain, but it is a research prototype and has not been audited. The choice between them is deferred; it turns on proof size, proving time and memory on the low-cost Android devices the target markets run on. The research register's current lean, drawn from published figures rather than measurements, is Longfellow as the primary route with a BBS+ profile beside it for credential types that must cross a QR code or NFC: a Longfellow proof runs to hundreds of kilobytes and its proving time on a low-cost phone extrapolates to several seconds, where a BBS+ proof is a few hundred bytes and tens of milliseconds. None of those numbers has been measured on real hardware yet; a one-engineer-day benchmark on two or three low-cost Android phones has been proposed and has no date yet, and this page will cite the measurement once it exists.

Threshold claims in the interim. Threshold conditions, such as proving that an age or an income qualifies without revealing the figure, are answered today by a zero-knowledge predicate on the current rail. On the new formats the interim answer is issuer-side attribute bucketing Research: not built: the issuer quantizes a sensitive value into predefined bands at issuance, and the holder discloses only the qualifying band at presentation. That reduces a range-proof requirement to a selective-disclosure operation SD-JWT supports directly. Native zero-knowledge predicates over the new formats ride on the same two candidate approaches as unlinkability, and are unmeasured for the same reason.

A staged migration, no flag day. The current rail keeps running while the standards stack is brought up beside it, and credential types move over as each format lands; users see no switch-over day. Two production capabilities must be reproduced on the new rail before the old one can be retired: zero-knowledge threshold proofs, and end-to-end revocation, which on the new formats takes the form of status-list revocation Research: one status bit array per credential type, published as an IETF Token Status List and as a W3C Bitstring Status List and signed with the service's issuing key; no status-list code exists yet. The first standards-compliant release is planned for early 2027, and the open-source release of the stack is planned for the first half of 2027.

Status, 2026-10-01: issuance, selective disclosure, zero-knowledge predicates and revocation all run in production on the AnonCreds rail over Hyperledger Indy; of the target profile, only the institutional identifiers exist: the did:webvh registry entries on the test network and the institutions' own DID logs, attested in the log witness on the test network; no code has shipped for W3C VC 2.0, SD-JWT, either unlinkability approach, OID4VCI/OID4VP, DCQL or status-list revocation.