feat: harden and expand extension service authentication after alpha

Problem Statement

Issue #2623 and PR #2638 provide the alpha extension-authentication mechanism needed for middleware and gateway-interceptor integrations: shared client transport primitives, gateway-minted exact-audience bearer tokens, supervisor credential distribution, custom CA support, and well-known public-key endpoints.

The alpha slice intentionally defers service-side SDKs, adoption by remote drivers, independent signing authority and rotation, stronger replay defenses, additional service authentication methods, and runtime lifecycle management. These follow-ups need one tracking issue so later implementations preserve a common trust model instead of diverging across extension types.

Parent design: #2430. Alpha implementation: #2623 and PR #2638. Sandbox token typing migration: #2753. Existing sandbox-JWT online rotation work: #1510.

Proposed Design

Deliver the post-alpha work as independently reviewable phases that continue to share protocol-neutral primitives while keeping subsystem orchestration with its owner.

1. Service-side verification SDKs

• Provide supported verification SDKs for extension authors, with Rust and Python first.
• Implement the documented verification contract: authenticated trust bootstrap, pinned EdDSA algorithm, exact typ, kid, signature, issuer, exact audience, positive expiry, caller kind, and supervisor sandbox identity.
• Include safe JWKS refresh, cache behavior, actionable errors, and framework-neutral middleware/interceptor examples.
• Keep verifier code outside openshell-extension-core; package it as extension-building SDK functionality that can later move to a separate repository if useful.
• Until the SDKs ship, retain the documented contract and authenticated middleware example as the reference implementation.

2. Remote driver protocol adoption

• Reuse the shared extension authentication and TLS mechanisms when remote compute-driver and credential-driver protocols define their network-authentication contract.
• Add no compute-driver or credential-driver authentication enum variants before those protocol contracts exist.
• Define caller identity, audience ownership, credential distribution, transport requirements, and authorization independently for each driver protocol before wiring in the shared primitives.

3. Independent signing authority and rotation

• Separate extension signing authority from sandbox admission authority, including distinct keys, kid namespaces, JWKS representation, storage, loading, and operational lifecycle.
• Support overlapping active and verify-only keys for zero-downtime rotation.
• Coordinate shared multi-key/JWKS infrastructure with #1510 without coupling extension-key rotation to sandbox-token rotation.
• Define HA rollout, rollback, cache lifetime, and compromised-key retirement behavior.

4. Replay resistance and revocation

• Evaluate request binding, TLS channel binding, and proof-of-possession credentials against gateway-to-extension and supervisor-to-middleware call paths.
• Select a mechanism only after defining proxy/load-balancer compatibility and what request material can be bound consistently.
• Add explicit revocation only if the threat model requires invalidating credentials before their short expiry; define storage, propagation, outage behavior, and HA consistency first.
• Preserve short lifetimes, exact audience, explicit token type, and unique token IDs as baseline controls.

5. Trust bootstrap and JWKS refresh

• Treat operator-provisioned public key or JWKS material as the authoritative cold-start trust anchor.
• Treat gateway well-known endpoints as steady-state refresh and operational convenience only after gateway identity and TLS trust are established.
• SDKs must never infer gateway identity merely from the location serving discovery or JWKS.
• Document key replacement, unavailable refresh endpoints, stale-cache behavior, and recovery.

6. Service authentication and lifecycle hardening

• Evaluate mTLS client authentication for OpenShell callers in addition to bearer authentication, including certificate issuance, delivery, rotation, and identity mapping.
• Add extension health checks with clear readiness/degraded/fail-open/fail-closed semantics.
• Design runtime registration only after static registration has been exercised by users; define registration authorization, persistence, reconciliation, removal, and audit behavior before adding APIs.
• Preserve Unix-domain-socket support and its local filesystem trust boundary where applicable.

Sequencing

1. Ship verification SDKs and formalize cold-start/refresh behavior so integrations have a supported service-side contract.
2. Gather integration feedback from middleware and interceptors.
3. Define driver-specific authentication contracts before adopting the shared mechanism.
4. Separate signing authorities and add overlapping-key rotation, coordinating with #1510.
5. Add replay/revocation and mTLS/lifecycle hardening according to observed threat and operational requirements.

The phases may become focused child issues when scheduled. This tracker should retain the shared invariants and dependencies.

Alternatives Considered

• Expand PR #2638: rejected because the alpha mechanism is nearly ready and these items have independent API, deployment, and operational decisions.
• Put service-side verification in openshell-extension-core: rejected because that crate is client transport/token-distribution infrastructure shared by OpenShell callers, while verification is consumed by extension implementations and should be independently extractable.
• Add driver enum variants immediately: rejected because a shared mechanism does not define a driver protocol's caller identity or authorization contract.
• Make gateway JWKS discovery authoritative for first contact: rejected because an unauthenticated first fetch cannot establish gateway identity; operators already need an out-of-band trust channel.
• Require mTLS immediately: rejected for the alpha integration slice because certificate issuance and per-runtime secret delivery require broader operational design.

Definition of Done

• Supported Rust and Python service-verification SDKs implement the documented contract and refresh behavior.
• Middleware and interceptor examples use or demonstrate the supported SDK boundary.
• Remote driver adoption occurs only through reviewed protocol-specific authentication contracts.
• Extension and sandbox admission signing authorities are separate.
• Multi-key overlap enables zero-downtime extension-key rotation.
• Replay-resistance and revocation requirements have a documented threat-model decision and any selected mechanism is implemented and tested.
• Cold-start trust and steady-state well-known endpoint behavior are implemented consistently in SDKs and deployment documentation.
• mTLS client authentication has a concrete disposition and, if selected, operational certificate lifecycle support.
• Health-check and runtime-registration contracts are defined and implemented if user feedback justifies them.
• Security-sensitive diagnostics and tests cover failure, rotation, stale trust material, and mixed-version behavior.

Agent Investigation

Searched existing issues for extension verification SDKs, driver authentication, signing-authority separation, key rotation, replay protection, proof of possession, revocation, mTLS, health checks, runtime registration, and JWKS bootstrap. No issue covers this complete post-alpha program. #1510 covers online rotation for sandbox admission JWTs and should provide or share multi-key infrastructure, but it does not separate or rotate extension signing authority. #2753 covers explicit sandbox-token typing and its rolling-upgrade migration, not these extension follow-ups.

Read the parent design #2430, alpha issue #2623, PR #2638, sandbox rotation issue #1510, and the openshell-extension-core boundary first. No specific files or tests are named; split the broad phases into focused child issues, with completion judged against the Definition of Done and its security, rotation, trust, and lifecycle requirements.