Platform acknowledges ADR-0039 and approves a policy-bound Vercel OIDC exchange for Delivery-to-Revenue service authentication
Platform position
Platform acknowledges ADR-0039. The root mint secret and signing key belong only inside Platform's issuer boundary. A consumer runtime must not be able to choose an arbitrary subject, audience, tenant, lifetime, or scope merely because it can call the token route.
The current Platform route accepts the root secret and caller-supplied tenant_id, subject, audience, and lifetime. That shape is suitable only for tightly controlled issuer administration and migration smoke tests. It is not an acceptable application credential surface. The proposed workload exchange is the right replacement.
Vercel OIDC confirmation
Platform confirms that a Delivery production deployment can be bound to its Vercel team, project, and production environment. Platform will verify the Vercel signature through the team-scoped JWKS and require exact issuer, audience, and subject values, plus valid issued-at, not-before, and expiration bounds. The Vercel subject encodes owner, project, and environment, so the initial policy can map that one exact workload to sub: system:delivery, aud: revenue, tenant_id: tnt_sguild, the ratified Delivery scopes, and a five-minute maximum Platform-token lifetime.
The workload proof must use a Platform-specific Vercel OIDC audience, not the default team-wide audience. Vercel supports custom OIDC audiences while preserving the project, environment, owner, and expiration claims. Binding the proof to the Platform exchange prevents a Vercel token issued for another downstream service from being replayed here.
The client may identify the target capability requested from a policy allowlist, but it may not supply authoritative output claims. Platform's server-side policy remains the only source for subject, permitted audience, tenant and organization reach, scopes, and maximum lifetime.
Contract requirements
The service-auth contract will make the Platform JWT and the enforcement split explicit. The token will carry issuer, audience, subject, tenant, scope, issued-at, not-before, expiration, and a unique token identifier suitable for audit correlation. The contract will define the scope vocabulary jointly with Revenue before the production policy is enabled.
Platform authenticates the calling workload and constrains its maximum authority. Revenue remains responsible for endpoint authorization and for checking that each requested Revenue resource belongs to an organization the authenticated Delivery workload may access. A broad service scope is not permission to act on an unrelated customer, organization, reservation, invoice, or payment method.
Platform will record issuance metadata without logging bearer tokens. The audit record will include the workload policy identifier, resolved subject, audience, tenant and organization reach, scopes, token identifier, issuance time, expiration time, result, and a non-secret reason code for denials.
Callers may cache the returned Platform JWT only in process memory and must refresh before the five-minute expiry with a safety margin. Repositories, local env files, databases, logs, and browser storage must not persist either workload proofs or issued service tokens.
The operator command will authenticate through an operator-controlled Platform path and emit a short-lived bounded bearer for the process that needs it. It will not expose or read the root mint secret. One-shot scripts must fail closed when no bearer or supported workload proof is present.
Sequencing
Platform will publish the contract, then deploy the additive exchange while the current route remains available only for the bounded migration. Delivery can then migrate and prove its ordinary Revenue client and audit paths. Revenue can add subject and scope enforcement without weakening its existing issuer, audience, tenant, and expiration checks.
The root secret rotates only after every inventoried consumer has migrated or retired its root-mint path and Revenue declares event:revenue-service-auth-enforcement-ready. The known consumer gates are Delivery migration, Sales migration, and retirement or migration of Revenue's operator and staging callers. Platform will then repeat the inventory, remove the consumer-facing root-mint integration path, and update the canonical service-auth documentation. No new consumer receives the current root secret during this window.
Platform's acknowledgment is complete. Revenue's independent decider acknowledgment remains the final ADR approval needed before ADR-0039 moves from Proposed to Accepted.
On 2026-08-02, after the aggregate readiness event cleared, Platform repeated the complete caller and environment inventory, rotated the Platform-owned root mint secret, retired the legacy mint and smoke routes, proved the prior secret failed, and re-proved current Sales and Delivery workload authorization in production. The final evidence is recorded in 2026-08-02-platform-adr-0039-root-mint-retirement-closeout.
References
- ADR-0039:
adrs/ADR-0039-platform-issued-workload-identity.md - Delivery proposal:
2026-07-30-delivery-adr-0039-workload-auth-proposal - Current Platform issuer module:
modules/service-auth/ - Vercel OIDC API verification:
https://vercel.com/docs/oidc/api - Vercel custom OIDC audiences:
https://vercel.com/changelog/custom-oidc-token-audiences