net-kingdom/security-case-type-revisions/1.2/oidc-browser-relying-party

Acknowledged OIDC browser relying-party 1.2 source package

This package supplements the exact proposed 1.2 type and Forgejo reference design. It is source-only and unimplemented. Its examples are proposed, including Forgejo; normal admission must refuse them until the separate implemented-type and canonical-case acceptance requirements are discharged. Completing this package or acknowledging its type does not accept a canonical case or authorize native work. Immutable acknowledged 1.1 history remains unchanged.

Purpose

Register exact-redirect browser OIDC relying parties through KeyCape, with groups enforced by the consumer. Confidential clients add a custody path, two reader policies, the existing KeyCape ESO role and a sixth dedicated consumer ESO reader role. consumer_namespace is explicit and independently constrained; a consuming service name does not establish its namespace or workload identity. Public clients require no secret materialization.

Threat model

Exact HTTPS redirects prohibit wildcard, query, fragment and plaintext HTTP. Requested scopes always include groups, but KeyCape issues identity tokens without a per-client group gate: each consumer must enforce its required claims. MFA pinning is client configuration, not proof of a human MFA session. Secret custody parameters and reader identities cannot be overridden by case authors.

The namespace SecretStore references a dedicated automount-disabled service account rather than forgejo/default. ESO's broadly privileged common controller remains trusted; this is routing and identity attribution, not cryptographic controller isolation. The supported v0.16.1 TokenRequest path requests a 600-second token; its legacy fallback must not acquire static tokens. The proposed OpenBao role has a 900-second maximum token TTL and no default policy. Neither rendered claims nor source tests prove native bindings, token audience, capabilities, delivery readiness or revocation.

Alternatives considered

Retain 1.1 with the observed Forgejo/runner workload ServiceAccount forgejo/default: preserves existing history but does not express the dedicated reader boundary. This describes observed workload identity only; the historical 1.1 consumer OpenBao policy was unbound and no historical default-SA OpenBao reader binding is claimed. Reuse the KeyCape reader role: combines provider and consumer identities unnecessarily. Adopt a separate controller: potentially reduces shared trust but adds infrastructure outside this bounded proposal. Proposed 1.2 retains shared-controller trust explicitly while adding the sixth dedicated role; no new grant follows from this source design.

Known limits

All native bound claims remain unconfirmed and execution remains false. HTTP OpenBao transport, shared ESO controller trust, legacy fallback, retained target Secrets and later dependency handling require owner verification before any separately approved session. A SecretStore/SA deletion alone does not revoke issued tokens. Recovery may remove only authenticated case-created resources with unchanged UID/ownership, must preserve preexisting exact matches, revert consumer references first and revoke issued tokens or verify expiry before declaring deactivation. Owner adapter and global verifier observations remain required. No human login, MFA, credentials, native materialization or first-case completion is claimed.

Verification

Run the existing owner full-package validator against this directory, then run its tests. Tests use the existing owner validator/composer and actual declarations; they prove source schema, examples, deterministic rendering, six-object confidential versus public boundaries, refused mutation/parameters, normal admission refusal and bounded rollback ordering. They do not contact native services.

python3 tools/security-case-types/security_case_validator.py validate-type docs/proposals/2026-10-11-forgejo-consumer-eso/package-1.2
NET_KINGDOM_ROOT=/home/worsch/net-kingdom python3 -m pytest docs/proposals/2026-10-11-forgejo-consumer-eso/package-1.2/tests

Governance and recording

SecurityCaseTypes section 3 requires the complete package and a separate NetKingdom source-owner review before type acknowledgment recording. Sections 4/5 require an implemented type for canonical case acceptance; section 6 requires a genuine new acknowledgment for the sixth role/authentication path. The old 1.1 acknowledgment is not inherited. Reference-migration source approval is a separate owner receipt; canonical 1.2 stays proposed without acceptance fields or phase acceptance.

Recorded source acknowledgment — 2026-10-11

Confirmed native human ACCEPT of infd-20261011-forgejo-type12-source-r1@1 at2026-10-11T06:47:39Z, approval8e9332c8-754a-420c-b8b7-445cb4fe6765, acknowledges source architecture only. Exact reviewed proposed typeSHA 017885bdd139cd66a5bf6d9839b1b8ec9bc08fb051d9577adc3928b76a7be6db is preserved in the immutable proposal package. This copy changes type status to acknowledged and documents that source record; it remains unimplemented. See decision/acknowledgment.json for exact native disposition, packet, owner returns, post-anchor review and source digests. Tests adapt only the expected type status; examples remain proposed without acceptance fields. Current canonical1.1 type, package and acceptedcase remain unchanged and selected by the default loader.

This explicit version root is security-case-type-revisions/1.2; choose it only for separate source validation/preparation using the existing --types/--types-root option. No default loader/repoint or canonicalcase1.2 admission is introduced. The full proposed package test/validator proof is retained; run this acknowledged copy's package validator/tests before recording its acknowledgment. The separate reference-migration owner design receipt is not canonical case acceptance.