Glossary

From the white paper: section 9 is the paper's glossary, and these pages mark maturity with three labels; this page defines both, term by term, with what Civitas actually runs today.

How to read the maturity labels. Three labels recur across these pages. Live means running today for real institutional users on the Civitas platform or wallet. In build means the work exists but has not reached its production form: the code runs against a test network, a sandbox or a pilot, or the release that would put it in users' hands has not shipped; every Civitas smart contract carries this label, since all run on the Stellar test network. Research means no shipped code. A specification is not code, and a demo is not production.

Credential formats and proof schemes

AnonCreds Live. A Hyperledger credential format built on Camenisch-Lysyanskaya signatures, with native zero-knowledge predicates and revocation proved at presentation. The format Civitas issues and verifies today over Hyperledger Indy, and the one the migration will replace.

BBS+ Research: one of two candidate approaches, no code. A signature scheme whose proofs are unlinkable: two presentations cannot be matched by cryptography alone, though disclosed attributes can still correlate. The alternative under research is a zero-knowledge layer over SD-JWT itself. Both are set out in the standards profile.

ISO mDoc / mDL Research: on the roadmap, no code. ISO/IEC 18013-5, the standard for mobile identity credentials, commonly mobile driving licenses. It uses CBOR and supports proximity presentation over NFC or QR. Support is on the roadmap for jurisdictions that issue mobile documents in that format.

JSON-LD. A JSON-based Linked Data format used in W3C Verifiable Credentials to make credential attributes machine-interpretable across systems. The platform also runs an older W3C JSON-LD rail beside AnonCreds: an interface that issues JSON-LD credentials under a single signature type, and an export of issued credentials into JSON-LD form. It is not an exchange protocol, and it is removed together with the current credential rail.

SD-JWT Research: target format, no code. Selective Disclosure JSON Web Token: a holder discloses individual attributes at presentation. It does not by itself stop verifiers linking presentations, which is why unlinkability is a research question of its own.

Verifiable Credential (VC). The W3C data model for a verifiable credential: claims about a subject, signed by an issuer, presented by a holder.

Verifiable Presentation (VP). One or more credentials, or proofs derived from them, packaged and signed by the holder for a verifier.

W3C VC Data Model 2.0. The second major W3C Verifiable Credentials specification (a W3C Recommendation since May 2025) and the first-release target, with VC 1.1 to be supported beside it. Its data model is not backward compatible with VC 1.1: it uses a new base context and renames issuanceDate and expirationDate to validFrom and validUntil, so supporting both versions means issuing or verifying each one explicitly.

Identifiers and DID methods

Attested resource. A document published under a DID, whose identifier includes the hash of its content and which carries a signature by a key its publisher's DID document lists; the pattern comes from the DIF DID Attested Resources draft specification. Civitas institutions publish their credential schemas this way In build.

DID. A decentralized identifier needing no central registration authority; it resolves to a DID Document.

DID Document. The machine-readable record behind a DID: authentication keys, service endpoints, metadata.

DID log. The did:webvh standard's term for an identifier's verifiable history: a file of log entries, one for each version of the DID document, each chained to the one before by a hash and signed by a key the log already authorizes, so no earlier version can be altered without detection.

did:webvh. A DID method extending did:web with verifiable, tamper-evident DID history. In the Civitas reference deployment on Stellar, each institution also records on the ledger which version of its DID log it stands behind, in the log witness contract In build.

Pairwise DID. A DID used for one relationship only, so identifiers cannot be correlated across relationships.

Self-certifying identifier (SCID). The part of a did:webvh identifier derived from the hash of the first entry of its DID log, which binds the identifier to that entry from the start.

Protocols and exchange standards

CBOR. A compact binary data format used by ISO mDoc credentials, especially suited to proximity presentation.

DCQL Research: target, no code. Digital Credentials Query Language: the language in which a verifier expresses its presentation request in OID4VP, replacing the earlier Presentation Exchange.

DIDComm. A DID-based messaging protocol for secure, private communication, used in some Aries self-sovereign identity systems. The platform does not use it: exchange today runs over the platform's own REST protocol.

OID4VCI Research: target, no code. OpenID for Verifiable Credential Issuance: the standard protocol for issuing credentials into a wallet.

OID4VP Research: target, no code. OpenID for Verifiable Presentations: the standard protocol for presenting wallet-held credentials, with requests expressed in DCQL, the Digital Credentials Query Language.

SEP-57 In build: Stellar test network. Stellar Ecosystem Proposal 57, still a draft: T-REX, the Stellar standard for regulated tokens. One of its parts is an identity-verifier interface for asking whether a Stellar account belongs to a verified party. The Civitas trust registry implements that interface through the OpenZeppelin stellar-contracts library, so any Stellar application can ask, from outside the platform, whether an account belongs to a recognized issuer.

SSI. Self-Sovereign Identity: people hold credentials in a personal wallet and control what they share and with whom.

Trust infrastructure and governance

CC BY 4.0. The Creative Commons Attribution 4.0 license: anyone may reuse and adapt the material, including commercially, provided the source is credited. The planned license for the Civitas governance and content frameworks; none is applied yet, with release planned for the first half of 2027.

Credential chain continuity. A person's verified history preserved as documentation changes, for example from asylum seeker to refugee to resident.

Ecosystem administrator. The entity governing a sub-network: admitting issuers and verifiers, managing registries, defining schemas; its rules form the governance framework. White-labeled sub-network administration runs on the platform today Live; jurisdiction-scoped registries and per-country governance under it are Research: designed, not built.

Fuzzy extraction Research: not built. Deriving a stable key from noisy biometric input without storing the biometric. The basis of the biometric recovery path under evaluation alongside the recovery phrase; see key management and recovery.

Goal path Research: engine not built. A step-by-step sequence of credential interactions that takes a person from a stated goal, such as getting a microloan, to its completion, showing what is missing and how to obtain it. The wallet already resolves one step, pointing a holder to the service that issues a missing credential Live; the engine that plans a whole path is not built. See goal-path orchestration.

Governance framework. The business, legal and technical rules for a credential ecosystem: who may issue or verify which credentials, under what conditions, and with what accountability.

Governance quorum In build: exercised on the Stellar test network. A governance-class change, such as revoking an issuer, needs more than one independent key holder's signature. The registry uses a two-of-three quorum, rehearsed end to end; the keys are not yet held by three separate holders, which deployment to the public Stellar network requires.

Holder. The person who owns credentials in a non-custodial wallet and authorizes every presentation. Holder binding ties a credential to the holder's key.

Holder binding. Cryptographic binding of a credential to the holder's public key, so that only the holder with the matching private key can present it.

Hyperledger Indy Live. The ledger the credential engine runs on today: public DIDs, schemas, revocation registries. Being replaced in stages by the Stellar trust layer and the target standards.

Issuance anchor Research: not deployed. A tamper-evident ledger record proving that a credential or batch of credentials was issued at a given time, planned as hashes of issued credentials batched under Merkle roots. One of the four contract types of the trust layer, and one of the two not built yet.

Issuer. An organization authorized to create and sign credentials after registration in the trust registry.

KYB / KYC. Know Your Business and Know Your Customer: due diligence on organizations before admission, and regulatory identity checks on individuals.

Log witness. A Civitas smart contract in which each institution records, from its own Stellar account, which version of its DID log it stands behind In build. The contract has no administrator and no upgrade path. The name is Civitas's own; it is distinct from the optional witness mechanism in the did:webvh standard, in which designated witnesses co-sign new log entries.

MEL. Monitoring, Evaluation and Learning.

MPL 2.0. The Mozilla Public License, version 2.0: file-level copyleft that allows commercial use alongside it. The planned license for the core; none is applied yet, with open-source release planned for the first half of 2027.

No Phone Home. Verifying a credential must not require contacting the issuer at presentation time.

Non-custodial wallet Live. Keys live on the holder's device, never with a third party. The launched wallet works this way; restoring it needs both the 24-word phrase and the encrypted backup. The backup is off until the holder turns it on.

Revocation registry. Records whether credentials remain valid, without exposing personal data. Issuers revoke today on the AnonCreds rail Live; the status-list registry for the new formats is Research: no code. Its target is one bit array per credential type, published both as an IETF Token Status List (for SD-JWT VC) and as a W3C Bitstring Status List (for the W3C forms), signed by the institution's issuing key and hosted off-chain; lists for credentials held by people never go on chain.

Schema publication In build: with the log witness on the Stellar test network. Publication of credential type definitions, including fields, attribute types and versioning. In the Civitas reference deployment a schema is an attested resource published off-chain under its publisher's own did:webvh identifier, signed with keys the publisher holds itself and listed in an index its DID document points to. It is immutable by construction, so a changed schema is a new resource, and a publisher can mark an older version as deprecated in the platform catalog. See schema publication.

Sub-network. A geographic or institutional ecosystem with its own administrator and rules. White-labeled sub-networks run on the platform today Live and share one trust registry; jurisdiction-scoped registries are not built.

Token Status List Research: target, no code. The IETF status-list format for SD-JWT VC credentials, carrying the same bits as the W3C Bitstring Status List.

Trust registry In build: Stellar test network. The on-chain record of recognized credential issuers: a Soroban contract integrated with the production platform, whose entries hold each issuer's did:webvh identifier, status, Stellar account, Indy DID and a key list. Signing key: none yet. Credentials are signed via the service's Indy DID for now; the new key will be listed in its log. The design will extend it to verifiers, the roles and credential types each institution is approved for, attribute-access permissions and the conditions of approval Research: not built. See the trust registry contract interface.

Verifier. An organization that requests and validates credential presentations from holders.

W3C Bitstring Status List Research: target, no code. A privacy-preserving revocation mechanism in which each credential's validity is one bit in a compressed list. The status-list format for the W3C credential forms; the same bits are also published as an IETF Token Status List.

Cryptography

Ed25519. A fast, compact digital signature scheme, commonly used for DID authentication keys.

Merkle tree / Merkle root. A cryptographic structure that combines many hashes into one root hash, so a single value can stand for a whole batch. The planned issuance anchors would batch credential hashes under Merkle roots Research: not built.

Selective disclosure Live. Revealing only the attributes a verifier asks for, with consent on the device for every presentation.

Unlinkability. The property that separate presentations of the same credential cannot be matched to each other, so verifiers cannot combine them into a profile of the holder. On the credential rail running today, presentations to different services cannot be matched by cryptography, because the zero-knowledge presentation carries no identifier shared between services Live; within one service the relationship is stable by design, so that service recognises a returning holder. Carrying the property onto the target formats is a research question Research: two candidate approaches, no code.

Zero-knowledge proof (ZKP). Proving a statement without revealing the underlying data. Used today for predicates such as "over 18" Live; next-generation proof systems are Research: two candidate approaches, not yet piloted on low-cost devices.

Miscellaneous

DPI / DPG. Digital Public Infrastructure (foundational interoperable systems for identity, payments, data exchange) and Digital Public Good (open digital infrastructure serving the Sustainable Development Goals).

PII. Personally identifiable information: data that identifies a person directly, such as a name or document number, or that could identify them when combined with other data. No Civitas contract writes any of it to the ledger.

Prompt injection. Retrieved content trying to override an AI agent's instructions. Relevant only to the planned wallet assistant; no AI or agent code exists in any layer today Research: no shipped code.

RAG (retrieval-augmented generation). An AI architecture that grounds a model's answers in content retrieved from a knowledge base at the moment of answering. Relevant only to the planned wallet assistant, whose answers are designed to be grounded in a curated base of service requirements and local rules Research: no shipped code.

Soroban. The Stellar smart-contract platform behind the trust layer. Two contract types run today (trust registry, log witness), both on the test network; the revocation registry and issuance anchors do not exist yet. There is no separate DID registry and no schema contract: each institution's did:webvh DID log carries its key history, and its credential schemas are published off-chain under its own identifier.

State archival. Soroban archives stored data unless its lifetime is extended, keeping active state small. The registry extends its stored data before it expires: every issuer entry that is not revoked each week, and the rest of the stored data of both contracts in advance.

Stellar. The public blockchain chosen as the trust backend of the Civitas reference deployment: low-cost writes, fast finality. Every Civitas contract runs on its test network; mainnet deployment waits on the security audit of the next release of the contract library the registry is built on and on a key ceremony, rehearsed in advance, that places the governance keys with three separate holders.

Status, 2026-10-01: this glossary covers the main terms of the white paper and its technical layer, defines each term as the wider ecosystem uses it and marks, entry by entry, what Civitas runs today; every Civitas contract named here runs on the Stellar test network, and the formats and protocols marked Research have no shipped code.