Workstream K: confidential compute — attestation and conditional key release (confidential-auth-v1) #142

Workstream K — confidential compute: attestation and conditional key release

Makes the J CONFIDENTIAL policy enforceable off-chain. Depends on J (#140, 5a393ef5) and I (compute-conformance-v1). Refs #126 (closed epic; K was recorded there as future work).

Success statement. A worker does not receive confidential private input merely because it claims confidential_execution = true. Instead: valid worker session + fresh, purpose-bound challenge + acceptable attestation evidence + verified session/executor/task binding + trust and measurement policy + J policy eligible → conditional release. Any failure → no key, no plaintext input, no confidential capability, no execution start.

Scope

• Challenge model (confidential-auth-v1): fresh, unpredictable, single-use, short-lived, bound to session, executor, task and purpose (CONFIDENTIAL_INPUT_RELEASE); ephemeral off-chain state Issued → Presented → Consumed | Expired | Revoked | Denied.
• Evidence envelope (attestation-envelope-v1): format, verifier kind, bindings, window, opaque vendor payload kept separate from normalized verified claims; logs carry a hash reference, never the payload.
• Verifier interface AttestationVerifier — vendor-neutral; normalizes into VerifiedAttestation (environment type, measurement, security version, debug state, environment key, bindings, window, trust anchor). Future NVIDIA / AMD / Intel / confidential-VM adapters implement it without touching J or ComputeTask.
• Trust policy (deployment, non-consensus): accepted formats, trust anchors with revocation, measurement allowlist with revocation, minimum security version, debug policy, freshness bounds, TTLs. Rotation and revocation semantics documented; in-flight authorizations resting on a revoked anchor are revoked; already-redeemed releases cannot be undone.
• Reference attestation verifier — REFERENCE / TEST ONLY, not hardware attestation, not production confidential compute: Ed25519-signed evidence under a distinct test root (never the executor key), domain-separated, nonce/session/executor/task/purpose bound, measurement allowlist, expiry.
• J integration: VerifiedAttestation → J Evidence { level = ATTESTED, binding = CHALLENGE(session), window, verifier, reference } injected by the authority (callers cannot inject ATTESTED evidence); policy::eligible remains the final policy decision; claim-only / CERTIFIED / expired / wrong-session all fail.
• Release authorization — ReleaseAuthority (control-plane confidential authorization service): Requested → ChallengeIssued → EvidencePresented → Verified → PolicySatisfied → Released → Consumed | Expired | Revoked | Denied; single-use, TTL-bounded, bound to task/executor/session; not a bearer token (redeemed only inside the authenticated session).
• Conditional release, two separate abstractions per F §9: (A) the control plane issues the FetchInput capability for a confidential input only against a redeemed release authorization (authorize_fetch_confidential; ordinary authorize_fetch refuses ConfidentialReleaseRequired); (B) KeyReleaseAuthority (the client's delegated key service, F §11/§14) releases the client-registered content key wrapped (X25519 + BLAKE3 KDF + XChaCha20-Poly1305) to the environment key the attestation bound. The data plane stores ciphertext; plaintext exists only inside the (reference) environment.
• Named suite confidential-auth-v1, cases K01–K30, CI step Mbongo Compute Confidential Authorization printing CONFIDENTIAL AUTHORIZATION: PASS; negative-control verifiers (signature-blind, binding-blind) that the suite must catch.
• Architecture document docs/architecture/compute-confidential-attestation-key-release.md (NORMATIVE, non-consensus).

What K proves, and does not

Proven: policy-gated release; encrypted-at-rest confidential input; content key released only to the key a verified attestation bound, only after J eligibility, once per challenge, within a window; every replay / binding / freshness / trust failure fails closed; PUBLIC and VERIFIED paths unchanged; no consensus, RPC, SDK-wire, ComputeTask or Receipt change.

Not proven: provider-resistant confidentiality — the reference environment is a software process with software keys; REFERENCE_ATTESTED is not hardware attestation. Hardware-vendor compromise, TEE side channels, malicious firmware accepted by policy, host denial of service, output correctness (#52), traffic analysis and metadata observation are outside K.

Follow-up gate

Hardware Attestation Adapter — first production backend: the first real vendor/confidential-VM verifier implementing AttestationVerifier, with its own trust-root distribution and evidence format. K is not production hardware-confidential until it exists.

Success criteria

claim-only confidential fails · valid ATTESTED evidence satisfies J · session, executor, task, challenge and freshness bindings proven · replay (challenge, session, task) denied · unknown format, untrusted root, revoked root, bad measurement, verifier outage fail closed · J remains the final policy evaluator · release before authorization impossible · keys absent from chain artifacts and logs · PUBLIC flow unchanged (conformance 38/38, reference harness, v0.4 vertical) · protected blobs identical · CRITICAL = HIGH = BLOCKING_MEDIUM = 0.