key-cape/workplans/KEY-WP-0042-online-access-token-status.md

id	type	title	domain	repo	status	owner	topic_slug	created	updated	flavor	depends_on	state_hub_workstream_id
KEY-WP-0042	workplan	Provide issuer-owned current access-token status and scoped revocation	infotech	key-cape	proposed	codex	custodian	2026-10-18	2026-10-18	extension		e2eecd1c-45c7-5a7c-bd1c-d31c845e3d38

CUST-WP-0080's current-operation/inverse requirement exposed a concrete missing issuer facility. KEY-WP-0025-T03 truthfully documents the expiry-only limit; KEY-WP-0038 owns Forgejo's existing client, not a token-liveness API. This is an explicit proposed scope extension in the existing issuer, not a silent change to that completed limit record. No new service or duplicate session authority. Consumer binding/authorization and native case acceptance stay in NK-WP-0048-T34/T42/T43 and RAPPS-WP-0016-T08/T09; they are not copied here.

Review the bounded issuer/profile extension

id: KEY-WP-0042-T01
status: progress
priority: high
state_hub_task_id: "d8af8e77-f6e5-5d0d-8b44-794af3dee5cf"

The reviewable contract is docs/online-token-status.md: opt-in RFC 7662/7009 access-token status; registered owning-client authentication; private hash-only bounded state; unique access-token jti; online human ID-token exact at_hash binding with the disabled legacy ID-token contract unchanged; singleton store-loss refusal; disabled legacy behavior explicit. Source preparation is authorized by the full Custodian implementation goal. Independent issuer/profile/consumer assent remains required before admission; no such assent is inferred here.

Implement and verify the actual issuer paths

id: KEY-WP-0042-T02
status: done
priority: high
state_hub_task_id: "2cade51f-d25a-5719-96b4-b57d50c1b97d"

Wire the same issuer store to both actual grant types, UserInfo, introspection, revocation, configuration validation and implemented discovery. Verify distinct grants, exact expiry, replay/tombstones, capacity, malformed/unauthenticated and cross-client refusals, current registration and human disposition, revocation during directory lookup, process-store loss and absence of secret output. Keep the complete existing source suite, disabled profile and build passing.

2026-10-18 T02 source continuation: the actual consumer join exposed missing same-grant correspondence. The online human ID token now signs the exact access token's RS256 at_hash, retaining its own audience and excluding access-only fields. Distinct same-second grants cannot share that binding; disabled issuance is unchanged. This qualifies the earlier unscoped "no ID-token change" statement for the proposed online profile, without changing existing deployment behavior. The complete source race suite passes 726 test/subtest results with the same six native/external skips. The actual HTTPS PKCE/discovery/UserInfo/status/revocation handlers and real Forgejo provider/callback pass five separate consumer processes: two current grants accepted, mixed grants/revoked original/suspended human refused. The original issuer fails the same current consumer. MFA session seeds and PDP admissions are synthetic. Source-only evidence: Custodian forgejo-current-token-r1. Independent issuer/profile/consumer review and T03 native admission remain open.

Admit and accept the issuer lifecycle at native scope

id: KEY-WP-0042-T03
status: todo
priority: high
state_hub_task_id: "a5539bb0-2501-5774-a7d8-acddfb0938ab"

After independent contract review, admit exact issuer image/config/profile, HTTPS ingress/client custody and measured capacity/headroom. Exercise real human PKCE and service tokens, actual endpoint authentication, revoked-token UserInfo refusal, expiry, unavailable dependency, restart/store loss and fresh reauthentication. Preserve old offline-token semantics and document every consumer's selected mode. Review disabling/rollback explicitly; never silently fall back to offline acceptance for online-profile consumers. Provide owner receipts to existing NK48/Apps consumer tasks and Audit source admission.

2026-10-18 source verification: all 659 test/subtest results in the complete race suite pass, with six preexisting native/external skips. The standalone binary passes 26 isolated process checks, including actual main/router/config, service issuance, capacity, revocation, process restart, fresh issuance and disabled-profile behavior; fixture diagnostics omit synthetic private inputs. The HTTPS human PKCE flow and revocation during directory lookups also pass. An isolated control omitting the revoked-state predicate fails seven intended checks. This closes source task T02 only. T01 independent issuer/profile review, T03 native admission and all existing consumer operation/effect bindings remain open. Evidence is retained by CUST-WP-0080 under keycape-token-status-r1.

Provide the shared producer client and owner-private command observations

id: KEY-WP-0042-T04
status: done
priority: high
state_hub_task_id: "4c71c9f7-8e14-5fec-8491-d7a7995f97e2"

2026-10-18 source outcome: internal/authclient/online.go owns strict current token/status joining, explicit HTTPS/CA/JWKS/current-credential admission, identity-first credential access, per-check rereads, response/clock/lifetime rechecks and independent read-only inactive observation. The existing executable exposes check-current-token, revoke-token, check-inactive-token, with exact token digest binding and new private observation outputs outside Git. Negative output is explicitly inactive-for-client, never global revocation/ownership. The public five-file Go adapter is generated from the same client and JOSE bytes; ordinary source checks refuse drift. Source/contract: docs/current-token-client.md.

The full source race suite passes 724 test/subtest results with the same six native/external skips. Human PKCE tests retain actual subject/assurance/auth-time/ tenant provenance and refuse ID-token substitution. A separate source fixture uses the built CLI, generated Go consumer and actual Warden kernel across fresh owner processes, with real fixture HTTPS status and independent negative cleanup checks. Owner approvals/case/catalog and target are synthetic; there is no native admission or second real application acceptance. The first CLI fixture's directory permissions, archive-only Warden Git metadata failure and original API absence are retained as failures, not backfilled successes. Source/evidence: the-custodian/docs/changes/netkingdom-target-2026-10-18/keycape-current-client-r1/. T01 independent issuer/profile review, T03 native lifecycle, NK48/Apps actual operation/inverse/ongoing-resource bindings and all full target gates remain open.