@openwop/openwop-conformance 1.144.0 → 1.146.0

package/README.md

@@ -94,7 +94,7 @@ Exit code is non-zero on any failed assertion. `--certify` distinguishes: `0`
 
 ## What's Covered
 
-The current suite has 467 scenario files under `src/scenarios/`.
+The current suite has 468 scenario files under `src/scenarios/`.
 - 2026-08-19 (suite `1.137.0 → 1.138.0`): NEW `durability-poison-exhaustion.test.ts` — RFC 0158 §C.8, the FIRST row of that RFC's conformance table to land. Asserts what `failure-path.test.ts` cannot: not just that deterministically failing work reaches terminal, but that attempts STOP — counted on the log, re-counted after a scaled quiet window, asserted unchanged. A host still redelivering records more. Seam-gated on the existing event-log seam (`blocked` = unobservable, not unmet) and outside every profile floor.
 - 2026-08-19 (suite `1.136.15 → 1.137.0`): NEW `replay-fanout-suppression.test.ts` — capability-gated on `webhooks.supported`, **outside every profile floor**; witnesses `replay.md` §"Host-initiated fan-out is an external effect", which was the largest normative MUST NOT on the replay surface with no scenario and no SECURITY invariant. Three legs in ONE `it` against ONE receiver and ONE subscription — a positive control, the MUST NOT, and a `branch` boundary leg — because "no delivery arrived" passes identically when delivery never worked, so absence is asserted only after presence is proven on that exact wiring. A host with an SSRF guard correctly refuses the loopback receiver and records `blocked`: **unobservable, not unmet.**
 - 2026-08-18 (suite `1.136.7 → 1.136.8`, SP-04): NEW `spec-section-citations.test.ts` — server-free; a `<doc>.md §"<Section>"` citation of a checked doc MUST resolve to a heading that exists. `storage-adapters.md §"Claim acquisition"` was cited by four artifacts, including a normative MUST in `production-profile.md` §Durability, and the section did not exist for the life of RFC 0009. Scoped to the docs whose section citations carry the durability contract; a corpus-wide sweep finds ~260 unresolved citations that need triage before they can gate.
@@ -438,7 +438,7 @@ Server-required (added in 1.7.0):
 | ------------- | ----------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
 | **Redaction** | [`capabilities.md`](../spec/v1/capabilities.md) §"Secrets" + NFR-7 + §"aiProviders" | Vendor-neutral assertions that the server doesn't leak secret material. Three scenario groups: (a) discovery shape contract — `secrets` + `aiProviders` advertisements are well-formed regardless of `secrets.supported`; when `supported === true`, scopes MUST be non-empty + `resolution === 'host-managed'`; `byok ⊆ supported`. (b) bearer-token redaction — invalid Bearer canary in `Authorization` header is not echoed in the 401 response body. (c) credentialRef echo control — gated on `secrets.supported === true`; canary planted in `configurable.ai.credentialRef` MUST NOT appear in any RunEvent payload (poll-based capture; transport-agnostic). Uses runtime-built canary fixtures (`lib/canaries.ts`) that defeat static secret scanners. 6 scenarios. |
 
-Current source tree: 467 scenario files. Use [`coverage.md`](./coverage.md) for current grade/gap tracking.
+Current source tree: 468 scenario files. Use [`coverage.md`](./coverage.md) for current grade/gap tracking.
 
 ## Remaining Gaps
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@openwop/openwop-conformance",
-  "version": "1.144.0",
+  "version": "1.146.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.144.0",
-  "corpusCommit": "1aca8bb8ebdfaf23b33283f9c313aacfebfd4f07"
+  "suiteVersion": "1.146.0",
+  "corpusCommit": "aedaa189e427ef0f62db402c1b97f1d8a3ebb9ca"
 }

package/schemas/capabilities.schema.json

@@ -3695,6 +3695,11 @@
           "type": "boolean",
           "description": "RFC 0159 (auth-profiles.md \u00a7Subject linking). When true, this host advertises BOTH `openwop-auth-saml` and `openwop-auth-scim` AND honours the cross-profile subject-linking obligation: it links the SAML and SCIM principals of one human on an opaque, IdP-stable subject id (SCIM `externalId` \u2194 persistent SAML `NameID`), same-tenant only, and on SCIM deactivation fail-closes the linked SAML identity too (composing RFC 0049 \u00a7C) \u2014 so a provisioned leaver cannot still SSO in. The link key MUST NOT be a mutable/PII attribute (email, userName). Optional; absent/false means the SAML and SCIM lanes are independent and the combined leaver guarantee is NOT claimed. A host MUST NOT set this true unless both profiles are advertised and the obligation holds."
         },
+        "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)."
+        },
         "rotation": {
           "type": "object",
           "description": "API-key rotation advertisement (auth-profiles.md \u00a7`openwop-auth-api-key-rotation`).",

package/src/lib/spec-coherence-registry.test.ts

@@ -119,3 +119,37 @@ describe('resolveFileRecord classifies a corpus scenario as inapplicable, not bl
     expect(r.disposition).toBe('executed-pass');
   });
 });
+
+describe('the published layout is what makes these rows comparable across hosts', () => {
+  // Load-bearing and, until now, tested nowhere.
+  //
+  // A spec-coherence row is `inapplicable` only when V1_DIR is null, and V1_DIR
+  // is null only when the layout resolves to `published`. Two peers established
+  // by measurement what the code implies: `resolveLayout()` keys off PKG_ROOT,
+  // not the consuming repo, so an npm-installed consumer's parent is always
+  // `node_modules/@openwop/` — which never contains `schemas/` no matter where
+  // the host's checkout sits on disk. Every npm-consuming host therefore gets
+  // the same answer, and the dispositions are comparable BY CONSTRUCTION.
+  //
+  // One peer had generalised the opposite way — "the disposition is a property
+  // of where the bundle was cut" — from a host whose own runner sets
+  // OPENWOP_CONFORMANCE_ROOT when it finds a sibling checkout. True of that
+  // host, false of the artifact. The distinction only survives if something
+  // holds the artifact to it.
+  //
+  // The thing that would break it is a change that looks HELPFUL: adding
+  // `spec` to `files` so "the corpus tests run for consumers too". That would
+  // silently give npm consumers V1_DIR, the 28 would execute instead of
+  // flipping, and every host's numbers would shift with no failure anywhere.
+  it('the published package ships no spec/ — so V1_DIR is null for npm consumers', () => {
+    const pkg = JSON.parse(readFileSync(join(SCENARIOS, '../../package.json'), 'utf8')) as { files: string[] };
+    expect(
+      pkg.files.filter((f) => f === 'spec' || f.startsWith('spec/')),
+      'adding spec/ to `files` would give npm consumers a V1_DIR, so the spec-coherence rows would execute '
+        + 'instead of reporting `inapplicable` — changing every host bundle with no test going red',
+    ).toEqual([]);
+    // schemas/ IS shipped, and is what selects the `published` layout. If this
+    // ever stops being true the layout resolves to neither branch.
+    expect(pkg.files, 'schemas/ is what makes resolveLayout() pick `published`').toContain('schemas');
+  });
+});

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

@@ -0,0 +1,117 @@
+/**
+ * auth-subject-link-key-class — RFC 0163: SCIM ⟷ SAML subject-linking
+ * 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`
+ * §"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.
+ *   (§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.
+ *
+ * @see RFCS/0163-subject-linking-hardening.md
+ * @see spec/v1/auth-profiles.md §"Subject linking (SAML ⟷ SCIM)"
+ */
+
+import { describe, it, expect } from 'vitest';
+import { softSkip } from '../lib/soft-skip.js';
+import { driver } from '../lib/driver.js';
+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;
+
+interface DiscoveryAuth {
+  profiles?: string[];
+  subjectLinking?: boolean;
+  subjectLinkKey?: string;
+}
+
+interface DiscoveryDoc {
+  capabilities?: { auth?: DiscoveryAuth };
+  extensions?: { auth?: DiscoveryAuth };
+}
+
+async function readAuth(): Promise<DiscoveryAuth | null> {
+  const res = await driver.get('/.well-known/openwop');
+  const body = res.json as DiscoveryDoc | undefined;
+  return capabilityFamily<DiscoveryAuth>(body, 'auth') ?? body?.extensions?.auth ?? null;
+}
+
+describe('auth-subject-link-key-class: advertisement shape (RFC 0163 §A)', () => {
+  it('subjectLinking:true requires a subjectLinkKey drawn from the closed safe-class enum', async () => {
+    const auth = await readAuth();
+    if (auth === null || auth.subjectLinking !== true) {
+      return softSkip('inapplicable', 'auth.subjectLinking not claimed');
+    }
+
+    // §A.1 — a subjectLinking:true host MUST advertise a subjectLinkKey.
+    expect(
+      typeof auth.subjectLinkKey === 'string' && auth.subjectLinkKey.length > 0,
+      driver.describe(
+        'auth-profiles.md §Subject linking',
+        'RFC 0163 §A.1: a host advertising capabilities.auth.subjectLinking:true MUST also advertise capabilities.auth.subjectLinkKey',
+      ),
+    ).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,
+    // 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`,
+      ),
+    ).toBe(true);
+  });
+
+  it('subjectLinkKey is only claimed alongside both SAML and SCIM profiles (rides the RFC 0159 §B gate)', async () => {
+    const auth = await readAuth();
+    if (auth === null || auth.subjectLinkKey === undefined) {
+      return softSkip('inapplicable', 'auth.subjectLinkKey not claimed');
+    }
+    const profiles = auth.profiles ?? [];
+    expect(
+      profiles.includes(SAML_PROFILE) && profiles.includes(SCIM_PROFILE),
+      driver.describe(
+        'auth-profiles.md §Subject linking',
+        'RFC 0163: subjectLinkKey is meaningful only when both openwop-auth-saml and openwop-auth-scim are advertised (it names the class the two lanes are joined on)',
+      ),
+    ).toBe(true);
+  });
+});
+
+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 () => {
+    const auth = await readAuth();
+    if (auth === null || auth.subjectLinking !== true) {
+      return softSkip('inapplicable', 'capability-gated on auth.subjectLinking');
+    }
+    // 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)');
+  });
+});