railiance-platform/docs/playwright-identity-handoff.md

Playwright consumer identity activation handoff

Status: source prepared; owner activation and real human/agent evidence pending. The user already admitted all identified platform humans and coding agents. This handoff implements ADR-0006 without inventing registration acceptance, distributing admin kubeconfigs or broadening other service credentials.

Custodian coordination request

Requested outcome: Enable self-service Playwright access for identified platform humans and coding agents. The user authorized sending this cross-repository delivery request on October 13. The Custodian is asked to establish one accountable coordinator and link the existing implementation tasks and owner requests to a source-backed delivery task. Platform acceptance remains RPF-WP-0056-T03; the coordination request must preserve the existing owner responsibilities and evidence.

Sent to the-custodian through State Hub on 2026-10-13 at 19:31 UTC: 1b279bad-a159-43da-8709-1167882e62f8. Delivery is confirmed; coordinating-owner acceptance and source task references remain pending in RPF-WP-0056-T06.

Requirements:

1. All identified platform humans and coding agents initially qualify for playwright-consumers. Their existing identity owners establish identities; no further membership policy decision is needed from the user.
2. A consumer can follow documented onboarding, authenticate, and use one command to connect and run a UI trial without operator assistance for each use. Include renewal, actionable failure messages and cleanup. The current setup helper is an implementation input; a complete single-command experience remains to deliver.
3. Humans use platform login. Each coding agent uses its own registered identity and governed credential delivery. No shared administrator kubeconfig or shared workstation SSH identity is part of consumer onboarding.
4. Preserve the existing namespace-scoped permissions and approved target boundary. Broad initial eligibility does not grant Secrets, pod exec, workload mutation, other namespaces or additional browsing targets.
5. Provide supported onboarding, renewal and revocation, including how to terminate active connections and what remains usable until token expiry.
6. A real human and a real coding agent independently complete identity verification, permission checks and responsive/keyboard browser trials using the supported consumer instructions. Native wrong-audience, missing-scope, expired/tampered token and ineligible-identity attempts fail. No administrator impersonation or synthetic token test substitutes for these acceptance receipts.
7. Platform and rapp-playwright accept the receipts, publish the consumer instructions and update managed availability/discovery. Completion means the consumer flow works, not merely that the coordination messages were delivered.

First delivery should finish the prepared scoped port-forward route, including supported per-caller API transport. Keep the user-facing requirements independent of this transport so an existing shared platform access mechanism can replace it later. A new access gateway is not required for this first delivery.

Requested Custodian return: coordinating owner; source workplan/task identifiers; linked owner tasks and their dependency order; first executable milestone; and any specific unresolved decision. Registration, custody and transport implementation gaps should be assigned to owners rather than returned as another membership approval question. Do not claim owner acceptance until their responses exist.

Existing implementation follow-ups: railiance-cluster 0c1023ce-86ac-404a-842e-2f7e1a6d90f1, KeyCape 85bf4765-35cc-418f-903b-2dba64e8a06b, NetKingdom c6b4dfb0-44d5-4f12-8854-2c38ab6dc454, ops-bridge c367f3a2-ceba-4ec9-b241-b917c47ba11e, rapp-playwright 8d1de2a9-5209-4f82-a2cd-80d8c2e07001.

Implementation inputs and owner responsibilities

Owner	Concrete change	Required return
railiance-cluster	Review and integrate config/playwright/authentication-config.candidate.yaml into the K3s API-server configuration	Native config validation, rollout/recovery receipt, preserved existing authentication, real allowed/denied requests
key-cape / net-kingdom	Review and register config/playwright/keycape-public-client.candidate.json; dedicated per-agent confidential registrations	Exact claim/expiry contract, issuer rollout, registration and custody references without values
ops-bridge / cluster access owner	Supported per-caller TLS API route on local port 16444	Human and agent transport instructions using their own identities
railiance-platform	Run scripts/playwright_consumer.py verify and provider trials for both identity kinds	API-returned identity, permission negatives, responsive/keyboard trial receipts
rapp-playwright	Review native consumer receipts and update managed availability	Accepted RAPP-PLAYWRIGHT-WP-0004-T01/T03 and declaration/registry evidence

Coordination requests sent October 13: cluster f643ce05-b71d-4492-83a3-ae142d0d3535, KeyCape 60b22d25-a573-4957-aaae-3a66f5713466, NetKingdom 94a0096c-f34c-463c-b336-b13cf629b968. No reply had arrived when preparing this source. Owner source/activation receipts remain necessary.

The candidate uses issuer https://kc.coulomb.social, dedicated audience playwright-kubernetes, access scope playwright:connect, and a constant mapped group playwright-consumers. Subjects become keycape:human:<sub> or keycape:service:<sub>. KeyCape represents registered coding agents as service principals with the coding-agent role. Other services fail this mapping; token groups cannot inject Kubernetes privileges. Human tenants are not rewritten or restricted to tenant:platform. Dedicated registrations determine who can obtain this audience and scope.

The public client uses exact PKCE callback http://127.0.0.1:18764/callback. Native KeyCape login verifies issuer/JWKS, scope, audience, state and nonce. Use its access token: ID tokens have client audience and no access scope. Human lifetime inherits issuer settings; confirm it is at most one hour before activation. Do not add per-client tokenLifetime to the public client: KeyCape supports that override only for client-credentials registrations.

Each coding agent needs a distinct new client registration with the dedicated audience/scope, unique service subject, coding-agent role, its actual registered tenant and preferably 15-minute lifetime. Its new secretRef must have an existing governed custody/delivery contract before activation. No existing OpenBao client secret or audience is reused. The browser-RP registration helper's accepted HTTPS/standard-scope type does not cover this loopback/custom-scope client; its case-acceptance requirement cannot be satisfied by fabricating a receipt.

Cluster integration must preserve unrelated authenticators and the SSH/admin recovery route. AuthenticationConfiguration is an API-server file, not a resource accepted by kubectl apply. Review existing K3s flags and config fragments, natively validate CEL against the deployed Kubernetes version, establish rollback before activation, and coordinate any required single-node API-server restart. The source candidate has not been compiled by Kubernetes or applied. Source: Kubernetes 1.35 authentication configuration and exec plugins.

Before availability is published, prove wrong audience, missing scope, expired token, tampered signature, ordinary service and nonmember refusals at the native API. The helper's synthetic tests do not establish those server-side properties. Prove positive human and coding-agent access via SelfSubjectReview, permission checks and browser trials, with no --as impersonation. Client disablement stops issuance; issued JWTs remain valid until expiry, and existing port-forwards need explicit termination. Keep the provider availability tasks open until those receipts are accepted. Existing operator-driven pilot/restart evidence remains valid with its documented limits.