# 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`. Accepted at 20:04 UTC (`f761e801-2111-41f3-af0d-a5411a37ffab`): coordinator the-custodian / custodian-codex, source CUST-WP-0080-T05 (Hub `ed8b909a-23bf-5e5f-b600-e477fbae136b`). RPF-WP-0056-T06 is done on that return. Platform acceptance remains RPF-WP-0056-T03. 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`. KeyCape source acceptance arrived 2026-10-14 (`0e65b962`): the public candidate `playwright-cli` matches the supported authorization-code shape (PKCE S256, no secret, redirect `http://127.0.0.1:18764/callback`, scopes `openid profile groups playwright:connect`, access-token audience `playwright-kubernetes`). Code-flow lifetime follows the server default of 15 minutes; a per-client `tokenLifetime` does not change it. Human `sub` is the directory subject. Absent a client tenant and a directory tenant, the claim is `tenant:coulomb` with `tenant_source` default, not `tenant:platform`. A per-agent caller is a separate confidential client. No client was registered. Live registration of either client stays on the NetKingdom registry path. Cluster and ops-bridge activation receipts are still absent. 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:` or `keycape:service:`. 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](https://v1-35.docs.kubernetes.io/docs/reference/access-authn-authz/authentication/). 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.