[crisfiorini-oss]

Summary

A hosted environment can now supply an owner-produced managed key-service binding while retaining the existing kms and kms-wrapped custody selections. Accounts delegates provider operations to the existing key-service owner's runtime client instead of adding another cloud driver inside the Host.

The frontend payload reader now also supports Azure Container Registry using the pod's federated identity. Accounts and auth-gateway use the same shared reader.

Changes

• Add a generic adapter over the runtime client's encryption, MAC, organization-key and wrapping operations. Retain Host envelope framing and error classification.
• Preserve Ed25519 signing material and the existing signing-wrap purpose. Refuse mixed legacy/provider bindings, missing wrapped material and ephemeral fallback after managed-provider failure.
• Declare the optional non-secret configuration key and document its ownership.
• Development candidate only: the dependency replacement pins the source of service-vault #86. Replace this candidate with its owner-reviewed release before promotion; this PR is not a deployable release.

Classification: fix at the existing Host adapter boundary. The existing GCP stopgap and Vault implementation remain unchanged; provider SDK calls live below the consumer.

Build or reuse	Result
Host Sealer/KeyFactory/Cipher, wrapped-signing path, SDK accessors and existing owner gap CLI #924	Reuse all existing Host contracts and configuration projection. Extend the provider owner's runtime client; do not add a cloud SDK implementation, proxy or signing algorithm inside Accounts.

Classification of the registry change: extend the existing labelled workload-reader stopgap until the shared identity dependency in CLI #924 owns cloud credential resolution. The Azure SDK owns token exchange and renewal; the shared repository transport still restricts reads to the configured HTTPS registry, and the bundle verifier checks the admitted digest. Both services explicitly pin this development candidate; no release qualification is claimed.

Build or reuse	Result
Existing frontendpayload ORAS source and repository transport; Core/CLI registry readers; Azure SDK	Reuse the transport and bundle verifier. Core/CLI operator registry login cannot run as a pod identity; use Azure's workload identity and container-registry SDKs for that missing runtime reader instead of implementing OAuth.

Current-main compatibility

Reuse Authority's HeldInstallations service for the missing ListHeld handler instead of implementing another role/storage query. Adopt the current Authority contracts and fixture lifecycle, reuse SessionDisplayNames for fixture organization names, and regenerate the canonical protobuf/Connect/TypeScript, contract, runnable, catalog and source SDK outputs through their owning generators. The frontend SDK dependency and lockfile remain synchronized at 0.3.41.

Build or reuse	Result
Authority held-installation reads, session display names and fixture convergence	Reuse the existing service and fixture operations. Keep the Host adapter thin; do not add another authorization or naming implementation.

Testing

• Earlier applicable GitHub CI passed on dc873643435ff1bb2994f94cff40ee53c254695a. The current candidate 1e5f30a16e093a496c3e0a3b4fb29675d7761e11 also passes all applicable GitHub CI lanes, including Naming records. Release-only publication, notification and landed-identity lanes are skipped on the pull request.
• The three previously failing Host conformance cases now pass locally: fixture member reads, organization display names and installation acknowledgement permissions.
• Earlier focused frontend-payload and key-service tests, key-service vet, naming, boundary and whitespace checks passed. The provider owner's controlled Azure SDK tests cover the underlying key operations.
• Native generation completed for all changed generated artifacts; no generated output was hand-edited. The final 1,411-line diff includes 746 generated lines in dedicated directories marked for collapsed review. Authored inputs, configuration and dependency files remain visible.

Deployment qualification

The managed-key dependency remains the explicitly identified development candidate from service-vault #86, including the corrected Managed HSM GCM nonce behavior. Adopt an owner-reviewed release and qualify the projected binding, workload grants and recovery behavior before promotion. No live managed backend, complete hosted application acceptance or module release is claimed. The shared dependency-kind work in codefly-dev/cli#924 remains open.

Azure frontend download correction

Accounts was withholding Wiki and Proposals because the Azure frontend reader rejected ACR redirects to the same registry’s dedicated regional data endpoint. The reader now admits HTTPS downloads from that endpoint with no bearer credentials, while refusing foreign registries, ports, methods and credentialed download requests. Both consumers pin the patched library candidate.

Build or reuse: extend the existing Azure SDK BlobClient and shared frontend payload verifier; no second downloader or authentication implementation. The regression test fails against the original transport, and the frontendpayload tests pass with the fix. Live rollout evidence is recorded separately.

Redirected storage response headers

Extend the same shared Azure SDK reader to accept a redirected storage response that omits the registry-specific Docker-Content-Digest header. A supplied conflicting digest remains refused, and preparation still verifies the entire downloaded archive against the signed digest and its existing size bounds. Both host consumers pin immutable reader candidate d67666b.

Validation: frontendpayload package tests pass. The header-absent regression fails before this correction and succeeds after it; tampered payload bytes remain rejected. Live deployment acceptance: Accounts and auth-gateway rolled out successfully; the consuming solution frontend manifest and its 122454-byte remote entry both returned HTTP 200 after previously returning 404. Fresh bounded runtime logs contain no frontend-preparation refusal. Authenticated organization catalogue, document upload and chat were not exercised.

Source review (2026-10-28)

Independent source review of 1e5f30a16e093a496c3e0a3b4fb29675d7761e11 found no new actionable code defects. The review checked existing provider-owner and shared payload-reader reuse; it did not exercise live key-service federation, registry access or deployment. Development-candidate release requirements above still apply.