Schema publication

From the white paper: section 4.2 says credential schemas are published as attested resources under the publisher's own identifier; this page describes where a published credential schema lives and why nobody, the platform included, can quietly change one.

The problem publication solves. A credential schema is the published definition of a credential type: which attributes a "Proof of Employment" credential carries, in what format, under which version. Everything downstream trusts that definition, so a quietly edited schema is a way to change what a credential means after the fact. Publishing each schema as a signed, content-addressed resource under its publisher's own identifier In build: the log witness it relies on runs on the Stellar test network makes that edit impossible to hide.

Where a schema lives. A schema is an attested resource: a document published under its publisher's own did:webvh identifier, kept off-chain on the institution's host (by default platform.civitasid.org), and signed with keys the institution holds itself. The definition therefore carries the signed history of the organization that stands behind it and travels with that organization wherever its identifier is served from. The schema is not written into the institution's DID log and never reaches the Stellar ledger; the log carries the institution's keys, and a reader checks the schema's signature against them (the trust registry page describes the log and its witness). On the credential rail in service the platform also writes a copy of each schema to the Hyperledger Indy ledger, after the service's log has accepted it; that copy retires with the Indy rail. Content is immutable by construction: a resource's identifier is the hash of its content, so a changed schema is a new resource with a new identifier.

Versions and deprecation. Publishing a new version does not withdraw the old one: previous versions stay resolvable, and credentials issued under them still verify. A publisher can mark an older version as deprecated with the platform's per-schema Deprecated flag, which hides it from the catalog lists other services see. A publisher can also keep a schema private: the platform then hides it and its credential definitions from other services, which can neither copy it nor ask a holder for credentials by it, while the schema itself stays public under the publisher's identifier.

Discovery. Each service publishes one index resource listing every schema it has published, and its DID document points to that index through a service endpoint, so a verifier that can resolve the publisher's identifier can find and enumerate its schemas. The identifier, its key history and everything published under it are served from one place and checked together.

Why a forged copy cannot pass unseen. The ledger records which version of the publisher's DID log the publisher stands behind, in the log witness: a contract with no administrator and no upgrade path that stores only the DID, the attesting account, the log's version identifier and the time, and no schemas. Anyone may attest, and a reader counts an attestation only when the account that made it is both the account the trust registry binds to that publisher and the account the publisher's own signed log names In build. Only the publisher can change the account its log names, and the platform's registrar binds no other account, so the platform cannot choose whose attestation counts. The attestation is signed by the institution's own Stellar account in its own wallet, so the platform never holds a key that vouches for anyone's log.

Publication from the platform. Publishing a schema from the Service Dashboard signs it on the publisher's side as an attested resource and adds it to the service's schema index In build: with the log witness on the Stellar test network. The platform stores and serves the log, the index and the schemas but cannot rewrite them: every log entry and every schema is signed with keys the service holds itself, which never reach a Civitas server, and the log's version is attested by the service's own Stellar account. The people who use a service's Service Dashboard publish with dedicated publishing keys, from which the platform accepts schemas and nothing else, while the keys that change the log stay with the service's owner, in the Service Admin.

Who may sign what. Keys are split by what they may do In build. Owner keys, held by the owner in the Service Admin, are the keys that change an institution's DID log; a key made in the Service Dashboard is a publishing key, from which the platform accepts schemas only. When a user is deleted from the Service Dashboard, the platform refuses that user's schemas at once, and the owner then removes the key from the log. The owner also reviews the list of published schemas: each entry is shown with its verdict under the log's history, the owner keeps or drops it and signs the list once, and no owner signature is placed over a list the owner has not seen. While a served list fails verification, publishing to it is refused.

Verification without chain reads. Verifiers do not read the chain. The exporter resolves each publisher's log, verifies it in full, reconciles its head with the on-chain attestation, and publishes the result in the signed registry snapshot: per service, the identifier, the verified head and the schema list. A verifier holding a schema document can recompute its digest and compare it with the snapshot, offline, in the same zero-chain-access path the registry uses. A failed refresh changes the age of the answer, never the answer: the snapshot keeps the last verified state, with its ledger timestamps.

One privacy boundary, stated plainly. The publisher's signature over a schema is the institution's public statement about a credential type. It never appears in a holder's credential presentation, so it adds nothing that could correlate a person across verifiers.

Status, 2026-10-01: schema publication as attested resources under each service's own identifier runs from the Service Dashboard for every service with a DID log, signed with keys the service holds itself, with each log's version attested in the log witness on the Stellar test network; a new service is created together with its log; dedicated publishing keys are in service; no Civitas contract runs on the public Stellar network.