Repository navigation
security(keyverse): require authenticated released identity evidence before durable binding #297
Description
Activity
Fresh owner update: #295 has advanced ordinary-forward to exact
d15a741c10685208b124477e9d7820cdf17339e8on protected basedevelop@eb9757f8649aaad026a9865508d9aad50c1a7a4f. The fail-closed identity-subject ACL remains intentional: raw issuer/subject is onlyExternalIdentityBindingCandidatedata, and no positive persistence-authorizing path is created without immutable released/versioned Keyverse subject-assertion evidence.The documentation reseal at predecessor
cf9d6d1727b542e545d1e34f7222bcbe1dec8139introduced an unrelated manifest regression by replacing the canonical SHA-256 ofdatabase/migrations/0005_outbox_delivery_finalization.sqleven though the migration did not change. Foundation34514317149/102995840419reproduced a real exact-head RED and printed the canonical migration seal.d15a741...is the minimal repair: canonical migration-0005 seal restored while the reconciledCHANGELOG.mdseal remains current; Foundation34515073682/102998336570is GREEN.Fresh Keyverse release inventory is still empty, and the inspected open Keyverse identity/auth/security lanes are mutable PRs rather than an immutable subject-assertion owner release. Therefore #297 remains open. Completion still requires a real owner release/contract, Orgmetra ACL consumption of that exact released evidence, positive/negative exact-head tests and security/review evidence, and normal protected integration. Do not substitute a local token/JWKS verifier, caller trust flag, mutable Keyverse branch dependency, or cross-service SQL.
#295 exact binding owner has advanced ordinary-forward to
a3fa3470b6b4b489889b574afcc1f672a7fdedccafter a fresh runtime-integrity repair for optional claim-name screening. The authority boundary remains unchanged: raw issuer/subject/claim syntax is still non-authorizing,bind_identity_subject(...)still fails closed, and a positive durable path still requires an immutable released/versioned Keyverse subject-assertion contract through the Orgmetra ACL.Fresh dependency read still returns no Keyverse releases. The new repair does not invent trust evidence or add an OIDC/JWKS verifier. It only ensures malformed/behavior-bearing
extra_claimscontainers or claim-name keys cannot execute through the local credential-name screening step before the fail-closed trust gate. Test-first85c08ac7e991877171d44dd523aaad585c599259; causal sourcea3fa3470b6b4b489889b574afcc1f672a7fdedcc. #295 is Draft again until the new exact-head checks/review are admissible.#295 advanced ordinary-forward to exact
694585a64d038d30e851e156b8d5423e567c14f8and is Draft while fresh exact-head gates run. The new repair is deliberately narrower than this issue's authentication-authority gap: padded/blank exact-stringextra_claimsnames are now rejected before credential-name classification, with real test-first Foundation RED onb63c50a...and minimal canonical-name validation on694585a....This does not create a positive durable-binding authority.
ExternalIdentityBindingCandidateremains non-authorizing andbind_identity_subject(...)still fails closed until the immutable Keyverse subject-assertion contract/release owned byContextualWisdomLab/keyverse#155exists and Orgmetra adopts that exact released version through its ACL. The fresh ConceptWeave consumer handoff on Keyverse#155 reinforces, rather than changes, the owner boundary: Keyverse identity/tenant trust evidence must remain orthogonal to application-specific resource authorization.Keep #297 open. No mutable Keyverse source, local
authenticated=truereceipt, or caller-controlled trust flag has been introduced.Consumer boundary remains fail-closed on current #295
da7d005e87c906f0ed1f0e8bd91c0677b3fff5d9; this ordinary-forward hardening does not manufacture Keyverse authentication authority.The adapter now also rejects raw
id_token,client_secret, andapi_keyfields before candidate/trust classification, alongside the existing password/passkey/private-key/access-token/refresh-token screening. OpenID Connect Core treats the ID Token as the JWT carrying authentication information and Client Secret as client-authentication secret material, so accepting them as ordinary extra claim metadata would blur the exact owner boundary. Orgmetra still does not parse/verify them and does not retain claim values.Keyverse#155 remains the positive-path prerequisite. Its immutable released contract must provide the authenticated/versioned RP/tenant/subject trust semantics; Orgmetra then consumes that exact artifact through the ACL. Until then,
ExternalIdentityBindingCandidateremains non-authorizing andbind_identity_subject(...)remains fail closed. Keep #297 open through owner release + consumer version adoption + exact-head acceptance + protected integration.Current #295 consumer boundary advanced to exact
086fe88607b1e30f72633b5222fbcaf8f846e9caon unchanged protecteddevelop@eb9757f8649aaad026a9865508d9aad50c1a7a4f.The new change closes post-validation mutation of the non-authorizing candidate itself by replacing frozen-dataclass storage with tuple-backed immutable storage. This does not create authentication authority or a positive durable-binding path. Low-level construction can still manufacture a Python value, so consequential trust must come only from the released Keyverse owner contract and must be reconstructed/revalidated at the ACL boundary rather than inferred from object type.
Fresh Keyverse owner inventory still shows issue #155 open and published GitHub releases
[]. Keep this issue open: completion remains Keyverse#155 protected integration + immutable released contract/artifact + Orgmetra exact-version ACL adoption + negative forged/stale/cross-tenant/non-durable evidence acceptance + normal protected integration.#295 current binding owner advanced to exact
c7d39a6702ed2149c79dc2aa7c2c4be983679f9cafter a valid CodeRabbit finding on returned UUID aliasing. The candidate now retains checked tenant/person integer scalars and constructs a fresh UUID view on every property read, so mutation of one returned UUID cannot rewrite retained candidate identity.This is input-integrity hardening only. It does not create authentication authority or a positive durable-binding path. #297 therefore remains open with the same completion boundary: released/versioned Keyverse subject-assertion evidence must first cross the ACL, and consequential Orgmetra consumption must reconstruct/revalidate that evidence rather than trust locally constructible candidate objects. Current #295 exact-head hosted checks are still queued, so no successor GREEN or merge claim is made.
Finding
Orgmetra must not promote syntactically valid
(issuer, subject)input into durable Person identity truth without evidence that the canonical identity owner authenticated that subject and permits the subject mode to be durably correlated by this RP/tenant.Keyverse still has no published immutable GitHub release exposing that consumer trust contract. Raw issuer/subject input therefore remains non-authorizing candidate data and
bind_identity_subject(...)must fail closed.Current Orgmetra repair
Canonical binding PR #295 is now exact
c7d39a6702ed2149c79dc2aa7c2c4be983679f9con protecteddevelop@eb9757f8649aaad026a9865508d9aad50c1a7a4f, open / Ready for Review / mechanically mergeable. The older086fe886...Draft snapshot is superseded ordinary-forward and is no longer current authority.The current #295 lane:
ExternalIdentityBindingCandidatewithpersistence_authorized == False;#295 records exact-head Foundation, SAST and Security success and external GHAS analysis success, but does not have admissible complete release/merge evidence: its Strix artifact lacks exact materialization provenance, central CodeQL publication/settlement remains a required-workflow RED, and no qualifying current-head independent approval exists. Ready state is therefore not completion or merge authorization.
Keyverse owner dependency
Keyverse #155 remains the canonical owner of the missing subject-assertion trust semantics for durable RP binding: issuer/signature/audience/time/subject evidence, RP/tenant binding, replay/substitution resistance, revocation/rotation/version semantics, and unambiguous durable-versus-session-only correlation eligibility.
Keyverse #158, created by the gateway/composition lane, is a broader immutable OIDC relying-party consumer release envelope. It has now been currentized so that it must adopt/reuse #155 or prove complete verified succession; it may not create a second independently evolving subject-trust schema. #155 is not closed merely because #158 exists. A verified successor is acceptable only when every valid #155 semantic/test/fixture/release delta is demonstrably inherited.
Open Keyverse PR #103 already contains overlapping issuer-side RP requirements for issuer, signature/algorithm, expiry, subject, audience and tenant/resource validation. Treat it as an existing foundation/possible canonical owner rather than duplicating those contracts. Its mutable Draft state is not a consumable release and it does not by itself establish the durable-vs-session-only subject-correlation guarantee required here.
OpenID Connect Core and applicable OAuth security BCPs remain design/traceability inputs, not permission for Orgmetra to become a token/JWKS/signature verifier. Subject modes that are ephemeral or otherwise non-correlatable remain non-persistable unless the released Keyverse owner contract explicitly marks them eligible for durable RP correlation.
Relation to gateway composition
Orgmetra #432/#433 may compose released Keyverse identity evidence into a runtime
AuthenticatedPrincipal, but it does not replace this durable Person-binding lane. The gateway-specific mapping of verifiedsub/org/workspace/scope evidence into runtime actor/tenant/capability coordinates must remain explicit and versioned, while:No implicit claim-to-UUID cast, decoded-only trust, role/scope-to-HR-purpose shortcut, mutable Keyverse source import, or parallel subject receipt is permitted.
Acceptance
Keep this issue open until the Keyverse owner release, Orgmetra positive-path ACL, exact-head evidence and protected integration all exist. Fail-closed #295 alone is not completion, and #158 existence alone is not verified succession of #155.