contract(identity): publish versioned subject-assertion trust semantics for durable RP binding #155

Consumer-driven owner gap

Orgmetra #297 cannot safely complete durable person↔Keyverse subject binding because Keyverse currently has no immutable published release exposing a consumer contract/receipt that proves an RP may persist a verified subject association. Orgmetra #295 therefore fails closed and treats raw (issuer, subject) only as non-authorizing candidate data.

This is Keyverse-owned identity/authentication truth. Do not solve it by copying mutable Keyverse source into Orgmetra or by letting an RP manufacture a boolean authenticated=true/local receipt.

Required owner contract

Publish a versioned, independently consumable subject-assertion trust contract and conformance fixtures that let an RP determine, from Keyverse-authenticated evidence, at minimum that:

• issuer, signature/allowed algorithm, audience, expiry/time claims and subject were verified under the exact released Keyverse profile;
• the assertion/receipt is bound to the intended RP/tenant context and cannot be replayed or substituted as another subject association;
• the owner contract explicitly guarantees whether the verified subject is suitable for durable RP correlation/binding rather than only session-scoped authentication. Do not invent a consumer-side field name merely to satisfy this issue; choose the owner representation and version it here;
• revocation/rotation/key rollover and contract-version semantics are explicit enough that a relying party can fail closed on stale or unverifiable evidence;
• tests cover wrong issuer/audience/signature/algorithm, expired/not-yet-valid evidence, cross-tenant/RP substitution, forged/local receipts and a subject that is not eligible for durable correlation.

The contract should remain orthogonal to downstream HR authorization. Orgmetra owns Person/Employment/Assignment and purpose-bound HR policy; Keyverse owns authentication/identity evidence.

Subject-stability standards watch

OpenID Connect Core 1.0 defines the ordinary Subject Identifier as locally unique and never reassigned within its issuer, and the public/pairwise subject types are intended for RP consumption. However, the OpenID Connect Ephemeral Subject Identifier 1.0 draft intentionally changes sub across subsequent visits. As of 2026-09-11 it is still pre-final: the OpenID Foundation announced a final-spec vote for 2026-09-16 through 2026-09-30. Treat that draft as design/watch evidence, not current normative authority.

The release contract therefore must not make an unconditional assumption that every syntactically valid sub can become a durable RP identity link. If Keyverse supports ephemeral or otherwise non-correlatable subject modes, the released semantics must make durable-binding eligibility unambiguous so consumers can reject persistence while still allowing appropriate session authentication.

Release acceptance

Completion requires protected integration plus an immutable Keyverse API/schema/client or equivalent consumer artifact, conformance fixtures, version/changelog, SBOM/provenance/rollback coordinates and a published immutable release. A Proposed ADR, branch SHA, README statement, or successful issuer-side unit test is not a consumable release.

Orgmetra consumer acceptance remains tracked in ContextualWisdomLab/Orgmetra#297 and should version-bump only after this owner contract is immutable.