Known limitations

View as Markdown

Registry Stack is pre-1.0 Beta software for self-hosted institutional pilots. It is not a production support commitment and carries no hosted service-level agreement.

Product maturity

Interfaces may change before 1.0. Keep clients and deployments on compatible releases.
Operators must supply production identity, networking, secret storage, monitoring, backup, and incident response.
Generated checks establish contract consistency. They do not certify legal compliance, accessibility, source correctness, or institutional authority.

Platform support

This is the release artifact matrix for the current source roster, which first applies to version 0.39.0. Version 0.38.0 is the last numbered release whose immutable archive contains Relay; its archived documentation and release manifest preserve that release’s original platform roster.

Artifact	Linux amd64	Linux arm64	macOS Apple Silicon
`evidence`, `evidencectl`, and `evidence-oid4vci`	Published	Published	Published
`breg` and `bregctl`	Published	Published	Published
`breg-mcp` and `breg-review`	Published	Published	Published
`casework` and `caseworkctl`	Published	Published	Published
`schedulingctl`	Published	Published	Published
`registry-manifest`	Published	None	None
`discovery` and `discoveryctl`	Published	None	None
`scheduling`	Published	None	None
`messaging` and `messagingctl`	Published	None	None
`registry-render`	Published	None	None
Container images	Published	None	None
Client packages (`@registrystack/client`, `registry-stack-client`)	Published	Published	Published

The container row covers the retained service images: Evidence Gateway, its OID4VCI adapter, Discovery, Base Registry Engine, breg-mcp, breg-review, Casework, Scheduling, Messaging, and Registry Render.

The release publishes no Windows, Intel macOS, or musl Linux artifact. Installers refuse unsupported operating systems and architectures before downloading.
Standalone Linux binaries, including CLI tools, link the GNU C library dynamically and require glibc 2.34 or newer. Installers reject detected musl hosts, including Alpine, and glibc versions below 2.34. That floor is the one of the release an installer was published with. A release’s Linux binaries need the glibc that release was built for, so each installer also starts every Linux binary it verified before it selects the release. A release whose binary does not start on the host is refused, and the installed toolset stays selected. Python client wheels are manylinux_2_17; no musllinux wheel is published.
Each container image is linux/amd64; no multi-architecture image index is published. An arm64 container host therefore needs amd64 emulation.
Published macOS executables use arm64 bundles that include the executable, its shared AWS-LC-FIPS libraries, and notices. The release publishes no Homebrew formula, cargo binstall target, apt, apk, yum, Nix, winget, or Scoop package.

Base Registry Engine (BReg) limits

Base Registry Engine serves one governed registry from a PostgreSQL database it owns, under a package an operator activates deliberately. Its current limits are:

PostgreSQL only: the store requires btree_gist, plus PostGIS where the registry declares spatial fields. There is no SQLite, other SQL engine, file, or HTTP source adapter.
Audit is outside PostgreSQL: each process writes its own file or stdout stream. A crash after a mutation commits can leave a request entry without its response. Revision history still records the change; external append-only storage supplies audit tamper evidence and completeness.
Every production model or access change is a package applied deliberately. No runtime API edits access rules, record shapes, or webhook destinations, and nothing hot reloads.
No backup or restore command ships. Recovery from an activation that migration reconcile cannot resolve depends on the operator’s PostgreSQL backups. A destructive migration must name a backup artifact that tooling validates but does not create.
history erase has no dry run or undo and refuses more than 10,000 revisions in one transaction. history rebaseline verifies every live row in one transaction and holds writes to every entity table until it commits.
The runtime enforces timeouts and connection-pool bounds but has no request-rate limit. Put the registry behind an upstream limiter.
The load-test harness tests a profile on the operator’s hardware. No supported throughput or latency figure is committed.
A release provides binaries and a container image, not a Helm chart, Compose deployment, operator, or hosted offering. Quickstart Docker usage is a loopback development path.

Encrypted restricted fields add these limits:

Change-request flows cannot target an encrypted field.
One key version is active at a time; envelope-key rotation is not implemented.
A flip-on migration requires history: erase-and-rebaseline or history: retain-plaintext-history. Retaining plaintext history does not meet the database-read guarantee. Erasing and rebaselining can remove history beyond the encrypted field.
Backups made before the flip remain plaintext. No tooling retires or encrypts them.
Blind indexes deliberately leak equality, presence, and cardinality to a database reader while keeping the indexed value sealed.

BReg statistical releases

BReg’s count datasets use explicit calendar periods in UTC and closed boolean or vocabulary dimensions. They do not reconstruct historical registry contents, accept free SQL, or expose microdata. The native JSON/CSV document does not claim full SDMX conformance.

Minimum-count suppression and deterministic rounding can reveal suppressed values through interval arithmetic. For example, two positive suppressed cells under minimum five are each at most four; a rounded total of ten with base five constrains their sum to at least eight, revealing two fours. Exact zeros reveal absence; overlapping populations and successive versions permit differencing. There is no privacy budget or differential privacy.

The statistical dataset explanation describes these residual risks and the separation between live, publisher, and released-reader profiles.

Evidence Gateway limits

Evidence Gateway answers predefined requirements. It is not a general query or policy engine, and a signed assertion proves what the configured service asserted rather than the source’s correctness.

A released assertion has no revocation, status-list, or presentation-time callback. It remains verifiable until validUntil; rotating a signing key does not invalidate an assertion while its public key remains available. The bounded OID4VCI adapter does not add assertion revocation or a general wallet lifecycle.
The request nonce is uninterpreted correlation data echoed into the payload. Evidence Gateway never stores it or checks uniqueness, so it becomes a freshness check only when a verifier independently retains the value it sent.
Unsigned output is transport-authenticated convenience, not later-verifiable evidence. Both the immutable bundle and the matched grant must permit it.
disclosureGuard families are operator attestations, not semantic classification. The runtime cannot detect two differently named families that disclose equivalent information.
There is no cumulative disclosure budget. Rate controls are uniform per principal, in-memory, and per process; replicas multiply them and restart resets them. Per-client quotas belong at the gateway.
One process serves one trust domain with one token issuer and one set of claim names. Mutually distrustful issuers or clients whose authority uses different claim names need separate deployments, bundles, signers, and audit boundaries.
Access tokens are bearer tokens. A token carrying a proof-of-possession confirmation claim is denied because Evidence Gateway validates no sender proof.
There is no runtime upload, editor, approval API, hot reload, merge, mutation, governed-field override, or fallback. Every change is a reviewed revision and restart.
Startup does not detect overlapping authority paths. Zero paths and multiple paths both deny at request time, so overlap appears as a refusal rather than a deployment-time error.
Readiness resolves credentials, trust bindings, the signer, and the audit sink. It sends no evidence-data request and does not prove that a source returns data.
Fixed HTTP sources accept bounded JSON media types. A local adapter can validate another source protocol and expose bounded JSON, but Evidence Gateway itself does not implement that protocol’s search, pagination, subscription, or conformance behavior.
Production signing supports Vault or OpenBao Transit through a workload-local Unix-socket proxy. Local assurance supports a file-backed private JWK. There is no PKCS#11 or cloud-KMS plugin layer.

Two subject binding modes, two different limits

A requirement in the immutable bundle declares which mode it issues under. The vocabulary is closed at two values and carries no default: a requirement that declares nothing issues audience-scoped assertions, and no caller input selects a mode.

Boundary	`audience-scoped` (absence of a declaration)	`holder-bound` (declared per requirement)
Subject binding scope	The audience taken from the authenticated context	The RFC 7638 thumbprint of the holder key the caller supplied
Cross-verifier use	None. The assertion is meaningful to the one relying party it names	Deliberate. One credential is presentable to several verifiers, and the holder decides which
Holder key	Optional, echoed into `cnf`, verified by nothing	Required, and `cnf` is required in the credential
Possession proof	None at any point	A key-binding JWT the relying party verifies at presentation
Correlation across verifiers	Prevented by the service	Delegated to the holder, who chooses which key to reuse and where
Response formats	Signed JWS, SD-JWT VC, or the unsigned envelope, as permitted	Narrowed to the SD-JWT VC serialization and its batch envelope
Value forms	All twelve	Ten forms; the two entity-reference forms are refused, because both take the audience as a derivation input
Contract status	Frozen Version 1	Frozen, and every negative test the profile names resolves to an executable test

The audience-scoped holder key is unverified: a request may carry an optional holderKey that is echoed into the cnf member. Under this mode Evidence Gateway issues no holder key, binds none, and verifies none, so cnf is a caller-supplied convenience for whatever presentation layer the operator runs elsewhere.
Audience-scoped assertions are not multi-verifier: the subject identifier is an audience-scoped pseudonym, so the same person requested for a different audience yields a different identifier. Purpose is an input to every subject binding and audit pseudonym as well, so one subject is not linkable across purposes. This is deliberate, and it means an audience-scoped assertion is not a general-purpose credential a holder presents to several verifiers.
A holder-bound credential accepts cross-verifier correlation: the binding no longer takes the audience as an input, so the same holder key, trust domain, purpose, subject role, selector profile, and selector values yield the same binding for every caller and every verifier. Holder key reuse is the correlator, and Evidence Gateway can neither prevent nor detect it. The declared purpose is a low-cardinality attribute disclosed to every verifier the credential reaches, and the binding is a persistent pseudonym for that whole tuple: repeating the same request with the same key returns the same binding.
Batch issuance reduces linkability; it does not remove it: a holder-bound release may carry one member per distinct holder key under a ceiling the bundle declares, so a holder presenting a different member to each verifier hands them no shared subject binding. What it removes is the deterministic key-based link, not linkability in general: the members still share an issuance timestamp, purpose, requirement, Evidence Type, configuration revision, and disclosed values. The issuer knows one requester submitted those keys together.
The holder-bound audit pseudonym is stable across issuances: it omits the audience, so repeated issuance for the same subject records the same pseudonym. That is a deliberate accountability property, stated rather than hidden.
Presentation-time audience is verifier-asserted: the relying party puts the audience and nonce in its own challenge, and neither is issuer-signed. No issuance record names the verifier a holder-bound credential later reached.

What verifying a presentation does and does not prove

A verified key-binding JWT proves the presenter held the private key of the credential’s confirmation key when that JWT was signed, over exactly the presented bytes, for the audience and nonce the relying party chose. It proves nothing else.
A valid issuer signature alone does not prove possession. A presentation whose issuer signature verifies and whose key binding does not is rejected, never reported as an issuer-only success.
Nonce equality is not nonce consumption: the same presentation bytes verify again, and again, against the same stateless policy. RFC 9901 section 7.3 places the challenge lifecycle in the surrounding protocol, so issuing a challenge, retaining it, and retiring it belong to the relying party. This is not replay prevention, and no Evidence Gateway surface performs replay prevention.
The relying party cannot derive a subject binding under either mode: the derivation is keyed by a deployment secret it does not hold. Expected subject bindings are pinned from independent trusted state, exactly as they are for an audience-scoped assertion. An expected holder key thumbprint is an optional extra expectation for a pre-established holder, not what proves possession.
Wallet compatibility is unclaimed: full SD-JWT VC and OID4VCI conformance are not claimed, and no test in this repository covers a wallet storing or presenting an Evidence Gateway credential. The pinned OID4VCI runner covers sanitized metadata and wire shapes, service-side key binding, and independent presentation verification. Its opt-in upstream half runs focused source tests at exact Inji revisions, not Android or iOS user-interface or device automation.

Registry Manifest and Discovery

Manifest output is descriptive and static. It neither serves records nor authorizes access.
Rendered standards artifacts are well-formed, not certified: Manifest rendering emits standards-shaped artifacts but does not validate them against external standard bodies: a rendered CPSV-AP, DCAT, or SHACL document is well-formed by construction, not certified against the standard. Read the limits in full in the Manifest data model.
Current Discovery runtime and clients support Evidence providers only.
Published Discovery v1alpha1 profile resources remain historically broad. Operators must rebuild mixed pre-retirement indexes before serving them with a current runtime.

Stack-wide boundaries at a glance

These boundaries cut across components.

No source mutation: Evidence Gateway reads its fixed sources read-only, and persists nothing it read.
A published manifest grants nothing: Publishing a dataset, policy, or evidence offering in a discovery artifact grants no access, enforces nothing, and asserts no fact about a live record. Discovery metadata is not a trust anchor: a published manifest does not bind a consumer to trust a JWKS endpoint or a service host. Trust bootstrap stays in the consumer’s local policy.
Solmara Lab and its hosted instance are demonstrations, not infrastructure: Solmara Lab is a separately maintained adopter demo that uses generated synthetic data and demo configuration. It is not a formal Registry Stack product and provides no production deployment guidance. Any hosted instance of Solmara Lab is likewise a demonstration, not production infrastructure: it carries no uptime or data-retention commitment.

Security-model operator boundary

A healthy, reachable, internally consistent deployment is not the same as a production-secure one. Read the full security boundary in the security model.

Health checks do not certify key custody: Readiness, liveness, and protocol-conformance checks do not certify production-grade private-key custody. A deployment using software keys, local JWK files, or demo-generated keys can be reachable and internally consistent yet not production-secure. Custody, rotation, and key-provider approval remain operator responsibilities.
Many guarantees are the operator’s to provide: Secret and key provisioning, key custody and rotation schedule, audit retention and storage, tenant isolation, transport termination, edge rate limiting, deployment configuration, and incident response are operator responsibilities, not behaviors the stack guarantees.
Audit retention is not audit completeness: the local audit log of Evidence, Render, Base Registry Engine, Casework, and Scheduling is not chained or signed, so it provides no cryptographic tamper evidence for retained history. A running writer detects external changes to its active file and fails closed, while each runtime deletes sealed files after retentionDays. None of them ships sealed history for you; tamper evidence and completeness come only from the append-only storage the operator ships audit entries to.
Demo and template code is not a production profile: Demo helper code and generated workflow snippets are integration examples, not a production freshness or replay-protection profile, and must not be relied on for freshness, expiry, or replay protection.

Supply-chain and release limits

These concern how releases are signed and what that signing currently covers.

Partial release signing: One keyless cosign bundle authenticates the public SHA256SUMS inventory, and GitHub artifact attestations authenticate the candidate manifest and bundle. OCI image signatures are not yet published, and Git version tags are not yet cryptographically signed (GPG, SSH, or Sigstore). The v0.8.0 prerelease was published before release-asset signing and does not currently include cosign signatures.

For how to verify what is signed, see the release verification guidance in release/VERIFY.md in the repository.

Product removal

Registry Relay ended with version 0.38.0 and is absent from 0.39.0. No maintained component replaces its generic SQLite publication, SDMX, or JSON-FG surfaces. See the retirement decision.