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`. 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:<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](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.