@openwop/openwop-conformance 1.146.0 → 1.148.0

package/CHANGELOG.md

@@ -1,5 +1,23 @@
 # `@openwop/openwop-conformance` Changelog
 
+## [1.148.0] — 2026-09-01 — RFC 0163 `Draft → Active`: classes not attributes, schema conditional, fixture proof out of the scenario
+
+No new scenario file (suite file count unchanged); published content changes, so the identity bump is a minor. Three things move.
+
+**The enum names classes, not vendor attributes.** `capabilities.auth.subjectLinkKey` is now `{opaque-idp, configured-immutable}`; the `Draft` set `{opaque-idp, oid, immutable-id}` carried two Entra ID attribute names that the suite could not tell apart (its only check is membership), and the RFC's own gap register was already anticipating a fourth. `configured-immutable` absorbs both under the §A.1 conjunctive predicate. 1.147.0 was never published, so no consumer ever accepted the old members.
+
+**The co-requirement is in the schema.** `capabilities.schema.json` gains `if subjectLinking:true then required [subjectLinkKey]` under `auth`. The `Draft` left this in prose and recorded the hole as its own risk R5 — a `subjectLinking:true` document with no key was schema-valid, so a host self-certifying against the bare schema read as passing. The conditional fires only on a flag no production host emits, which is a tightening of an unemitted shape, not a closure of a server-emitted one. Pinned server-free in `src/lib/capabilities-auth-subject-link.test.ts` (missing key rejected, `email` rejected, the two retired names rejected, both members accepted, absent/false unaffected).
+
+**The fixture proves itself in `src/lib`, not in the scenario.** The four two-trust-root self-tests that 1.147.0 put inside `auth-subject-link-key-class.test.ts` moved to `src/lib/saml-idp.test.ts` (plus a sixth: a post-signing Issuer swap MUST NOT verify — the §B.1 "inside the signed element" requirement, witnessed rather than asserted). Inside the scenario they were the G8 shape exactly: on every host that does not advertise `subjectLinking`, the advertisement legs soft-skip `inapplicable`, the fixture legs pass with assertions, and the file resolves to `executed-pass` — a witnessed pass about a fixture, credited to a host the file never examined. `src/lib` tests run in the published suite and produce no ledger row, the same reason `oidc-issuer.test.ts` lives there. The RFC 0050 `auth-saml-profile.test.ts` reference-suite block has the same shape and is recorded as RFC 0163 gap G5 for its own PR, since moving it changes RFC 0050's recorded evidence.
+
+Also: three `subject-link-*` invariants registered (RFC 0159 had a threat-model row and no invariant); `coverage.md` gains the two subject-link rows it was missing; `host-sample-test-seams.md` documents the `idpUrl`, `externalId`, and `link`/`linkKey` fields the two scenarios already sent and the `authenticated`/`linkedDenied` response the validate seam already returned; the "RFC 0048 §D owner-echo determinism" citation that RFC 0159, RFC 0163 and `auth-profiles.md` relied on is corrected — §D is "Cross-workspace isolation"; the echo is §C and the determinism is RFC 0006.
+
+## [1.147.0] — 2026-09-01 — RFC 0163 §B two-trust-root fixture (gap G-fixture)
+
+No new scenario file (suite file count unchanged): un-stubs the RFC 0163 §B same-IdP-trust-root behavioral leg in `auth-subject-link-key-class.test.ts`, which had been a phased `blocked` soft-skip pending the fixture. The bundled synthetic SAML IdP (`src/lib/saml-idp.ts`) is extended to carry a **distinct trust root** per instance: `createSyntheticSamlIdp({ entityID })` now stamps a **signed** `<saml:Issuer>` into every assertion (inside the signed canonical element, so it cannot be swapped post-signing), exposes `.entityID`, and adds `issuerOf()`. Two instances (distinct entityID + distinct signing key) model two independent IdPs that can mint an assertion for the **same** opaque subject id (an identifier collision) while remaining cryptographically and by-issuer distinguishable — the fixture RFC 0163 gap G-fixture called for.
+
+The §B scenario now carries two forms: a **server-free reference suite** proving the fixture (executable now — distinct entityIDs, both IdPs mint the colliding subject, the assertions carry different signed Issuers, and IdP-A rejects IdP-B's cross-root assertion with `bad-signature`); and a **live black-box leg** over the host's SCIM+SAML seams — a same-IdP positive control (must link, which guards the negative against vacuity) paired with the §B.1 cross-IdP collision that MUST NOT link. The live leg is opt-in via `OPENWOP_TEST_SAML_IDP_URL` (IdP-A, also the SCIM lane's IdP) + `OPENWOP_TEST_SAML_IDP_URL_B` (IdP-B) + `OPENWOP_TEST_SCIM_URL`, soft-skipping (`inapplicable`) until a host wires the two-trust-root seam and gated on `capabilities.auth.subjectLinking`. Existing RFC 0050 SAML variant coverage is unaffected (the signed Issuer is threaded through sign+verify consistently; all 6 negatives + valid still pass). RFC 0163 stays `Draft`; this makes its §B leg executable-when-seamed without flipping its status.
+
 ## [1.81.0] — 2026-08-12 — RFC 0149 §D lifecycle coherence
 
 Adds one scenario (suite 420 → 421): `rfc-lifecycle-coherence.test.ts`, three always-on server-free legs. §D asks the corpus generator to fail when an `Accepted` RFC "retains an unresolved acceptance blocker not explicitly carried". The obvious rule — every box ticked before `Accepted` — was measured and rejected: of 141 `Accepted` RFCs, 42% ticked all, 25% ticked none, 24% ticked some, so a blanket gate fails **69 RFCs on its first run**, and a gate that fires 69 times gets disabled rather than fixed. The follow-up hypothesis (that the partially-ticked RFCs were a blocker backlog) also failed on reading them: every trailing item in `0027`/`0040`/`0041` is deliberately unticked **and annotated with why**, which *is* §D's "explicitly carried", just in a parenthetical rather than a register row. **Shipped rule: annotated vs bare, not ticked vs unticked** — an unticked item with no explanation is indistinguishable from one nobody checked. Scoped to RFCs ≥ 0147 so it binds the cohort that proposed it, with a leg asserting exactly that; earlier RFCs are the dated record of a period when the convention did not exist, and the boundary is asserted so a new RFC cannot inherit the exemption. All 67 bare items across 0147–0156 were annotated to land it. The non-vacuity guard is load-bearing here because **the gate's passing state and its broken state look identical**. Sabotage-verified.

package/coverage.md

@@ -117,6 +117,8 @@ The scenario groups in the table below (one row per group; count the rows — th
 | `authorization-fail-closed.test.ts`                                                                                                                                                                                                                     | `capabilities.authorization` (RFC 0049 §C) + `SECURITY/invariants.yaml` `authorization-fail-closed`                                                                                                                                                                                                                     | A (advertisement `failClosed===true` always; fail-closed MUST-NOT via optional `POST /v1/host/sample/authorization/decide` seam — an unseeded-role principal resolves `allowed:false`)                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                              | `host-pending`                                                                                                                   | Capability-gated on `authorization.supported`; behavioral probe soft-skips on 404. Scope-match + denial-audited scenarios deferred to a host.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           |
 | `auth-saml-profile.test.ts`                                                                                                                                                                                                                             | `openwop-auth-saml` (RFC 0050, `auth-profiles.md` §`openwop-auth-saml`)                                                                                                                                                                                                                                                 | A+B (profile-advertisement shape always; **1-positive + 6-negative reference suite runs server-free** via the bundled synthetic IdP `conformance/src/lib/saml-idp.ts` — `alg:none`/unsigned/bad-sig/expired/not-yet-valid/wrapping; host-ACS validation opt-in via `OPENWOP_TEST_SAML_IDP_URL` + the `auth/saml/validate` seam)                                                                                                                                                                                                                                                                                                                                                                     | host-pass (server-free reference)                                                                                                | Synthetic IdP bundled (`node:crypto`, no deps). Host-ACS pass is the remaining graduation gate.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                         |
 | `auth-scim-profile.test.ts`                                                                                                                                                                                                                             | `openwop-auth-scim` (RFC 0050, `auth-profiles.md` §`openwop-auth-scim`)                                                                                                                                                                                                                                                 | B (profile-advertisement shape always; SCIM user/group provisioning → principal/role roundtrip opt-in via `OPENWOP_TEST_SCIM_URL` + the `auth/scim/provision` seam)                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                 | `host-pending`                                                                                                                   | Behavior opt-in (operator-supplied SCIM endpoint); deactivate ⇒ subsequent-deny assertion deferred to a host.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           |
+| `auth-subject-link.test.ts` | `openwop-auth-saml` + `openwop-auth-scim` with `capabilities.auth.subjectLinking: true` (RFC 0159, `auth-profiles.md` §Subject linking) | B (advertisement gate always — `subjectLinking:true` only alongside both profiles; cross-lane leaver deny + mutable-key negative opt-in via `OPENWOP_TEST_SAML_IDP_URL` + `OPENWOP_TEST_SCIM_URL` and the `auth/scim/provision` + `auth/saml/validate` seams) | host-pass (tier-1 in-process witness, openwop-app #3581) | Invariant `subject-link-leaver-deny`. No production host advertises `subjectLinking`. |
+| `auth-subject-link-key-class.test.ts` | as above (RFC 0163) | B (`subjectLinkKey` ∈ `{opaque-idp, configured-immutable}` when `subjectLinking:true`, unaided; same-IdP control + cross-IdP collision negative opt-in via `OPENWOP_TEST_SAML_IDP_URL` + `OPENWOP_TEST_SAML_IDP_URL_B` + `OPENWOP_TEST_SCIM_URL`) | `host-pending` (gates RFC 0163 `Active → Accepted`) | Invariants `subject-link-key-class-declared`, `subject-link-same-trust-root`. Fixture self-test lives in `src/lib/saml-idp.test.ts`, not here (G8). |
 | `runtime-requires-shape.test.ts`                                                                                                                                                                                                                        | `node-pack-manifest.schema.json` `$defs/Runtime.requires` (RFC 0076 §A, `node-packs.md` §"Runtime platform requirements")                                                                                                                                                                                               | Server-free (closed-vocabulary validation: 8 tokens validate; raw builtin `node:dns/promises` rejected → `invalid_manifest`; empty-array≡omission; `uniqueItems`)                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                   | host-pass (server-free)                                                                                                          | Always runs; no host needed. The install-time GATE behavior is in `runtime-requires-install-gate.test.ts`.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                              |
 | `runtime-requires-install-gate.test.ts`                                                                                                                                                                                                                 | RFC 0076 §A install gate (no capability flag; seam `POST /v1/host/sample/packs/install-gate`)                                                                                                                                                                                                                           | A (install-grant; install-refuse → `pack_runtime_requirement_unmet { unmet, manifest, advice? }`; non-sandbox SHOULD-projection — all via the optional seam)                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        | `host-pending`                                                                                                                   | Seam-gated; soft-skips on 404. First adopter: MyndHyve's install-time gate against `core.openwop.http` declaring `["net.dns","net.outbound"]`.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                          |
 | `safefetch-behavior.test.ts`                                                                                                                                                                                                                            | `capabilities.httpClient.safeFetch` (RFC 0076 §B, `host-capabilities.md` §host.http) + `SECURITY/invariants.yaml` `http-client-ssrf-guard`                                                                                                                                                                              | A (SSRF block + DNS-rebinding defeat + `Connection: upgrade` refusal + tool-hooks audit-when-`prePostEvents`, via the optional `POST /v1/host/sample/http/safe-fetch` seam)                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                         | in-memory ✅                                                                                                                     | **5/5 PASS against the in-memory reference host** (2026-05-29, `OPENWOP_REQUIRE_BEHAVIOR=true`); seam-gated, soft-skips on 404 elsewhere. Reuses the existing `http-client-ssrf-guard` invariant (no new invariant). Advertisement contract in `http-client-ssrf.test.ts`. §B → Accepted still awaits `core.openwop.http@2.0.0` consumer + non-steward adoption.                                                                                                                                                                                                                                                                        |

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@openwop/openwop-conformance",
-  "version": "1.146.0",
+  "version": "1.148.0",
   "description": "Production-ready black-box conformance suite for OpenWOP v1.0 compliant servers.",
   "repository": {
     "type": "git",

package/schemas/CORPUS-STAMP.json

@@ -1,5 +1,5 @@
 {
   "_comment": "Provenance of this vendored schemas/ copy. See conformance/README.md \u00a7\"Resolving the contract\". Compare against the stamp in your installed @openwop/openwop-conformance to detect a stale hand-copied contract.",
-  "suiteVersion": "1.146.0",
-  "corpusCommit": "aedaa189e427ef0f62db402c1b97f1d8a3ebb9ca"
+  "suiteVersion": "1.148.0",
+  "corpusCommit": "da881becd3482742b3d75028a08ac298d8cc8d48"
 }

package/schemas/capabilities.schema.json

@@ -3697,8 +3697,8 @@
         },
         "subjectLinkKey": {
           "type": "string",
-          "enum": ["opaque-idp", "oid", "immutable-id"],
-          "description": "RFC 0163 (auth-profiles.md \u00a7Subject linking). The CLASS of opaque, IdP-stable, non-PII identifier this host joins the SAML and SCIM lanes on. A CLOSED enum of ALLOWED classes only: `opaque-idp` (SCIM `externalId` \u2194 persistent-format SAML `NameID`), `oid` (an IdP-asserted immutable object identifier), `immutable-id` (a configured immutable-id attribute asserted by the same IdP). Mutable/PII keys (email, userName, displayName) are INEXPRESSIBLE by construction \u2014 a conforming host cannot name one, which is the witness that converts RFC 0159 \u00a7A.2/\u00a7A.4's negative-existence prohibition into a positive advertisement. REQUIRED (its own MUST in auth-profiles.md \u00a7Subject linking, not a schema `required` row) when `subjectLinking` is true: a host setting `subjectLinking:true` MUST advertise a `subjectLinkKey` in this enum and MUST honour it (advertise only what you honour). Optional at the schema level so the field is additive; absent-with-`subjectLinking:true` is a conformance violation, not a schema-validation error. RFC 0163 also requires the SAML and SCIM lanes to share an IdP trust root before a link may form (SAML assertion issuer corresponds to the SCIM provisioning IdP)."
+          "enum": ["opaque-idp", "configured-immutable"],
+          "description": "RFC 0163 (auth-profiles.md \u00a7Subject linking). The CLASS of opaque, IdP-stable, non-PII identifier this host joins the SAML and SCIM lanes on. A CLOSED enum of ALLOWED classes only, naming classes rather than vendor attributes: `opaque-idp` (SCIM `externalId` \u2194 persistent-format SAML `NameID`) or `configured-immutable` (a host-configured attribute asserted by the same IdP on both lanes that is opaque, stable for the account lifetime, never reassigned, non-PII and not user- or operator-influenceable \u2014 e.g. a directory object id or an immutable-id claim; the attribute name stays host config, the class goes on the wire). Mutable/PII keys (email, userName, displayName) are INEXPRESSIBLE by construction \u2014 a conforming host cannot name one, which is the witness that converts RFC 0159 \u00a7A.2/\u00a7A.4's negative-existence prohibition into a positive advertisement. REQUIRED when `subjectLinking` is true: expressed BOTH as the auth-profiles.md \u00a7Subject linking MUST and as this block's `if`/`then` conditional, so a discovery document claiming linking without a class fails schema validation as well as the conformance scenario. Absent when `subjectLinking` is absent/false."
         },
         "rotation": {
           "type": "object",
@@ -3862,6 +3862,14 @@
           }
         }
       },
+      "if": {
+        "properties": { "subjectLinking": { "const": true } },
+        "required": ["subjectLinking"]
+      },
+      "then": {
+        "required": ["subjectLinkKey"],
+        "$comment": "RFC 0163 \u00a7A.1 / \u00a7C: a host that claims subject linking MUST declare the class it joins on. A conditional required on a flag no host emitted when it landed is a tightening of an unemitted shape (COMPATIBILITY.md \u00a72.2), not closure of a server-emitted shape (\u00a72.1)."
+      },
       "additionalProperties": true
     },
     "discovery": {

package/src/lib/capabilities-auth-subject-link.test.ts

@@ -0,0 +1,75 @@
+/**
+ * Server-free pin of the RFC 0163 §C schema conditional in
+ * `schemas/capabilities.schema.json`:
+ *
+ *   auth.subjectLinking: true  ⇒  auth.subjectLinkKey required
+ *   auth.subjectLinkKey        ∈  { opaque-idp, configured-immutable }
+ *
+ * This checks the SCHEMA ARTIFACT, not any host, which is why it lives under
+ * `src/lib/` (no scenario ledger row — see `saml-idp.test.ts` for the G8
+ * reasoning). The host-facing assertion is the advertisement leg of
+ * `scenarios/auth-subject-link-key-class.test.ts`, gated on the flag.
+ *
+ * @see RFCS/0163-subject-linking-hardening.md §C
+ * @see spec/v1/auth-profiles.md §"Subject linking (SAML ⟷ SCIM)"
+ */
+
+import { describe, it, expect } from 'vitest';
+import { readFileSync, readdirSync } from 'node:fs';
+import { join } from 'node:path';
+import Ajv2020 from 'ajv/dist/2020.js';
+import addFormats from 'ajv-formats';
+import { SCHEMAS_DIR } from './paths.js';
+
+function compileCapabilities() {
+  const ajv = new Ajv2020({ allErrors: true, strict: false });
+  addFormats(ajv);
+  for (const file of readdirSync(SCHEMAS_DIR).filter((f) => f.endsWith('.schema.json'))) {
+    const s = JSON.parse(readFileSync(join(SCHEMAS_DIR, file), 'utf8')) as { $id?: string };
+    ajv.addSchema(s, file);
+    ajv.addSchema(s, `./${file}`);
+  }
+  // Validate the `auth` block in isolation: the conditional lives on that
+  // object, and a full discovery document would drag in every root-level
+  // required family (supportedEnvelopes, schemaVersions, limits, …) that has
+  // nothing to do with what this file pins.
+  return ajv.compile({ $ref: 'capabilities.schema.json#/properties/auth' });
+}
+
+const PROFILES = ['openwop-auth-saml', 'openwop-auth-scim'];
+function doc(auth: Record<string, unknown>) {
+  return auth;
+}
+
+describe('capabilities.schema.json: auth.subjectLinkKey conditional (RFC 0163 §C)', () => {
+  const validate = compileCapabilities();
+
+  it('subjectLinking:true WITHOUT subjectLinkKey fails validation (§A.1 co-requirement is in the schema, not only prose)', () => {
+    const ok = validate(doc({ profiles: PROFILES, subjectLinking: true }));
+    expect(ok, JSON.stringify(validate.errors)).toBe(false);
+    expect(JSON.stringify(validate.errors)).toContain('subjectLinkKey');
+  });
+
+  it('subjectLinking:true with a class member validates', () => {
+    for (const k of ['opaque-idp', 'configured-immutable']) {
+      const ok = validate(doc({ profiles: PROFILES, subjectLinking: true, subjectLinkKey: k }));
+      expect(ok, `${k}: ${JSON.stringify(validate.errors)}`).toBe(true);
+    }
+  });
+
+  it('a mutable/PII key is INEXPRESSIBLE: "email" fails the enum', () => {
+    const ok = validate(doc({ profiles: PROFILES, subjectLinking: true, subjectLinkKey: 'email' }));
+    expect(ok).toBe(false);
+  });
+
+  it('the retired Draft-era attribute names are not members (the enum names classes)', () => {
+    for (const k of ['oid', 'immutable-id']) {
+      expect(validate(doc({ profiles: PROFILES, subjectLinking: true, subjectLinkKey: k })), k).toBe(false);
+    }
+  });
+
+  it('subjectLinking absent or false does not require a key (nothing de-conforms)', () => {
+    expect(validate(doc({ profiles: PROFILES }))).toBe(true);
+    expect(validate(doc({ profiles: PROFILES, subjectLinking: false }))).toBe(true);
+  });
+});

package/src/lib/saml-idp.test.ts

@@ -0,0 +1,83 @@
+/**
+ * Server-free unit tests for the synthetic SAML IdP harness — specifically its
+ * TWO-TRUST-ROOT behaviour (RFC 0163 §B, gap G-fixture, #1163).
+ *
+ * These assertions prove the FIXTURE, not any host: two instances with distinct
+ * `entityID`s and signing keys can mint an assertion for the SAME opaque
+ * subject id (an identifier collision) while remaining cryptographically and
+ * by-issuer distinguishable. That is what makes the §B same-IdP MUST
+ * witnessable — a host comparing the SAML Issuer to the SCIM connection's IdP
+ * entityID has a well-defined, causable negative.
+ *
+ * They live here rather than in `scenarios/auth-subject-link-key-class.test.ts`
+ * on purpose: a scenario file that passes fixture self-tests and soft-skips its
+ * host legs resolves to `executed-pass` in every host's certification bundle
+ * (conformance-certification.md gap G8), which would credit a host that never
+ * advertised subject linking with a witness about a fixture. `src/lib/` tests
+ * run in the published suite but produce no scenario ledger row, exactly like
+ * `oidc-issuer.test.ts`.
+ *
+ * @see conformance/src/lib/saml-idp.ts
+ * @see RFCS/0163-subject-linking-hardening.md §B
+ */
+
+import { describe, it, expect } from 'vitest';
+import { createSyntheticSamlIdp, DEFAULT_SAML_ENTITY_ID } from './saml-idp.js';
+
+const COLLIDING_SUBJECT = 'idp-op-8f3a';
+
+describe('saml-idp: two-trust-root fixture (RFC 0163 §B)', () => {
+  const idpA = createSyntheticSamlIdp({ entityID: 'urn:openwop:conformance:idp-A' });
+  const idpB = createSyntheticSamlIdp({ entityID: 'urn:openwop:conformance:idp-B' });
+
+  it('a lone instance keeps the canonical default entityID (RFC 0050 behaviour unchanged)', () => {
+    const lone = createSyntheticSamlIdp();
+    expect(lone.entityID).toBe(DEFAULT_SAML_ENTITY_ID);
+    expect(lone.verify(lone.mint('valid')).valid).toBe(true);
+  });
+
+  it('the two IdPs have distinct entityIDs and distinct signing keys (distinct trust roots)', () => {
+    expect(idpA.entityID).not.toBe(idpB.entityID);
+    expect(idpA.certificatePem).not.toBe(idpB.certificatePem);
+  });
+
+  it('both IdPs can mint a valid assertion for the SAME colliding subject id', () => {
+    const a = idpA.verify(idpA.mint('valid', { subject: COLLIDING_SUBJECT }));
+    const b = idpB.verify(idpB.mint('valid', { subject: COLLIDING_SUBJECT }));
+    expect(a.valid, `IdP-A must accept its own assertion; got ${a.reason}`).toBe(true);
+    expect(b.valid, `IdP-B must accept its own assertion; got ${b.reason}`).toBe(true);
+  });
+
+  it('the colliding assertions carry DIFFERENT signed Issuers (the trust-root discriminator)', () => {
+    const assertionA = idpA.mint('valid', { subject: COLLIDING_SUBJECT });
+    const assertionB = idpB.mint('valid', { subject: COLLIDING_SUBJECT });
+    expect(idpA.issuerOf(assertionA)).toBe('urn:openwop:conformance:idp-A');
+    expect(idpB.issuerOf(assertionB)).toBe('urn:openwop:conformance:idp-B');
+    expect(idpA.issuerOf(assertionA)).not.toBe(idpB.issuerOf(assertionB));
+  });
+
+  it('IdP-A REJECTS an assertion minted by IdP-B for the same subject (cross-root does not verify)', () => {
+    // The crux of RFC 0163 §B: an identifier collision across two trust roots
+    // is NOT a link. IdP-B signs with a different key AND stamps a different
+    // Issuer, so IdP-A's validator refuses it — a match on the opaque subject
+    // string alone can never authorize across the roots.
+    const crossRoot = idpB.mint('valid', { subject: COLLIDING_SUBJECT });
+    const r = idpA.verify(crossRoot);
+    expect(r.valid, 'an assertion from a DIFFERENT trust root MUST NOT verify against this IdP').toBe(false);
+    expect(r.reason).toBe('bad-signature');
+    expect(idpA.issuerOf(crossRoot)).not.toBe(idpA.entityID);
+  });
+
+  it('the Issuer is inside the signed element: swapping it post-signing breaks verification', () => {
+    // RFC 0163 §B.1 requires the trust-root identity to be signed so it cannot
+    // be rewritten to impersonate another root. Rewrite IdP-B's Issuer to
+    // IdP-A's entityID on an otherwise valid IdP-B assertion: the issuer now
+    // READS as A, but the signature was computed over B's canonical form.
+    const forged = idpB
+      .mint('valid', { subject: COLLIDING_SUBJECT })
+      .replace('<saml:Issuer>urn:openwop:conformance:idp-B</saml:Issuer>', '<saml:Issuer>urn:openwop:conformance:idp-A</saml:Issuer>');
+    expect(idpA.issuerOf(forged)).toBe(idpA.entityID);
+    expect(idpA.verify(forged).valid, 'a re-stamped Issuer MUST NOT verify').toBe(false);
+    expect(idpB.verify(forged).valid, 'the original root MUST NOT verify it either').toBe(false);
+  });
+});

package/src/lib/saml-idp.ts

@@ -16,7 +16,23 @@
  * `auth/saml/validate` test seam; sign/verify here are mutually consistent
  * by construction (the harness owns both the serialization and the digest).
  *
+ * ## Trust roots (RFC 0163 §B)
+ *
+ * Each instance carries a distinct `entityID` — the SAML `Issuer` it stamps
+ * into (and signs into) every assertion. Two instances with different
+ * `entityID`s model two **independent IdP trust roots**: they have distinct
+ * signing keys AND distinct issuers, so an assertion minted by IdP-B does not
+ * verify against IdP-A's certificate and its `Issuer` does not match IdP-A's
+ * entityID. This is the fixture the RFC 0163 §B same-IdP-trust-root behavioral
+ * leg needs: two IdPs can mint an assertion for the **same** opaque `subject`
+ * (an identifier collision) while remaining cryptographically and by-issuer
+ * distinguishable, so a host that joins the SAML and SCIM lanes MUST refuse to
+ * link across the two roots. `issuerOf()` exposes the (signed) `Issuer` so a
+ * scenario — or a host — can assert same-trust-root correspondence before
+ * forming a link.
+ *
  * @see RFCS/0050-saml-scim-enterprise-identity-profiles.md §A
+ * @see RFCS/0163-subject-linking-hardening.md §B (same-IdP trust root)
  * @see spec/v1/auth-profiles.md §`openwop-auth-saml`
  */
 
@@ -52,13 +68,39 @@ export interface SamlVerifyResult {
     | 'malformed';
 }
 
+export interface SyntheticSamlIdpOptions {
+  /**
+   * This IdP's SAML `entityID`, stamped and signed into every assertion as the
+   * `<saml:Issuer>` and exposed as `.entityID`. Two instances with distinct
+   * `entityID`s model two independent trust roots (RFC 0163 §B). Defaults to a
+   * fixed canonical value so a lone instance behaves exactly as before.
+   */
+  readonly entityID?: string;
+}
+
+/** The default single-IdP entityID (unchanged behaviour for a lone instance). */
+export const DEFAULT_SAML_ENTITY_ID = 'urn:openwop:conformance:idp';
+
 export interface SyntheticSamlIdp {
   /** PEM signing certificate (public key) the host configures to trust this IdP. */
   readonly certificatePem: string;
+  /**
+   * This IdP's SAML `entityID` — the `<saml:Issuer>` it signs into every
+   * assertion, and the trust-root identity a host records for the connection.
+   * Distinct per instance (RFC 0163 §B).
+   */
+  readonly entityID: string;
   /** Mint a SAML assertion of the given variant. */
   mint(variant: SamlVariant, opts?: { subject?: string }): string;
   /** Validate an assertion per the RFC 0050 §A MUST list. */
   verify(assertionXml: string): SamlVerifyResult;
+  /**
+   * The `Issuer` (entityID) carried by the consumed assertion, or `null` if the
+   * assertion is malformed. RFC 0163 §B: a host compares this against the SCIM
+   * connection's recorded IdP entityID and MUST NOT form a link across two
+   * distinct trust roots even when the opaque subject id collides.
+   */
+  issuerOf(assertionXml: string): string | null;
 }
 
 const SIG_ALG_RSA_SHA256 = 'http://www.w3.org/2001/04/xmldsig-more#rsa-sha256';
@@ -69,17 +111,21 @@ function digest(input: string): string {
 }
 
 /** Deterministic canonical form of the signed element: the harness controls
- * the exact byte string, so sign/verify agree without a full C14N stack. */
-function canonicalAssertion(id: string, subject: string, notBefore: string, notOnOrAfter: string): string {
+ * the exact byte string, so sign/verify agree without a full C14N stack. The
+ * `<saml:Issuer>` is inside the signed element (RFC 0163 §B: the trust-root
+ * identity is signed, so it cannot be swapped post-signing). */
+function canonicalAssertion(id: string, issuer: string, subject: string, notBefore: string, notOnOrAfter: string): string {
   return (
     `<saml:Assertion ID="${id}" Version="2.0">` +
+    `<saml:Issuer>${issuer}</saml:Issuer>` +
     `<saml:Conditions NotBefore="${notBefore}" NotOnOrAfter="${notOnOrAfter}"/>` +
     `<saml:Subject><saml:NameID>${subject}</saml:NameID></saml:Subject>` +
     `</saml:Assertion>`
   );
 }
 
-export function createSyntheticSamlIdp(): SyntheticSamlIdp {
+export function createSyntheticSamlIdp(opts?: SyntheticSamlIdpOptions): SyntheticSamlIdp {
+  const entityID = opts?.entityID ?? DEFAULT_SAML_ENTITY_ID;
   const { publicKey, privateKey } = generateKeyPairSync('rsa', { modulusLength: 2048 });
   const certificatePem = publicKey.export({ format: 'pem', type: 'spki' }).toString();
 
@@ -97,7 +143,7 @@ export function createSyntheticSamlIdp(): SyntheticSamlIdp {
     refId: string; // the ID the <Reference> points at (≠ id ⇒ wrapping)
     extraInjected?: string; // an unsigned injected assertion (wrapping attack)
   }): string {
-    const inner = canonicalAssertion(parts.id, parts.subject, parts.notBefore, parts.notOnOrAfter);
+    const inner = canonicalAssertion(parts.id, entityID, parts.subject, parts.notBefore, parts.notOnOrAfter);
     const sig =
       parts.signatureValue === null
         ? ''
@@ -115,7 +161,7 @@ export function createSyntheticSamlIdp(): SyntheticSamlIdp {
     const iso = (ms: number): string => new Date(ms).toISOString();
     const past = iso(now - 3_600_000);
     const future = iso(now + 3_600_000);
-    const canonical = canonicalAssertion(id, subject, past, future);
+    const canonical = canonicalAssertion(id, entityID, subject, past, future);
 
     switch (variant) {
       case 'valid':
@@ -127,11 +173,11 @@ export function createSyntheticSamlIdp(): SyntheticSamlIdp {
       case 'bad-signature':
         return envelope({ id, subject, notBefore: past, notOnOrAfter: future, sigAlg: SIG_ALG_RSA_SHA256, signatureValue: Buffer.from('forged').toString('base64'), refId: id });
       case 'expired': {
-        const c = canonicalAssertion(id, subject, iso(now - 7_200_000), past);
+        const c = canonicalAssertion(id, entityID, subject, iso(now - 7_200_000), past);
         return envelope({ id, subject, notBefore: iso(now - 7_200_000), notOnOrAfter: past, sigAlg: SIG_ALG_RSA_SHA256, signatureValue: sign(c), refId: id });
       }
       case 'not-yet-valid': {
-        const c = canonicalAssertion(id, subject, future, iso(now + 7_200_000));
+        const c = canonicalAssertion(id, entityID, subject, future, iso(now + 7_200_000));
         return envelope({ id, subject, notBefore: future, notOnOrAfter: iso(now + 7_200_000), sigAlg: SIG_ALG_RSA_SHA256, signatureValue: sign(c), refId: id });
       }
       case 'signature-wrapping': {
@@ -139,8 +185,8 @@ export function createSyntheticSamlIdp(): SyntheticSamlIdp {
         // second, attacker-injected assertion with a different Subject is what
         // a naive consumer reads. The signed element ≠ the consumed element.
         const benign = 'a-benign';
-        const benignCanonical = canonicalAssertion(benign, subject, past, future);
-        const injected = canonicalAssertion(id, 'attacker@evil.example-opaque', past, future);
+        const benignCanonical = canonicalAssertion(benign, entityID, subject, past, future);
+        const injected = canonicalAssertion(id, entityID, 'attacker@evil.example-opaque', past, future);
         const sig =
           `<ds:Signature><ds:SignedInfo><ds:SignatureMethod Algorithm="${SIG_ALG_RSA_SHA256}"/>` +
           `<ds:Reference URI="#${benign}"><ds:DigestValue>${digest(benignCanonical)}</ds:DigestValue></ds:Reference>` +
@@ -151,21 +197,37 @@ export function createSyntheticSamlIdp(): SyntheticSamlIdp {
     }
   }
 
+  /** Parse the consumed (first) assertion; `null` if it is malformed. */
+  function parseConsumed(assertionXml: string): { id: string; issuer: string; notBefore: string; notOnOrAfter: string; subject: string } | null {
+    // The consumed assertion is the FIRST <saml:Assertion> in the response.
+    const m = /<saml:Assertion ID="([^"]+)"[^>]*>[\s\S]*?<saml:Issuer>([^<]*)<\/saml:Issuer>[\s\S]*?<saml:Conditions NotBefore="([^"]+)" NotOnOrAfter="([^"]+)"\/>[\s\S]*?<saml:NameID>([^<]*)<\/saml:NameID>/.exec(assertionXml);
+    if (m === null) return null;
+    const [, id, issuer, notBefore, notOnOrAfter, subject] = m;
+    return { id, issuer, notBefore, notOnOrAfter, subject };
+  }
+
+  function issuerOf(assertionXml: string): string | null {
+    return parseConsumed(assertionXml)?.issuer ?? null;
+  }
+
   function verify(assertionXml: string): SamlVerifyResult {
     const sigAlg = /<ds:SignatureMethod Algorithm="([^"]+)"/.exec(assertionXml)?.[1];
     const sigValue = /<ds:SignatureValue>([^<]*)<\/ds:SignatureValue>/.exec(assertionXml)?.[1];
     const refId = /<ds:Reference URI="#([^"]+)"/.exec(assertionXml)?.[1];
-    // The consumed assertion is the FIRST <saml:Assertion> in the response.
-    const consumed = /<saml:Assertion ID="([^"]+)"[^>]*>[\s\S]*?<saml:Conditions NotBefore="([^"]+)" NotOnOrAfter="([^"]+)"\/>[\s\S]*?<saml:NameID>([^<]*)<\/saml:NameID>/.exec(assertionXml);
+    const consumed = parseConsumed(assertionXml);
     if (consumed === null) return { valid: false, reason: 'malformed' };
-    const [, consumedId, notBefore, notOnOrAfter, subject] = consumed;
+    const { id: consumedId, issuer, notBefore, notOnOrAfter, subject } = consumed;
 
     if (sigValue === undefined || sigAlg === undefined) return { valid: false, reason: 'unsigned' };
     if (sigAlg === SIG_ALG_NONE) return { valid: false, reason: 'alg-none' };
     // Anti-wrapping: the signature MUST reference the consumed assertion.
     if (refId !== consumedId) return { valid: false, reason: 'signature-wrapping' };
 
-    const canonical = canonicalAssertion(consumedId, subject, notBefore, notOnOrAfter);
+    // The signed canonical includes the Issuer (RFC 0163 §B): an assertion from
+    // a DIFFERENT trust root carries a different Issuer AND is signed by a
+    // different key, so verification against THIS IdP's public key fails
+    // (`bad-signature`). The crypto separation IS the trust-root separation.
+    const canonical = canonicalAssertion(consumedId, issuer, subject, notBefore, notOnOrAfter);
     const ok = createVerify('RSA-SHA256').update(canonical, 'utf8').verify(publicKey, sigValue, 'base64');
     if (!ok) return { valid: false, reason: 'bad-signature' };
 
@@ -175,5 +237,5 @@ export function createSyntheticSamlIdp(): SyntheticSamlIdp {
     return { valid: true, reason: null };
   }
 
-  return { certificatePem, mint, verify };
+  return { certificatePem, entityID, mint, verify, issuerOf };
 }

package/src/scenarios/auth-subject-link-key-class.test.ts

@@ -3,29 +3,38 @@
  * hardening (the declarable, witnessable link-key class + the same-IdP
  * trust-root MUST).
  *
- * Status: DRAFT. RFC 0163 is `Draft` (additive follow-on to RFC 0159, which
- * is `Accepted`). The obligations are documented in `auth-profiles.md`
+ * Status: ACTIVE. RFC 0163 is `Active` (additive follow-on to RFC 0159, which
+ * is `Accepted`); wire shape locked 2026-09-01. The obligations are documented in `auth-profiles.md`
  * §"Subject linking (SAML ⟷ SCIM)" → "Link-key-class declaration and same-IdP
  * trust root — RFC 0163", and are discoverable via
  * `capabilities.auth.subjectLinkKey` (a closed enum) under the same
  * `capabilities.auth.subjectLinking` opt-in as RFC 0159.
  *
  * TWO LEGS:
- *   (§A) ADVERTISEMENT — server-free, runs whenever subjectLinking:true. A
- *        subjectLinking:true host MUST advertise a subjectLinkKey that is a
- *        member of the CLOSED enum {opaque-idp, oid, immutable-id}. Mutable/PII
- *        keys are inexpressible by construction, which is the witness that
- *        converts RFC 0159 §A.2/§A.4's negative-existence prohibition into a
- *        positive advertisement.
+ *   (§A) ADVERTISEMENT — a discovery read, runs whenever subjectLinking:true.
+ *        A subjectLinking:true host MUST advertise a subjectLinkKey that is a
+ *        member of the CLOSED enum {opaque-idp, configured-immutable}. The
+ *        enum names classes, not attributes. Mutable/PII keys are
+ *        inexpressible by construction, which is the witness that converts
+ *        RFC 0159 §A.2/§A.4's negative-existence prohibition into a positive
+ *        advertisement. The schema conditional (subjectLinking:true ⇒
+ *        subjectLinkKey required) is pinned server-free in
+ *        src/lib/capabilities-auth-subject-link.test.ts.
  *   (§B) SAME-IDP TRUST ROOT — behavioral. A SAML(IdP-A) + SCIM(IdP-B)
- *        identifier collision MUST NOT form a cross-lane link. This leg needs a
- *        TWO-TRUST-ROOT fixture (two distinct-entityID synthetic IdPs); it is
- *        DECLARED here and PHASED — soft-skips `blocked` until the fixture is
- *        engineered (RFC 0163 gap G-fixture), mirroring how RFC 0159 phased its
- *        cross-lane behavioral legs. Do not delete this describe block: it is
- *        the placeholder that records the requirement as declared-but-unwitnessed.
+ *        identifier collision MUST NOT form a cross-lane link. This leg is
+ *        backed by the TWO-TRUST-ROOT fixture engineered in
+ *        `conformance/src/lib/saml-idp.ts` (two synthetic IdPs with distinct
+ *        `entityID`s / signing keys minting a colliding subject id — RFC 0163
+ *        gap G-fixture, addressed in #1163). The fixture's own proof (distinct
+ *        roots, colliding subject, signed Issuers, cross-root rejection) lives
+ *        in `src/lib/saml-idp.test.ts` — deliberately NOT in this file, so a
+ *        host that never advertises linking does not record an executed-pass
+ *        about a fixture (certification gap G8). This file carries only the
+ *        live BLACK-BOX leg over the host's SCIM+SAML seams, opt-in via the
+ *        two-IdP env vars below, `inapplicable` until a host wires the seam.
  *
- * @see RFCS/0163-subject-linking-hardening.md
+ * @see RFCS/0163-subject-linking-hardening.md §B (same-IdP trust root)
+ * @see conformance/src/lib/saml-idp.ts — the two-trust-root fixture
  * @see spec/v1/auth-profiles.md §"Subject linking (SAML ⟷ SCIM)"
  */
 
@@ -36,7 +45,7 @@ import { capabilityFamily } from '../lib/discovery-capabilities.js';
 
 const SAML_PROFILE = 'openwop-auth-saml';
 const SCIM_PROFILE = 'openwop-auth-scim';
-const SUBJECT_LINK_KEY_CLASSES = ['opaque-idp', 'oid', 'immutable-id'] as const;
+const SUBJECT_LINK_KEY_CLASSES = ['opaque-idp', 'configured-immutable'] as const;
 
 interface DiscoveryAuth {
   profiles?: string[];
@@ -72,14 +81,14 @@ describe('auth-subject-link-key-class: advertisement shape (RFC 0163 §A)', () =
     ).toBe(true);
 
     // §A.3 — the value MUST be a member of the CLOSED enum of allowed classes
-    // (opaque-idp | oid | immutable-id). Mutable/PII keys (email, userName,
+    // (opaque-idp | configured-immutable). Mutable/PII keys (email, userName,
     // displayName) are absent from the enum by construction, so a conforming
     // host cannot name one.
     expect(
       (SUBJECT_LINK_KEY_CLASSES as readonly string[]).includes(auth.subjectLinkKey ?? ''),
       driver.describe(
         'auth-profiles.md §Subject linking',
-        `RFC 0163 §A.3: subjectLinkKey MUST be one of ${SUBJECT_LINK_KEY_CLASSES.join(', ')} — a closed enum of allowed classes only; a mutable/PII key is inexpressible`,
+        `RFC 0163 §A.3: subjectLinkKey MUST be one of ${SUBJECT_LINK_KEY_CLASSES.join(', ')} — a closed enum of allowed CLASSES (not attributes); a mutable/PII key is inexpressible`,
       ),
     ).toBe(true);
   });
@@ -100,18 +109,68 @@ describe('auth-subject-link-key-class: advertisement shape (RFC 0163 §A)', () =
   });
 });
 
-describe('auth-subject-link-key-class: same-IdP trust root (RFC 0163 §B — PHASED, follow-on fixture)', () => {
-  it('a SAML(IdP-A) + SCIM(IdP-B) identifier collision MUST NOT form a cross-lane link', async () => {
+describe('auth-subject-link-key-class: same-IdP trust root (RFC 0163 §B — behavioral, opt-in two-IdP seam)', () => {
+  // Two distinct trust roots served over two operator-supplied synthetic-IdP
+  // endpoints, plus the RFC 0159 SCIM seam. IdP-A feeds the SCIM lane; IdP-B is
+  // the colliding cross-root SAML issuer. Opt-in and soft-skipping until a host
+  // wires the two-trust-root seam — it MUST NOT fail a host that has not.
+  const idpAUrl = process.env.OPENWOP_TEST_SAML_IDP_URL; // trust root A (also the SCIM lane's IdP)
+  const idpBUrl = process.env.OPENWOP_TEST_SAML_IDP_URL_B; // trust root B (the cross-IdP collider)
+  const scimUrl = process.env.OPENWOP_TEST_SCIM_URL;
+
+  it('a same-IdP link forms (control) but a cross-IdP collision MUST NOT link', async () => {
     const auth = await readAuth();
-    if (auth === null || auth.subjectLinking !== true) {
-      return softSkip('inapplicable', 'capability-gated on auth.subjectLinking');
+    if (auth === null || auth.subjectLinking !== true) return softSkip('inapplicable', 'capability-gated on auth.subjectLinking');
+    if (!idpAUrl || !idpBUrl || !scimUrl) {
+      return softSkip('inapplicable', 'opt-in: the two-trust-root seam needs OPENWOP_TEST_SAML_IDP_URL (IdP-A) + OPENWOP_TEST_SAML_IDP_URL_B (IdP-B) + OPENWOP_TEST_SCIM_URL');
     }
-    // The §B behavioral leg needs a TWO-TRUST-ROOT fixture (two distinct-entityID
-    // synthetic IdPs minting a colliding identifier). That fixture is a declared
-    // follow-on (RFC 0163 gap G-fixture); until it is bundled this leg is
-    // `blocked` (RFC 0148 §A — unobservable, not unmet), exactly as RFC 0159
-    // phased its cross-lane behavioral legs. The requirement is recorded as
-    // declared-but-unwitnessed rather than silently omitted.
-    return softSkip('blocked', 'RFC 0163 §B two-trust-root fixture is a declared follow-on (gap G-fixture)');
+
+    // POSITIVE CONTROL — same trust root both lanes. Provision a SCIM user
+    // whose SCIM connection is fed by IdP-A, then present a valid SAML assertion
+    // from IdP-A for the same opaque id: the link forms and authenticates.
+    // Proving presence here is what keeps the negative leg non-vacuous — "no
+    // cross-IdP link" passes identically on a host that never links at all.
+    const sameId = 'idp-op-same-8f3a';
+    const provSame = await driver.post('/v1/host/sample/auth/scim/provision', {
+      scimUrl,
+      idpUrl: idpAUrl, // the SCIM connection's IdP trust root
+      op: 'create-user',
+      externalId: sameId,
+      userName: 'r.smith',
+    });
+    if (provSame.status === 404) return softSkip('blocked', 'SCIM provisioning seam unwired');
+    expect(provSame.status, driver.describe('auth-profiles.md §Subject linking', 'SCIM provisioning MUST succeed')).toBeLessThan(400);
+
+    const sameIdp = await driver.post('/v1/host/sample/auth/saml/validate', { idpUrl: idpAUrl, variant: 'valid', nameId: sameId });
+    if (sameIdp.status === 404) return softSkip('blocked', 'SAML validate seam unwired');
+    expect(
+      (sameIdp.json as { authenticated?: boolean } | undefined)?.authenticated,
+      driver.describe('auth-profiles.md §Subject linking', 'RFC 0163 §B positive control: a SAML assertion from the SAME IdP trust root as the SCIM lane links and authenticates'),
+    ).toBe(true);
+
+    // THE §B.1 MUST — cross-IdP identifier collision. Provision a SCIM user fed
+    // by IdP-A, then present a valid SAML assertion for the SAME opaque id but
+    // ISSUED BY IdP-B (a different trust root). The string collides; the trust
+    // roots do not. The host MUST NOT form the link, so the assertion MUST NOT
+    // authenticate as the SCIM-provisioned principal.
+    const collideId = 'idp-op-collide-8f3a';
+    const provCross = await driver.post('/v1/host/sample/auth/scim/provision', {
+      scimUrl,
+      idpUrl: idpAUrl, // SCIM lane trust root = IdP-A
+      op: 'create-user',
+      externalId: collideId,
+      userName: 'a.other',
+    });
+    expect(provCross.status, driver.describe('auth-profiles.md §Subject linking', 'SCIM provisioning MUST succeed')).toBeLessThan(400);
+
+    const crossIdp = await driver.post('/v1/host/sample/auth/saml/validate', { idpUrl: idpBUrl, variant: 'valid', nameId: collideId });
+    if (crossIdp.status === 404) return softSkip('blocked', 'SAML validate seam unwired');
+    expect(
+      (crossIdp.json as { authenticated?: boolean } | undefined)?.authenticated === true,
+      driver.describe(
+        'auth-profiles.md §Subject linking',
+        'RFC 0163 §B.1: a SAML assertion from IdP-B colliding on an identifier the SCIM lane provisioned from IdP-A MUST NOT form a cross-lane link (no cross-IdP identifier collision joins two principals)',
+      ),
+    ).toBe(false);
   });
 });

package/src/scenarios/auth-subject-link.test.ts

@@ -2,7 +2,7 @@
  * auth-subject-link — RFC 0159: SCIM ⟷ SAML subject linking (the combined
  * leaver contract).
  *
- * Status: DRAFT. RFC 0159 is `Active` (amends RFC 0050). The obligation is
+ * Status: ACCEPTED. RFC 0159 is `Accepted` (amends RFC 0050; hardened by RFC 0163). The obligation is
  * documented in `auth-profiles.md` §"Subject linking (SAML ⟷ SCIM)" and is
  * discoverable via `capabilities.auth.subjectLinking`.
  *