Delivery proposes ADR-0039 to replace distributed Platform mint secrets with scoped workload identity
Why
Delivery's lock audit failed because local configuration contained two
differently named mint-secret values and an unrelated Revenue client URL pointed
at localhost. Inspection then confirmed the larger boundary problem: Delivery's
Vercel production environment contains MintSecret, and the shared Revenue
client can use it to ask Platform for an arbitrary Revenue-audience service
token.
The root secret belongs to Platform's issuer boundary. Revenue should verify Platform-issued JWTs through issuer and JWKS configuration, and Delivery should present its own workload identity. Copying the correct root value into another Delivery variable would make the audit run but would preserve the architectural defect.
Delivery correction implemented and verified
Delivery changed audit:locks to require an explicitly supplied short-lived
REVENUE_LOCK_STATE_BEARER. The audit no longer reads any Platform mint-secret
variable and no longer inherits the ordinary Revenue reservation-client URL.
Delivery also corrected the state comparator to use the published boundary
mapping. Delivery confirmed maps to Revenue's held lock-state wire value,
and Revenue forfeited maps to Delivery's released terminal scheduling state.
With a one-time system:delivery, Revenue-audience token supplied only to the
process, the production audit compared 45 Delivery rows with 45 Revenue rows and
returned zero drift in every bucket.
This correction does not remove MintSecret from the deployed Delivery app.
The ordinary Revenue client still depends on it for invoice, credit,
payment-method, and settlement calls. Removing it before replacement would
break operator workflows.
Proposed decision
ADR-0039 makes Platform the sole holder of service-JWT signing material and the root mint secret. Vercel-hosted callers use Vercel OIDC as workload proof for a Platform exchange. Platform binds subject, target audience, tenant reach, lifetime, and scopes through server-side policy. A non-Vercel caller may receive a domain-specific exchange credential, never the root secret.
Revenue enforces subject and scope as well as issuer, audience, expiration, and tenant. Delivery migrates every Revenue call, proves production behavior, removes its mint-secret fallbacks, and removes the secret from Vercel. Platform then rotates the root secret so distributed historical copies stop working.
Asks
Platform, please acknowledge ADR-0039 or reply with the smallest policy-bound exchange shape Platform can own. Please confirm whether Vercel OIDC can be validated against the Delivery team, project, and production environment and exchanged for a five-minute Platform service JWT.
Revenue, please acknowledge ADR-0039 or identify required changes. Please confirm the initial subject and scope enforcement needed across the Delivery-consumed Revenue APIs.
Delivery acknowledges the proposed decision in this memo. Delivery will not remove the deployed root secret until the exchange is live and the current financial and settlement paths pass production verification.
References
adrs/ADR-0039-platform-issued-workload-identity.mdadrs/ADR-0036-operator-auth-rail-for-domain-web-apps.mdcontracts/credit-reservation-lock/delivery-state-vocabulary.md2026-05-14-platform-revenue-service-jwt-production-smoke-passed- Delivery
scripts/audit-locks.mjs - Delivery
lib/revenue/reservation-client.ts