Platform ADR-0052 position and required authority decisions
Position
Assignment ADR-0052/platform/001; coordinator 01a0e095-f279-7fd0-a8ef-92ce8f9547fc, host local; participant 01a0ff07-c6a3-7000-81a3-94f9960a4513. Platform supports separate workload policies for durable scheduling, but withholds acknowledgment of ADR-0052 until the decisions below are explicit. This memo grants no implementation, issuance or activation authority and creates no implementation commitments.
Bootstrap already supports a bounded synchronous human path: require signed-in user, exact tenant, exact active Organization, present membership with disabled === false, and an owner-agreed scheduling role. /api/auth/session, operator app access, SuperAdmin status and bootstrap tenant alone do not establish that permission. Independently verifying an unpersisted cookie at each hop can suffice only while a current human session exists. It cannot satisfy unattended recovery after session expiry. No new human-session interface is needed for that narrower case; durable workload authority requires this separate decision.
Required contract changes
Add two isolated policies to service-auth, preserving every existing selector, default, operator command and scope set:
| Proposed policy ID | Selector and sole scope | Output subject | Audience | Only authorized method/path |
|---|---|---|---|---|
sales-production-to-delivery-scheduling-soft-hold-v1 |
delivery.scheduling.soft-hold.create |
sales |
delivery |
POST /api/v1/delivery/v1/lesson-holds/soft |
revenue-production-to-delivery-scheduling-bind-v1 |
delivery.scheduling.reservation.bind |
system:revenue |
delivery |
POST /api/v1/delivery/v1/lesson-holds/bind |
These selectors do not collide with published service-auth v1.7.0 or the inspected policy vocabulary. Revenue is a new workload caller and output subject, not an extension of Delivery's default policy. Do not let an unhandled selector fall through to that default. No scheduling read, generic hold-create, cancel, closure, participant ensure, financial operation or Coaching access is added.
Both policies should pin proof issuer https://oidc.vercel.com/jack-allreds-projects, team JWKS, RS256 and scalar proof audience https://platform.sguildswim.com/api/auth/service-token/exchange. Sales proof subject is the existing approved owner:jack-allreds-projects:project:sales:environment:production. Proposed Revenue proof subject is owner:jack-allreds-projects:project:revenue:environment:production, requiring Revenue confirmation and actual production exchange proof before readiness. Source naming or environment configuration alone does not verify that identity. Pin output issuer https://platform.sguildswim.com, scalar audience delivery, tenant tnt_sguild, exactly [org_01900000-0000-7000-8000-000000000001], the single scope above, UUID jti, integer time claims, nbf = iat, and 0 < exp - iat <= 300. Allow at most 30 seconds clock tolerance. Missing claims, audience arrays containing a matching audience, aliases, absent-org defaults and preview/dev proofs must not satisfy the policy. Exchange inputs select policy only; output claims cannot be widened by submitted fields.
Delivery must reauthorize the exact route and canonical resource predicates before domain writes or idempotent receipt lookup. A request's org, actor, caller-domain header and reservation ID are not independent proof. Bind acceptance needs an agreed authoritative mechanism showing Revenue's exact order/reservation/lesson association, matching tenant, Organization and Participant, valid reservation state, and admissible lesson state. Owners must specify that mechanism, freshness and unavailable-evidence behavior. A generic Revenue service identity plus caller assertions is insufficient; Platform will not invent a new read scope or resource credential to fill the gap.
Amend scheduling section 8.5 to accept these workload policies on exactly these two routes while retaining its existing human-session requirement elsewhere. Publish an additive service-auth minor version, proposed v1.8.0 if v1.7.0 remains current, with Revenue added as workload caller. Delivery must name the scheduling version and classify any required wire changes; resource-proof fields and changed idempotency fingerprints cannot be called compatible without analysis. Pin rollout/admission gating and owner-approved handling of old callers. No permissive no-auth fallback is acceptable.
Revocation, recovery and errors
The proposal's fresh exchange for every send/recovery conflicts with service-auth section 8's reusable in-memory JWT cache. Recommend an explicit scheduling-policy exception: obtain a newly audited token for each outbound attempt, never persist or reuse the prior bearer, proof or cookie. If issuance is unavailable or policy is disabled, preserve the saved request/key and pending outcome; do not send or infer noncommit. Recovery replays unchanged business bytes/key, with current resource authorization before revealing any historical receipt.
Disabling issuance alone does not revoke already issued JWTs. Existing offline verification allows their remaining lifetime and clock tolerance. State this bounded residual window explicitly, or approve a concrete producer-side policy disable/revocation mechanism if immediate rejection is required. Do not claim instant revocation from token refresh rules. Human session expiry is distinct from human membership revocation: owners must decide whether revoking the initiating operator affects previously admitted durable work, and how cancellation or reauthorization is represented. Platform's workload token proves service authority, not current human membership.
Keep audit-before-return and Cache-Control: no-store on all exchange responses. Issuance audit records policy, subject, audience, tenant, exact org/scopes, UUID, times and request ID; consumer authorization records correlate UUID, exact operation and hashed idempotency key. Audit failure returns no bearer. Never log proofs, bearer, cookies or secrets. Audit provenance does not become an authorization claim.
Use service-auth section 6: 400 BAD_REQUEST for unknown selector or invalid exchange input; 401 UNAUTHENTICATED for missing/invalid/expired proof or JWT and exact issuer/audience/expected-subject mismatch; 403 FORBIDDEN for valid authentication with disallowed tenant/org/resource; 403 INSUFFICIENT_SCOPE for absent required scope; 500 for issuer/signing/audit failure. Clarify the existing table's overlapping subject wording in the new route map. Retain nondisclosing resource failures and existing state/idempotency conflicts; define linkage-evidence outage behavior explicitly and leave the operation pending. Authorization denial must cause no business persistence, dispatcher event or external effect; security audit is permitted.
Acceptance criteria
- Revised ADR and exact service-auth/scheduling maps settle identities, resource evidence, human revocation, residual JWT validity, rollout and version compatibility; all named owners approve their own positions before implementation.
- Platform later proves actual Sales and Revenue production exchanges, exact output claims, separate single-scope policies, wrong-selector/caller/issuer/audience/preview denials, audit-before-return failure and no-store. Existing closure, Coaching, operator and default-policy regressions remain unchanged.
- Delivery later proves both real routes: exact-resource success; missing/malformed/expired/future/overlong/missing-claim tokens; wrong audience/subject/scope/tenant/org; canonical resource mismatch; denied replay without receipt disclosure; and no business persistence or effect on denial. Issuer/resource-evidence outage and agreed revocation behavior fail safely.
- Sales and Revenue later prove unchanged saved request/key after response loss, fresh exchange per attempt, no persisted credentials, and authorized durable recovery after human-session expiry. Coaching substitutes and local proof remain separately labeled; deployed readiness requires separate evidence.
Reviewed sources and publication
Canonical checkout HEAD was 2ac56cfb4de72b1725bf522d537b5bec16ba0ea6. Reviewed ADR-0052 SHA256 040c11e2fa3f992eb8638f2f2a34dc51d227cc4775e54b196a1ab0ef2acb8cad; approval request SHA256 b93bb5f904d096a89e381a16e33e2207c340242efc8ad472e6ad70e9044a7d4f. Canonical bases: ADR-0001, ADR-0036, ADR-0039, service-auth v1.7.0 sections 3-8, and sales-scheduling-surface v1.12.0 section 8.5.
The clean Platform proof checkout is 8f877adca494d1fd23cc404cf64423d06a35565d; reviewed docs/adr0050-scheduling-session-boundary.md SHA256 a7f04b4ac34c1c155d1a725db34851cc5f69e2c9627c11d1db39bdeef9f8d558, bootstrap and service-auth sources. Cross-domain audit pins are Sales d31ddf1a4bd233c3d4e2714350452de8b7cbc878, Delivery 75589fa499b3c62ef94ef5702d5470c4781a1059, Revenue 5f10755c031897b6598a051f915c6864ee0901e1; spot-checked pinned Sales soft-create, Revenue bind client and Delivery route mount. These are source findings, not deployed exposure evidence. Primary Platform checkout is dirty with unrelated work, so it is not the reviewed release candidate.
Live Platform inbox and ledger were read on 2026-10-02; no ADR-0052 commitment requiring completion was found. This exact memo is prepared for the coordinator's collected batch, with no independent commit, push, indexer or freshness run. The coordinator must index and verify freshness after the final batch. The referenced engineering:architecture skill was not present in the available skill catalog or searched local skill/plugin trees; this review uses the canonical repo instructions and contracts directly.