Security

View as Markdown

Registry Stack protects data through product-specific authorization, closed configuration, bounded source access, explicit disclosure, package integrity, and accountable audit.

The normative cross-product security model is RS-SEC-G. The threat model, known limitations, security self-assessment, and release trust evidence provide review context and public evidence.

At a glance

What	Where it stands
Evidence authentication on every assertion or definition route	Built in; operational probes, OpenAPI, issuer metadata, and public verification keys are the exceptions
Evidence inbound authentication	OIDC bearer with one governed issuer profile; no API-key or static-credential mode
Deny-by-default authorization before source access	Built in
Only public verification material is published	Built in
Evidence person-level access audit	Built in and fail-closed, with no best-effort switch
Evidence disclosure modes	`value`, `predicate`, and `redacted`; the requirement fixes what is permitted
SD-JWT VC assertion serialization	Built in as an encoding; the assertion format itself is not a credential lifecycle
Holder-bound presentation	Declared per requirement and verified by the relying party
Replay prevention for presentation	Not provided; the relying party owns challenge issuance, retention, and consumption
Hardened HTTP headers and outbound source limits	Recommended by RS-SEC-G; confirm the deployed product applies them
Key custody, audit retention, isolation, TLS, and edge quotas	Operator responsibilities
Compliance with cited external standards	Not claimed

The Evidence request in one pass

Authenticate. Evidence verifies the bearer signature, issuer, audience, token type, and algorithm against one governed OIDC profile. It never trusts a proxy identity header or falls back to an alternate principal claim.
Authorize. One complete grant and authority path must match the requester, requirement, purpose, subject roles, selector profiles, origin, authority, and audience. Authorization finishes before source credential resolution or source access.
Serve. The core runs only the governed fixed source stages, validates typed concepts, and constructs the permitted value, predicate, or redacted answer. Caller input cannot add a source request, expression, disclosure field, or output projection.
Audit. An access-attempt record is durably accepted before each acquisition stage and a disclosure-release record before the response leaves. Audit failure blocks the corresponding action. Entries are minimized and value-free; tamper evidence depends on shipping them to append-only storage.

Every Evidence route returning an assertion or its protected definition requires a verified access token. /health, /ready, /openapi.json, the issuer JWKS, and issuer metadata may be public because they contain no person-level result or grant inventory. An issuer publishes only the public half of an assertion-signing key, so a verifier needs no source or service credential.

Evidence can encode an assertion as SD-JWT VC, with digests in place of disclosable values. That is a serialization of the same bounded assertion. Revocation, status, presentation replay state, and a general wallet lifecycle are outside that assertion format. The separate OID4VCI adapter provides its documented delivery profile without changing those limits.

A requirement chooses one of two subject-binding modes. Audience-scoped binding derives a pseudonym over the relying-party audience. An optional holder key in that mode is echoed into cnf without proof. Holder-bound mode derives from the RFC 7638 holder-key thumbprint and requires a key-binding JWT that the relying party verifies at presentation. Evidence issues no key-binding JWT, keeps no challenge state, and runs no presentation endpoint. Comparing a challenge nonce does not consume it, so the relying party must prevent replay.

The portable verifier library and evidence verify-presentation check issuer and key-binding signatures, the expected audience and nonce, and independently pinned expectations. A successful issuer signature alone does not prove holder possession.

An AI assistant acting for a citizen

A citizen can ask an AI chat assistant to read their own Base Registry Engine (BReg) record and prepare a correction to it. The assistant calls the breg-mcp gateway, the gateway acts at the registry as that citizen’s delegated agent, and BReg decides what the agent may read or change. Neither the model’s instructions nor a tool argument can widen that decision.

The agent carries the citizen’s identity. Before a tool call reaches the registry, the gateway exchanges the chat host’s verified token for a registry token that names the citizen as subject and the gateway as actor, using RFC 8693 token exchange. A call the gateway answers or refuses without a registry request, such as describe_service, makes no exchange. The chat host’s token never reaches BReg, and BReg refuses an actor it is not configured to trust for that client.
The agent reads and drafts under BReg’s authorization. Every registry request the gateway makes carries the delegated token, and BReg admits that token only to an access profile declared for agents. That profile, applied to the citizen, decides what the agent sees and which drafts it may write.
The agent drafts a change request and cannot submit it. A delegated token that carries no task grant is admitted only to a standing agent profile, an agent profile with no task grant. The BReg compiler refuses such a profile when it holds submit-request, revise-request, cancel-request, or apply-request, when it holds create or patch on an entity without a change request, when it holds import, tombstone, or batch on any entity, when it holds any action permission, and when it holds publish on a statistical dataset. The gateway’s own lint configuration also disallows the client methods that would reach further.
The agent’s drafts point at the citizen’s own record. The gateway writes a draft’s target from the single record BReg lists for the delegated token, the citizen’s own linked record in the reference project, and its owner from the subject of the chat host’s verified token. It refuses any tool argument or edit that names either field.
The citizen confirms the change. A separate breg-review process, with its own client credentials, shows the citizen the draft beside the record it would change and submits it under the citizen’s own sign-in. The page calls BReg only to read the registry contract, the draft, and the draft’s target, and to submit. BReg keeps the agent from submitting. What the citizen’s sign-in may do through the page is whatever the review access profile grants, and the operator declares that profile: the reference project’s review profile also grants patch and cancel-request on the draft.
A reviewer decides where the registry requires one. When the change request declares review.type: required, the review authority it names decides whether BReg applies the request. A change request that declares review.type: none has no such step.
The audit journal shows who acted for whom. BReg records an agent’s calls with keyed pseudonyms for the agent, the citizen it acts for, and the client.

What the assistant says in conversation is outside these controls; the review page shows the canonical draft BReg holds, not the assistant’s summary of it. BReg does not yet tie a change request’s target to the requester’s own record. For this pair of services, the gateway derives the target, the review page reads the target under the citizen’s own token before it offers submission and again before it submits, and a reviewer checks the request where review is required. The review page’s read covers the gap only when the review access profile limits that read to the citizen’s own record, as the reference project’s profile does. Any other client must not rely on BReg for it. A delegated token that leaks stays valid at BReg until it expires, so the authorization server must keep exchanged token lifetimes short. What the design guarantees states each property with its enforcement point.

Maintained boundaries

BReg authenticates callers and applies compiled access profiles to its own records, changes, history, and events.
Evidence Gateway authorizes before contacting a fixed source and signs only the concepts its reviewed requirement declares.
Registry Manifest publishes static metadata and grants no runtime authority.
Registry Discovery returns inert public metadata. The application owns provider trust.
Registry Platform supplies shared primitives while each product owns policy and configuration.

Recommended controls that require confirmation

RS-SEC-G recommends sourcing security-critical authentication, OIDC, audit, HTTP policy, cryptography, and SD-JWT helpers from Registry Platform so behavior stays consistent and reviewable. Confirm each deployed service uses those primitives because the specification does not force an implementation choice.

Security response headers and outbound HTTP limits are also recommended controls. For Evidence, confirm fixed-origin and hostname verification, redirect and proxy denial, TLS trust, timeouts, response-size bounds, and the one-request-per-stage ceiling. The governed bundle constrains source behavior, while the operator still owns the network path, edge controls, and certificates.

Operator responsibilities

Operators provide identity issuance, TLS and network controls, secret storage, key rotation, durable audit storage, database security, backups, monitoring, and incident response. Product checks do not replace these controls.

The software keeps secrets out of distributable artifacts and supplies the enforcement primitives; the operator provisions and runs them. Record ownership and recovery paths in the operator handoff checklist before activation.

Verify before production

Run the product’s production checks on the exact package and configuration.
Exercise valid, missing, invalid, expired, and insufficient credentials.
Confirm a denial reaches no protected source or mutation.
Confirm required audit failure blocks release of protected output.
Test dependency timeout, size limit, backup, restoration, and rollback.
Record the exact source, package digest, configuration revision, and approval.