verifier-base-verification (v0.1): confirm the MVP reading of steps 4.2.1–4.2.8 for a self-issued EAA

[RastaChaum]

Context

rulebooks/rb-base/verifier-base-verification.md is still v0.1 "Initial draft" (06.05.2026) and carries unresolved inline remarks (e.g. terminology at 4.2.2 — "is 'authentication' the right term?", and "[Do we need this?]" around 4.2.1). It defines the 8 verification steps:

• 4.2.1 cryptographic integrity & signature validity
• 4.2.2 authenticity / "genuinity"
• 4.2.3 issuer identity
• 4.2.4 issuer authorization & acceptance
• 4.2.5 validity periods / expiration
• 4.2.6 revocation / suspension
• 4.2.7 WUA verification (wallet integrity)
• 4.2.8 holder binding

Steps 4.2.2–4.2.4 are specified as TLOL-based for QEAAs. But IBAN-OV is an EAA — and the rulebook itself states (l. 38) that an EAA "is and can not be included in the TLOL". The ADR referenced at l. 66 ("EAA provider identity verification based on chaining and TLOL") is the open design point here (tracked in #48).

The MVP reading we plan to implement

Given the PA3 MVP sets mutual authentication to true, we plan to:

• implement 4.2.1, 4.2.5, 4.2.6 fully;
• treat 4.2.2–4.2.4 as trust-by-configuration (a self-issued EAA cannot be validated via the TLOL the QEAA way, pending the chaining ADR / Enable EAA Provider identification via chaining #48);
• skip 4.2.7 and 4.2.8 (WUA / device binding) for the MVP.

Is that the expected MVP reading for conformance purposes?

[RastaChaum]

Gentle bump — no feedback yet on this one, and it's currently blocking our Verifier implementation for PA3.

To keep it concrete, could you confirm (or correct) the MVP reading we plan to implement against verifier-base-verification for a self-issued EAA (IBAN-OV), with mutualAuthentication: true:

• 4.2.1 / 4.2.5 / 4.2.6 — implemented fully (crypto integrity, validity period, revocation).
• 4.2.2–4.2.4 — treated as trust-by-configuration for the MVP, since an EAA is not in the TLOL and the chaining ADR is still open (tracked in Enable EAA Provider identification via chaining #48).
• 4.2.7 / 4.2.8 (WUA / holder device binding) — skipped for the MVP.

If that's the expected reading for conformance purposes, we'll proceed on it; if 4.2.2–4.2.4 are meant to be handled differently pending #48, we'd rather align now than rework later. Happy to move this to whichever channel is best if issues aren't the right place. cc @flo0x