test: third-party OpenID4VP `vp_token` interop vector (capture from the EUDI RI wallet+verifier pair)

[luisgf]

Split out of #115 (2026-07-16 sourcing review). Two of #115's three checkboxes (a third-party SD-JWT VC and the W3C Bitstring decode vector) are actionable and land there; this issue tracks the remaining one, which is blocked on the ecosystem publishing a static artifact.

Why

verify_vp_token's e2e vector is self-recorded: openvc builds the vp_token it then verifies. A vp_token produced by another implementation would pin real interop of the presentation layer (DCQL response shape, KB-JWT binding, credential-format nesting), not just of the inner credential.

What exists today (checked 2026-07-16)

• OpenID4VP 1.0 (Final, 2025-07-09) elides every example token — §8.1.1 shows "eyJhb...YMetA"; there is no complete base64 credential string nor any example key material in the whole document (checked mechanically).
• The OIDF conformance suite (certification.openid.net) is a live, interactive harness — self-certification for OID4VP 1.0 / OID4VCI 1.0 / HAIP 1.0 opened 2026-02-26 — and publishes no downloadable vectors.
• The EUDI reference implementation commits no complete vp_token response (the verifier README's example is a dummy; the Postman collection carries none). Its dev verifier (verifier.eudiw.dev) produces real vp_tokens only interactively.
• Constituent pieces do exist (the EUDI PID SD-JWT VC + its holder key, vendored via test: third-party interop vectors (SD-JWT VC, OpenID4VP, W3C Bitstring) #115) — but a vp_token we assemble ourselves from them is our presentation-layer output, not a third-party artifact, so it does not close this gap.

Scope (when unblocked)

• Vendor an externally-produced OpenID4VP 1.0 vp_token (with enough published key material to verify offline) under tests/fixtures/, with provenance + retrieval date in the fixture README.
• Verify it end to end through verify_vp_token (positive), plus a tamper negative.

Gate / unblock conditions (any of)

• The OIDF conformance suite (or the OpenID4VP spec repo) publishes static test vectors with keys.
• The EUDI reference implementation commits a complete example vp_token response with verifiable keys.
• Another serious implementation (wallet or verifier) publishes a static, signed, verifiable vp_token artifact.

Invariants: offline & deterministic test suite; tests/ is not a package. Feeds the external-audit (#75) conformance-evidence story, same as #115.

[luisgf]

Sourcing re-check 2026-07-17 — a capture path exists; re-scoping the acceptance

Still true that nobody publishes a static third-party vp_token. But the 2026-07-17 review found a practical path that honours this issue's intent (an artifact produced by someone else's stack, pinning real presentation-layer interop):

• The EUDI reference verifier (eudi-srv-web-verifier-endpoint-23220-4-kt, Apache-2.0, OpenID4VP 1.0 + DCQL), driven with the reference wallet, produces a genuine third-party vp_token (SD-JWT VC + KB-JWT). Captured once and vendored with provenance (endpoint, wallet build, date, request transcript), it verifies offline — cnf and the issuer x5c travel inside — exactly like the test: third-party interop vectors (SD-JWT VC, OpenID4VP, W3C Bitstring) #115 PID fixture.
• The ETSI EAA Plugtests (2026 round: 4 May–30 Jun, TS 119 472-1 SD-JWT VC / mdoc, 15k+ cross-vendor tests) are the richest source of real artifacts, but access is participant-only → registering for the next round is the other unblock (and feeds the security: external review of the verification core + hand-rolled codecs (funded audit) #75 conformance-evidence story).

Re-scope: acceptance now includes an interactively captured, provenance-documented third-party token, not only a published static one. The capture itself is a manual session (reference wallet on a device against the reference verifier); the scope checkboxes are otherwise unchanged.

→ Moving to «Q3–Q4 2026 — eIDAS deadline & ecosystem refresh» (actionable, no longer waiting on the ecosystem).