Privacy architecture and data boundaries

From the white paper: section 5.1 says that Civitas is not a database of people and that nothing personal reaches the public ledger; this page draws the data map, boundary by boundary, and says which of those guarantees is structural and which is policy.

Structure first, policy second. A privacy property is structural when the system cannot break it, whoever operates it, and policy when it depends on the operator's behavior and a contract's terms. The page keeps the two apart.

Nothing personal on the ledger, by construction. The public trust layer records institution-level facts only. The trust layer rests on two Soroban contracts, both on the Stellar test network: the trust registry In build: wired to the production platform holds registered institutions, their status and the Stellar account each controls, and the log witness In build holds only attestations: for each institution, its DID, the Stellar account that attested, the version of its own signed DID log and the time. The logs themselves, which carry each institution's key history, and the credential schemas it publishes stay off-chain and, unless the institution names its own domain in its identifier, are served from the Civitas platform, as they are for every institution today. The two remaining contract types (revocation registry, issuance anchors) do not exist yet and will hold governance-level data on the same basis. No holder identifier, no credential content and no record that a person was checked is ever written to the chain: holders have no on-chain identity at all.

No server-side credential store. The launched wallet Live generates and keeps keys and credentials on the person's phone, behind a passcode and the device's secure hardware where present. Civitas holds no copy and runs no server that stores anyone's credentials. Every presentation passes a consent step on the device; nothing is shared automatically or silently. Which attributes a verifier may request is set in the platform's interaction rules today; registry-level enforcement is not yet implemented on-chain.

Pairwise identifiers. A holder has no identifier published in any registry or on any ledger, and each wallet-to-issuer and wallet-to-verifier relationship uses its own identifier, known only to the two parties. The platform does keep one identifier per wallet: the device identity the wallet registers, used to detect cloned installations. On the credential rail running today, AnonCreds over Hyperledger Indy Live, the zero-knowledge presentation itself carries no identifier shared between services, so two verifiers cannot compare records and find the same person. Within one service the relationship is stable by design: the pairwise identifier persists across that holder's interactions with that service, so a service recognises a returning user, and unlinkability holds between services rather than inside one. Carrying this property onto the target credential profiles is a design requirement, not a solved problem: SD-JWT is linkable across presentations by default, two approaches to unlinkability are under research and neither is chosen, and no code exists for the new formats or for either approach Research: first releases aimed at early 2027.

The administration layer holds institutions, not people. The platform's Ecosystem Console Live is designed to hold institution-level records only: due diligence on organizations, credential type definitions, interaction rules and governance decisions, with no personal data and no per-person activity logs.

Tenant databases are policy territory. What an issuer or verifier collects from its own clients stays in that institution's own tenant database, logically separated from every other tenant. Today those tenants run on infrastructure Civitas hosts, so Civitas processes those records on the institution's behalf under the agreement between them; the institution remains the controller. Running a tenant on the institution's own infrastructure is a designed option Research: the platform cannot yet be self-hosted, and self-hosting follows the open-source release planned for the first half of 2027. Treat this layer as governed by contract and configuration, not by cryptography.

Verification does not call the issuer. As designed, checking a credential never notifies the issuer that a check happened. On the new rail a verifier is designed to fetch the issuer's DID log and its status list from where they are hosted, which today is the Civitas platform for every institution; the host can see that a list was fetched, not which credential was checked, and large lists and caching narrow even that. Inside the platform today, the registry check is a verifier extension reading a signed export of the test-network registry, and that check has run with all network access blocked In build: the registry it consults runs on the Stellar test network. Checking the credential itself on the rail in service still reads the Hyperledger Indy ledger. On the live rail the holder proves non-revocation inside the presentation, so the verifier does not contact the issuer. Two limits: the check still runs inside the platform Civitas hosts, so Civitas stays in the path as host until a verifier runs the same check on its own systems, and the promise covers the identity check, not every service a deployment adds around it.

What a regulator can check, now and later. Today a reviewer can read the on-chain state of both test-network contracts, confirm they hold institution-level facts only, and watch the consent step in the shipped wallet. Source code cannot be checked yet: the open-source release is planned for the first half of 2027, and no license has been applied to a repository yet. Until then the no-personal-data property of the ledger is verifiable from public data, while the platform's handling of tenant records rests on contract terms and this document.

Status, 2026-10-01: the on-device wallet, per-presentation consent and pairwise identifiers run in production today; both deployed contracts run on the Stellar test network; tenant self-hosting, registry-enforced attribute limits and the unlinkable credential profiles are not built, and source inspection waits on the open-source release planned for the first half of 2027.