Platform action requested before ADR-0039 root rotation can become ready

Revenue asks Platform to correct ADR-0039's execution gate before treating event:service-auth-root-rotation-ready as sufficient authority to rotate the root mint secret or retire the consumer-facing root-mint route.

Current state

Delivery has completed its workload-auth migration and correctly cleared event:delivery-workload-auth-migration-ready. Revenue has not cleared event:revenue-service-auth-enforcement-ready; the current Revenue deployment still needs exact subject, Organization reach, operation-scope, issuance-bound, and JTI enforcement plus the contract's resource-server authorization audit.

Separately, Sales remains an active root-mint consumer. Its Revenue clients use lib/platform/service-token-client.ts to present PLATFORM_SERVICE_JWT_MINT_SECRET or SERVICE_JWT_MINT_SECRET to Platform's consumer-facing mint route and request sub: sales Revenue tokens. Sales calls shared Revenue reservation, coverage, order, and release routes that cannot lose authentication during Delivery's enforcement cutover.

The service-auth contract requires rotation only after every known consumer has migrated and after Revenue removes all no-scope compatibility. The current all-of definition names only Delivery migration and Revenue enforcement, so it does not encode the full accepted rotation condition.

Platform actions requested

First, inventory every current production, preview, cron, and operator caller of the root-mint route and identify all environments that hold the root mint secret. The inventory must explicitly include Sales and should distinguish active consumers from stale secret copies.

Second, amend the rotation-readiness event or its gating commitment so the root secret cannot rotate until every active consumer has a production-proven policy-bound replacement. For Sales, that means a distinct Platform workload policy with fixed sub: sales, aud: revenue, tenant and Organization reach, five-minute maximum lifetime, exact Revenue scopes, and issuance audit. It must not inherit or broaden Delivery's policy.

Third, publish the resulting Sales policy and migration sequence to Sales and Revenue for scope review. Revenue will map the approved Sales scopes to the shared routes while preserving exact system:delivery authorization on Delivery operations.

Finally, after Revenue publishes event:revenue-service-auth-enforcement-ready and every inventoried caller has completed production proof, rotate the root secret, retire the consumer-facing route, and prove that Delivery and Sales still succeed while historical secret copies fail.

Revenue position

Revenue's readiness event remains an independent Revenue decision based on deployed verifier, route-policy, denial, and authorization-audit evidence. This memo does not add Sales migration to Revenue's implementation scope. It asks Platform, as issuer and root-secret owner, to make the rotation gate represent the contract's actual all-consumer condition.

References

• adrs/ADR-0039-platform-issued-workload-identity.md
• contracts/service-auth/README.md
• 2026-07-30-platform-adr-0039-workload-identity-ack
• 2026-08-02-delivery-adr-0039-workload-auth-migration-ready
• 2026-08-02-revenue-adr-0039-root-rotation-gate-correction