[ottonomy]

Closes #63. Closes #64.

Why

fatal decided two things at once: a failure made verified false, and it halted every later check. So:

• An expired or not-yet-valid credential stopped at proof.signature. Status, registry and any added suites came back "Not run", even though the credential is authentic: @digitalcredentials/vc checks dates only after the proof verifies. A revoked-and-expired credential read only "Expired" (Expiry halts verification, so a revoked-and-expired credential reports only expiry #63).
• A revoked credential stopped at status.bitstring, so status.list-issuer never ran on a list that marked a credential. A revocation from a list signed by someone else read as a plain revocation (A revocation mark on a list signed by another DID is reported as a revocation, with no sign the list isn't the issuer's #64).

What changed

• halts?: boolean on VerificationCheck / CheckResult, defaulting to fatal. A fatal check with halts: false still makes verified false, but the checks after it run. Existing checks and caller suites behave as before, and their rows keep their shape.

• New proof.validity-period check (fatal, halts: false), run after proof.signature. It judges validFrom/validUntil (v2) or issuanceDate/expirationDate (v1) against the verifier's TimeService, and reports CREDENTIAL_EXPIRED / CREDENTIAL_NOT_YET_VALID.

• proof.signature reads a date-only rejection as a verified signature. The Data Integrity crypto service reports vc's date failure as a typed problem only when all of these hold:

  • it is a plain Error;
  • it is not a VerificationError;
  • it has no errors[];
  • its message matches vc's wording in full.

  So a date phrase quoted inside a wrapped proof error never counts. The CryptoService TSDoc states the contract.

• status.bitstring stays fatal but sets halts: false. It now classifies an expired status list by problem type, not by message text.

• status.list-issuer compares only lists whose proof verified (or was rejected only for its dates), so it now runs, and reports, after a revocation mark. Each list's proof verification is memoised per verification, beside the existing memo of loaded lists, so both checks share one verification per list.

• Docs: README, docs/api/verification-results.md, docs/architecture.md, CHANGELOG. More than one suite can now carry fatalFailureAt; verified is false exactly when any does.

verified does not change for any input.

Checked locally

• pnpm run build: clean.
• pnpm run test (lint + vitest): 941 passed, up from 907 on main.
• pnpm exec tsc -p tsconfig.dev.json: the same 6 errors as main.
• The ordering guard. Offline tests with real signatures check that a credential that is tampered and expired (v1 and v2) still reports a signature failure, with proof.validity-period "Not run". If a future vc checked dates before the proof, these tests fail.
• Removing each safeguard fails its test. Checked for the VerificationError name check, the errors[] check, the anchored match, proof.signature passing any rejection, status.bitstring's halts: false, and list-issuer trusting unverified lists.
• New offline real-signature cases:
  • revoked + expired → both problems; list issuer and registry still run;
  • a mark on a foreign list → CREDENTIAL_REVOKED + STATUS_LIST_ISSUER_MISMATCH;
  • an expired foreign list → STATUS_LIST_EXPIRED + mismatch;
  • an unverified list → list-issuer skipped.
• Not run: test:browser (Playwright).

For consumers

Expiry now appears on cryptographic.proof.validity-period, not on cryptographic.proof.signature. A UI should expect more than one suite with fatalFailureAt, and results for rows that used to be "Not run" after an expiry or revocation.

🤖 Generated with Claude Code