RegistryStack v0.11.0

Registry Stack v0.11.0

Registry Stack v0.11.0 is the beta-13 technical release after v0.10.0. It is a
pre-1.0 release for evaluation, integration pilots, and public review. It does
not promise stable 1.0 compatibility, completed OID4VCI interoperability,
hosted promotion, audit completion, or an external pilot result.

Highlights

• Direct and OID4VCI credential issuance now accepts only fresh,
  non-delegated stored evaluations whose selected credential claims have a
  complete registry-backed dependency closure. Every claim is bound to an
  exact compiler-pinned Relay consultation and normalized Relay execution
  provenance before signer access.
• Source-free, self-attested, delegated, and other evaluation-only claims can
  still be evaluated and rendered, but cannot be configured for credential
  issuance. Existing v0.10.0 evaluations remain readable and renderable and
  must be re-evaluated before issuance.
• Relay and Notary reject requests that contain more than one primary
  credential channel before parsing either candidate. The generic
  auth.multiple_credentials result does not reveal whether either candidate
  was valid.
• Claim evaluation formats now have one closed contract. Omitted formats
  defaults to canonical claim-result JSON; explicit empty, unknown, CCCEV-only,
  and SD-JWT evaluation-format lists fail configuration validation. SD-JWT
  remains a credential issuance format.
• Relay publishes a reproducible Draft 2020-12 runtime configuration schema
  and provides bounded, value-free diagnostics for unknown or incorrectly
  called Script host functions.
• registryctl check aggregates safe authoring diagnostics. Project inputs
  may bind bounded target attributes, and init --from installs deterministic
  project-local schema mappings for VS Code and Zed.
• Registryctl embeds the optional preview language server under
  registryctl authoring language-server; it is not a separate release
  artifact. The VS Code and Zed extensions remain source-installed developer
  previews and are not marketplace packages. Registryctl's generated schema
  mappings remain the stable beta authoring workflow.
• Registryctl continues to expose exactly five public starters: HTTP, DHIS2
  Tracker, OpenCRVS DCI, FHIR R4, and exact snapshot. A checked-in catalog
  distinguishes those starters from additional maintained and conformance
  workspaces.
• registryctl add notary supplies a local registry-backed Notary evaluation
  tutorial over the generated benefits workbook. It proves an evaluation path
  only and does not prove credential issuance, wallet behavior, credential
  presentation, or OID4VCI interoperability.
• Relay and Notary latch readiness after a confirmed retained audit-chain
  inconsistency and provide offline quarantine recovery. Transient operational
  failures remain distinct from a confirmed integrity failure.

Migration From v0.10.0

Keep complete, version-matched v0.10.0 and v0.11.0 restore sets and follow the
upgrade and rollback exercise
before admitting traffic.

Re-evaluate before credential issuance

• No PostgreSQL schema migration is required solely for the narrowed issuance
  trust boundary. Do not treat that as permission to reuse old evaluations.
• Drain issuance traffic, deploy the matching v0.11.0 Relay and Notary
  generation, and re-evaluate every claim that may be issued. Direct and
  OID4VCI issuance reject a v0.10.0 evaluation before signer access.
• Credential profiles may select only non-delegated registry-backed claims
  whose full dependency closure has exact compiler pins and normalized Relay
  execution provenance. Remove source-free, self-attested, delegated, and
  evaluation-only claims from credential profiles. They remain available for
  evaluation and rendering.
• Re-run both direct issuance and any enabled OID4VCI path after re-evaluation.
  This release does not claim full wallet or OID4VCI interoperability.

Update authentication callers

• Send exactly one primary credential channel. Requests containing both
  Authorization and x-api-key now fail with
  auth.multiple_credentials, even when one candidate is malformed or valid.
• Do not depend on fallback between credential channels or on an error that
  identifies the accepted candidate.

Update claim evaluation formats

• Omit claim formats to use canonical
  application/vnd.registry-notary.claim-result+json, or include that format
  explicitly. CCCEV JSON-LD may be added only alongside the canonical format.
• Remove explicit empty lists, unknown formats, CCCEV-only lists, and SD-JWT
  from claim evaluation formats. Keep SD-JWT under credential-profile issuance
  configuration. Subject-access allowed_formats follows the same evaluation
  boundary.

Regenerate and validate configuration

• Configuration ${VAR} expansion now rejects both unset and empty variables.
  Use ${VAR:-fallback} for an explicit fallback and ${VAR:-} only when the
  consumer deliberately accepts an empty value.
• Regenerate project outputs with registryctl v0.11.0 and its matching
  registryctl-v0.11.0-image-lock.json. Run registryctl test, check, and
  build; review every aggregated diagnostic before signing or deploying the
  new closure.
• Relay operators can reproduce the committed runtime schema with
  registry-relay schema --format json. A schema-valid document proves
  structure only. It does not prove that referenced files, credentials,
  network authorities, deployment gates, or security posture are deployable.
• Existing registryctl project-local schema mappings remain supported. The
  optional navigation preview requires source installation and is not needed
  for validation, completion, hover, or formatting.

Verify retained audit state

• Start one v0.11.0 instance of each product without traffic and require a
  successful retained-chain verification before admitting callers.
• A confirmed inconsistency latches readiness. Stop the process and use the
  product's offline audit quarantine command under the existing single-writer
  lock, retain the corrupt segment as evidence, then restart and attest the new
  break segment.
• Do not use quarantine for transient I/O or secret-resolution failures and do
  not delete, truncate, or rewrite audit files.

Release Evidence

The release workflow retains the existing eight-artifact public inventory:
Registry Notary, the Notary CEL worker, Registry Relay, the Relay Rhai worker,
Registry Manifest CLI, registryctl, the registryctl image lock, and Registry
Docs. The workflow also publishes the associated images, checksums, SBOMs,
reports, capsule, signatures, and provenance. The preview language server is
embedded in registryctl and is not a separate artifact. The editor extensions
are source-installed developer previews and are not added to that inventory.

Crosswalk remains pinned at
1d44ec735fdc8a7c719264b339574371e8330337. Solmara Lab and hosted publication
remain held until immutable v0.11.0 assets exist, Solmara is repinned to their
exact digests, and its separate adopter gate passes. This source note does not
claim that result.

RegistryStack v0.10.0

Registry Stack v0.10.0

Registry Stack v0.10.0 is the beta-12 technical release after v0.9.0. It is a
pre-1.0 release for evaluation, integration pilots, and public review. This
release deliberately breaks configuration, generated artifacts, and operator
workflows to establish a cleaner implementer contract before 1.0. It does not
promise 1.0 compatibility or an upgrade-stability freeze.

Highlights

• Registry Notary moves every deployable correctness-state domain to one
  typed, Notary-owned PostgreSQL state contract with separate private and API
  schemas. Replay, nonce, evaluation, idempotency, credential status, quota,
  and preauthorization decisions now coordinate active-active replicas and
  survive restart. Production Redis and its configuration are removed
  atomically.
• Registry Relay gains authenticated, hash-pinned consultations for bounded
  http, isolated Rhai script, and immutable snapshot integrations. Relay
  owns source access and its separate PostgreSQL consultation state plane;
  Notary owns claims, disclosure, credentials, and its own database.
• registryctl now provides a product-neutral project authoring journey:
  init --from, offline test, redacted check, and deterministic build.
  Generated Relay and Notary inputs are validated by the same product
  compilers used at startup while keeping source credentials and physical
  bindings in environment-owned inputs.
• Registry Stack now uses one shared RFC 8785 canonical JSON implementation
  and strict raw JSON parser. Duplicate object members and unsafe integer
  values fail closed, while public JWK parsing is bounded and rejects private
  key material without rejecting ordinary non-secret provider metadata.
• Release assets add the standalone registry-notary-cel-worker and
  registry-relay-rhai-worker binaries. Each product retains its own isolated,
  bounded execution boundary; neither worker is a shared state service.
• The retired monorepo Lab is removed. Solmara Lab remains a separate adopter
  repository and is validated against published Registry Stack assets rather
  than being part of this source release.

Migration From v0.9.0

This is a clean pre-1.0 cutover, not an in-place configuration migration. Keep
complete, version-matched v0.9.0 and v0.10.0 restore sets and follow the
upgrade and rollback exercise
before admitting traffic.

Reauthor the project

• Install registryctl v0.10.0 together with
  registryctl-v0.10.0-image-lock.json. Reauthor supported deployments around
  registry-stack.yaml, then run registryctl test, registryctl check, and
  registryctl build with an explicit environment.
• The direct-source commands registryctl init notary,
  registryctl add notary, registryctl notary smoke,
  registryctl notary open, registryctl openfn import, and
  registryctl openfn convert are removed without aliases. Model supported
  acquisition through product-neutral http, script, or snapshot
  integrations. Live tests use only the governed Notary endpoint and never
  contact a registry source directly.
• Notary no longer accepts direct registry connections, DCI or FHIR source
  connectors, source-adapter sidecars, source credentials, or transitional
  evidence modes. Registry-backed claims use authenticated, compiler-pinned
  consultations with the deployment's paired Relay.

Move Notary correctness state

• Before upgrade, remove v0.9.0 writers from traffic and back up Redis,
  configuration, signed bundles, anti-rollback state, audit evidence, and
  signing references. There is no Redis importer or dual-write path. Drain
  replay, nonce, idempotency, preauthorization, and quota lifetimes; any
  unexpired credential suspension or revocation requires an explicit reviewed
  migration and otherwise blocks cutover.

• Replace Redis and per-domain settings with the top-level typed state
  configuration. Provision a dedicated Notary database, migration login,
  isolated owner role, and runtime login. Before starting a listener, run:

  registry-notary --config /etc/registry-notary/notary.yaml state install \
    --migration-url-env REGISTRY_NOTARY_POSTGRES_MIGRATOR_URL \
    --owner-role registry_notary_owner \
    --runtime-role registry_notary_runtime
  registry-notary --config /etc/registry-notary/notary.yaml state doctor

  See the
  complete state runbook
  for role provisioning, TLS, backup, and recovery requirements.

• Do not reuse Relay tables, schemas, roles, or migrations. Replicas may share
  a Notary database only when they serve the same Notary authority and exact
  configuration generation.

• Bootstrap Relay consultation state with the full reviewed command and
  lifecycle inputs in the
  Relay operations runbook.
  Do not substitute the Notary installer or roles.

• Back up and restore the complete quiesced Notary database with its release,
  roles, migration set, and sensitive-state key version. Restore into an empty
  isolated database, rerun state install and state doctor, then require a
  complete readiness attestation. A backup that may predate acknowledged
  traffic remains quarantined until replay, nonce, idempotency, quota, and
  credential-status state is reconciled.

Update Notary configuration

• Remove auth.mode. API keys and OIDC may coexist for distinct service and
  citizen or wallet callers, but each request presents exactly one credential
  type. Static bearer tokens and OIDC remain mutually exclusive because both
  use Authorization: Bearer.
• Keep the Relay public catalog origin separate from the internal
  Notary-to-Relay connection URL. An explicitly enabled literal IP-loopback
  HTTP origin is allowed only for a paired Relay inside the shared network
  namespace. Remote HTTP remains invalid and public Relay origins require
  HTTPS.
• Rename registry-backed claim rules to consultation_output or
  consultation_matched. Claim provenance is
  registry-notary-claim-provenance/v2 with
  relay_consultation_count; the former source-count fields are removed.
• Federation configuration now uses evaluation_scopes and
  max_claim_result_age_seconds. Signed results use
  claim_result_issued_at, with stale results reported as
  federation.stale_claim_result. Federation profiles remain source-free in
  this release.

Bootstrap and regenerate Relay state

• Provision a separate PostgreSQL 16 through 18 database and isolated Relay
  migration, owner, runtime, keyring-maintenance, and keyring-reader roles.
  Run registry-relay consultation bootstrap-state before the first replica.
  Serving instances receive only the runtime credential.
• Consultation date inputs are now typed dates rather than ten-byte strings.
  Regenerate the public contract, integration pack, private binding, and
  Notary expectation, then deploy one matching Relay and Notary generation.
  Do not reuse a v0.9.0 contract_hash.
• The maintained multi-call profiles use fixed absolute deadlines. Configure a
  consultation-enabled Relay request timeout greater than 25 seconds and a
  Registry-backed Notary timeout of at least 30 seconds.
• Quiesce writers before backing up the complete Relay consultation database.
  Restore into an empty isolated database with the matching roles, bootstrap
  inputs, lifecycle settings, and audit-pseudonym key material; rerun
  consultation bootstrap-state and require readiness before traffic. Keep a
  potentially stale restore quarantined until acknowledged state is
  reconciled.

Regenerate canonical digests and install workers

• Registry Manifest source-manifest and policy digests now use RFC 8785
  canonical JSON. Numeric values and non-ASCII object names can change digest
  bytes, and integers outside exact binary64 representation are rejected.
  Regenerate and republish all manifest, policy, contract, and hash-bound
  artifacts with v0.10.0 instead of copying v0.9.0 digests.
• CEL-enabled binary deployments place the released
  registry-notary-cel-worker beside registry-notary under that exact name.
  Relay script deployments likewise install registry-relay-rhai-worker
  beside registry-relay. The product images include their corresponding
  worker.

Release Evidence

The tag workflow publishes the Notary, Notary CEL worker, Relay, Relay Rhai
worker, Manifest CLI, and registryctl binaries; the Relay and Notary images;
the exact registryctl image lock; checksums; file and image SBOMs;
Grype reports; the release capsule; keyless cosign signatures; and release-level
SLSA provenance. The release is not accepted until those published assets and
digests are independently verified.

Crosswalk remains pinned at
1d44ec735fdc8a7c719264b339574371e8330337. No retired Lab-only input is part
of the v0.10.0 artifact inventory. Solmara Lab is repinned and exercised only
after the immutable v0.10.0 assets exist, so this source note does not claim a
hosted promotion or successful post-publication adopter run.

RegistryStack v0.9.0

RegistryStack v0.9.0

RegistryStack v0.9.0 is the beta-11 release candidate after v0.8.4. This is a
pre-1.0 minor release because it deliberately changes Relay, Notary, Manifest,
and registryctl compatibility surfaces that cannot ship as a backward-compatible
v0.8 patch.

Highlights

• Removes Relay-local credential issuance and keeps Registry Notary as the
  credential issuance and verification boundary.
• Hardens Relay and Notary audit retention with single-writer chains, declared
  off-host shipping, acknowledgement cursors, live shipping-health gates, and
  signed-config acceptance evidence. Relay additionally gains offline
  quarantine recovery for an inconsistent retained chain.
• Preserves redacted federation denial context after request verification,
  including response-signing failures, without exposing raw peer, JTI, or
  subject identifiers.
• Scope-gates Relay trust-context headers before PDP evaluation and records
  value-bearing trust scopes only as keyed audit handles.
• Makes Manifest validation reject unknown keys and unsupported core schema
  versions, backed by new fuzz targets.
• Ships registryctl with a strict release image lock built from the exact Relay
  and Notary image digests produced by the tag workflow. Project generation no
  longer depends on compiled stale pins, mutable image tags, or live registry
  lookup.
• Parks registry-platform-sts outside active workspace and Lab release gates
  until a release-surface consumer is named.

Migration From v0.8.4

• Add an explicit deployment.profile to every Relay and Notary config.
  Profiles are never inferred; use local only for development, or select
  hosted_lab, production, or evidence_grade to match the deployment.
  Both products refuse startup when the profile is absent.
• Remove Relay provenance and entity publicschema configuration and move
  credential workflows to Registry Notary.
• Enable Relay's beta attribute-release surface explicitly with the
  attribute-release Cargo feature if it remains required.
• Enable the matching Relay Cargo features for OGC API or SP DCI deployments
  and publish an OpenAPI document from that build. The committed v0.9.0 Relay
  OpenAPI artifact describes the default build and no longer advertises those
  opt-in routes.
• Grant the exact value-bound scope before relying on any newly gated Relay
  header: x-registry-subject-ref uses registry:trust:subject_ref:<value>,
  x-registry-relationship uses registry:trust:relationship:<value>,
  x-registry-on-behalf-of uses registry:trust:on_behalf_of:<value>,
  x-registry-credential-format uses
  registry:trust:requested_credential_format:<value>, and
  x-registry-source-observed-at-unix-seconds uses
  registry:trust:source_observed_at_unix_seconds:<value>. A header without its
  matching scope is treated as absent.
• Remove waivers for hard deployment gates. Production and evidence-grade
  deployments must correct the underlying condition. Audit shipping deployments
  must declare the shipping target and configure a fresh acknowledgement cursor
  where the active profile requires one.
• Correct duplicate Notary claim ids, invalid default disclosure modes, and
  claim rules that refer to undeclared source bindings before startup.
• Review Notary custody for every configured credential, access-token, and
  federation signer. Set
  deployment.evidence.signer_custody_approved: true for production or
  evidence_grade only after that review produces evidence; it is not a
  bypass for an unreviewed software key.
• Stop calling both products' removed TUF-era /admin/v1/config/verify,
  /admin/v1/config/dry-run, and /admin/v1/config/apply routes, and stop
  invoking the removed CLI config apply-bundle command. First run
  registryctl bundle verify for stateless signature and binding verification,
  then place the signed Registry Config Bundle v1 on the node. For a genuinely
  absent, version-specific antirollback state path, start the product server
  with --initialize-state; that boot verifies the bundle and initializes
  state. The product's read-only config verify-bundle command remains, but it
  requires accepted state to exist, so use it only for later candidate
  validation and restarts.
  Replace retired TUF-era fields inside config_trust with the current Config
  Bundle v1 trust fields because strict parsing rejects the old schema. v0.9.0
  has no hot-apply path.
• Treat each product's config_trust.antirollback_state_path as durable state.
  Back it up with the matching release configuration, preserve separate
  version-specific restore sets, and restore the matching state during
  rollback. Do not delete or reinitialize state to force an older bundle to
  boot.
• Remove unknown keys from source-adapter sidecar YAML and governed runtime
  targets; v0.9.0 rejects them instead of silently ignoring them.
• Move Manifest data carried in unknown keys into documented extension points.
• Keep generated or hand-edited registryctl.yaml files on
  schema_version: registryctl/v1, remove unknown keys, and ensure
  notary.source is one of registry_data_api, relay,
  fhir_source_adapter_sidecar, or opencrvs_dci.
• Install registryctl v0.9.0 with its matching
  registryctl-v0.9.0-image-lock.json. Existing projects can still run from
  their stored digest pins, but registryctl init and registryctl add fail
  closed when the matching lock is missing or invalid.
• If audit.include_health: true is set on Relay, update evidence consumers to
  expect /healthz records only. /ready is always excluded; capture the
  readiness response, posture, and shipping-cursor evidence instead of waiting
  for a readiness audit record.

The upgrade and rollback procedure is recorded in
release/exercises/upgrade-v0.8.4-to-v0.9.0.md.
Its local-profile topology and separate evidence-grade Config Bundle,
anti-rollback, signer-custody, and stale-cursor gate are explicit pre-tag runs;
this prepare change does not claim either run succeeded.

Release Evidence

The tag workflow publishes binaries, three GHCR images, exact image digest
evidence, SHA256SUMS, the registryctl image lock, file and image SBOMs, Grype
reports, the release capsule, keyless cosign signatures for GitHub Release
assets, and release-level SLSA provenance. The image lock is classified as a
release file, not a binary, and is included in checksums, SBOM, capsule,
signature, provenance, upload, and reconciliation steps.

Crosswalk remains pinned at
1d44ec735fdc8a7c719264b339574371e8330337. Registry Atlas and the eSignet
Relay authenticator remain held as Lab-only external inputs.

The source beta can ship while hosted publication remains held. Do not announce
the hosted first-run path until the separate hosted-state proof, including #330
and #198, passes against the published v0.9.0 assets.

RegistryStack v0.8.4

RegistryStack v0.8.4

RegistryStack v0.8.4 is the beta-10 release candidate after v0.8.3.
It carries the post-v0.8.3 security, configuration, docs, and release-trust
hardening wave into the public stack release train.

Scope

• Keeps the stack release in the public registrystack/registry-stack
  monorepo.
• Defaults Registry Notary credential profiles to holder binding with
  did:jwk, with explicit opt-out warnings for deployments that intentionally
  issue unbound credentials.
• Removes fingerprint.commitment from current Relay, Notary, Lab, and
  registryctl-generated static credential configuration.
• Hardens authorization and audit boundaries: scoped OID4VCI issuance tokens,
  nonce expiry rejection, required-filter principal binding, approval reference
  validation, break-glass emergency-class binding, and pre-mutation config-apply
  intent audit events.
• Moves RegistryStack identifiers to the owned id.registrystack.org domain
  and refreshes Notary OpenAPI/problem response documentation.
• Adds registryctl support for FHIR source-adapter sidecar Notary scaffolding,
  richer generated spreadsheet samples, and corrected generated Notary policy
  purposes.
• Reworks the docs onboarding path, trust/security pages, release-trust
  evidence, and dependency-gate descriptions for the current monorepo release
  process.
• Keeps Crosswalk as the tested pinned product input.
• Keeps Registry Atlas and the eSignet Relay authenticator held as lab-only
  external inputs.

Release Gates

The source release is expected to pass:

• release manifest validation;
• import-map audit;
• Rust workspace checks;
• Lab monorepo source proof;
• full docs checks, archive builds, SEO, and built-link validation.

The tag-driven release workflow publishes final binaries, GHCR images, image
digests, SBOMs, Grype reports, keyless cosign signatures, release capsules, and
release-level SLSA provenance. Hosted/public announcement remains a separate
gate after hosted-state proof.

RegistryStack v0.8.3

RegistryStack v0.8.3

RegistryStack v0.8.3 is a security and release-trust patch release after
v0.8.2.

Scope

• Keeps the stack release in the public registrystack/registry-stack
  monorepo.
• Adds release-level SLSA provenance generation for tag-triggered GitHub
  Releases, allowing the release workflow to publish and verify
  *.intoto.jsonl provenance for non-signature release assets.
• Fixes cargo-deny advisory checks and removes unmaintained JSON-LD test
  dependencies.
• Triages CodeQL code scanning findings in scripts, demos, and generated docs
  helpers.
• Replaces RS256 RSA verification support with AWS-LC-backed crypto in the
  platform crypto layer.
• Keeps Crosswalk as the tested pinned product input.
• Keeps Registry Atlas and the eSignet Relay authenticator held as lab-only
  external inputs.

Release Gates

The source release is expected to pass:

• release manifest validation;
• import-map audit;
• Rust workspace checks;
• Lab monorepo source proof;
• full docs checks, archive builds, SEO, and built-link validation.

The tag-driven release workflow publishes final binaries, GHCR images, image
digests, SBOMs, Grype reports, keyless cosign signatures, and release-level SLSA
provenance. Hosted/public announcement remains a separate gate after
hosted-state proof.

RegistryStack v0.8.2

RegistryStack v0.8.2

RegistryStack v0.8.2 is the fix-forward release for the failed v0.8.1
artifact workflow.

Scope

• Keeps the stack release in the public registrystack/registry-stack
  monorepo.
• Includes the v0.8.1 release preparation, release workflow hardening,
  signed-release documentation, GHCR package namespace cleanup, registryctl
  install defaults, and OpenSSF Best Practices documentation updates.
• Fixes the release-only registry-relay build failure by updating OGC API
  EDR and OGC API Features GeoJSON vertex counting for the GeoJSON 1.0
  GeometryValue API.
• Keeps Crosswalk as the tested pinned product input.
• Keeps Registry Atlas and the eSignet Relay authenticator held as lab-only
  external inputs.

Release Gates

The source release is expected to pass:

• release manifest validation;
• import-map audit;
• Rust workspace checks;
• the release-equivalent registry-relay feature build that failed in v0.8.1;
• Lab monorepo source proof;
• full docs checks, archive builds, SEO, and built-link validation.

The tag-driven release workflow publishes final binaries, GHCR images, image
digests, SBOMs, Grype reports, and keyless cosign signatures. Hosted/public
announcement remains a separate gate after hosted-state proof.

RegistryStack v0.8.0

RegistryStack v0.8.0

RegistryStack v0.8.0 is the first release from the public monorepo
registrystack/registry-stack.

Scope

• Imports RegistryStack-owned source history into one repository.
• Builds the root Rust workspace from a single lockfile.
• Keeps Crosswalk as an external pinned input.
• Adds monorepo Lab source proof.
• Generates current docs from monorepo source while archived docsets continue
  to build from historical product refs.
• Adds release manifest validation, import audit tooling, and release evidence
  hooks.

Release Gates

The source release is expected to pass:

• release manifest validation;
• import-map audit;
• Rust workspace checks;
• Lab monorepo source proof;
• full docs checks, archive builds, SEO, and built-link validation.

The tag-driven release workflow publishes final binaries, GHCR images, image
digests, SBOMs, and Grype reports. Hosted/public announcement remains a
separate gate after hosted-state proof.