test(openid4vci): record real Credential Offers, Issuer Metadata and key proofs from a live issuer/wallet pair

[luisgf]

ADR-0007 D10 settles what conformance evidence the OID4VCI work can and cannot get:
the OIDF self-certification suite is a black-box HTTP harness driving a live issuer, so
it cannot test a library that ships no server, and openvc must never claim issuer
certification. What is obtainable, and what D10 asks for, is real recorded material:

• Credential Offers and Issuer Metadata from a real issuer — the vectors feat(openid4vci): parse untrusted Credential Offers and Issuer Metadata #142 needs to
  parse against something other than our own opinion of the shape;
• key-proof JWTs captured from a real wallet, verified with a frozen clock, the
  technique already used for the EUDI PID fixtures.

This issue is the follow-up the ADR files for that capture.

Why it matters more than it looks

tests/fixtures/trustlist/real/README.md is this repo's own evidence that self-made
fixtures hide total-failure bugs: shapes we generate ourselves only prove we agree with
ourselves. The key-proof verifier is the highest-consequence code path added in the
1.22 cycle — a wrong-accept there hands an attacker a credential bound to a key they do
not control — and today it is pinned entirely by vectors we wrote.

Scope

• tests/fixtures/openid4vci/, each file with a _provenance note naming source, date
  and software version:
  • Credential Offers and Issuer Metadata from the EU reference issuer
    (eu-digital-identity-wallet/eudi-srv-web-issuing-eudiw-py).
  • Credential Request bodies with real openid4vci-proof+jwt proofs, captured from the
    EUDI reference wallet against a live Credential Endpoint.
• Verify the captured proofs with now= pinned, so the fixtures do not rot.
• Add the spec's own §8.2 / App. F.1 examples as shape pins alongside them.

A source for the wallet-side capture

A downstream Django issuer is being built on the ADR-0007 consumer contract and will run
a real EUDI reference wallet against its own Credential Endpoint as part of its interop
milestone. That run produces exactly the request bodies and proofs this issue wants, and
they can be contributed back here with provenance. Coordinating the two means the
capture costs an export rather than a separate harness — worth waiting for rather than
building a shim.

Releases are not gated on this (D10: ship on self-made signed vectors first, as the
LoTE work did in 1.22.0).

Related

• feat(openid4vci): parse untrusted Credential Offers and Issuer Metadata #142 — the parsers these offer/metadata vectors are for.
• test: third-party OpenID4VP vp_token interop vector (capture from the EUDI RI wallet+verifier pair) #121 — the same exercise on the OpenID4VP side.

[luisgf]

#149 lands the half of this that does not need a live wallet, and leaves the issue open.

Done

• tests/fixtures/openid4vci/spec/ — the spec's own examples. App. F.1's jwt proof
  turns out to be a complete, genuinely signed ES256 token, not an illustration: it
  now verifies end-to-end with the clock frozen to its own iat (1701960444), which
  pins the typ check, the algorithm allow-list, the key↔alg binding, the
  signing-input assembly and the aud/iat/nonce logic against bytes we did not
  produce. Plus the three §8.2 Credential Request examples.
• tests/fixtures/openid4vci/real/ — Issuer Metadata and two Credential Offers recorded
  from https://issuer.eudiw.dev on 2026-07-27, the offers in the deep-link form a
  wallet receives (<scheme>://credential_offer?credential_offer=<percent-encoded JSON>),
  not pre-decoded. 27 credential configurations, batch_credential_issuance.batch_size
  100, a nonce_endpoint, request/response encryption blocks, per-config
  proof_types_supported carrying key_attestations_required — the shape feat(openid4vci): parse untrusted Credential Offers and Issuer Metadata #142's parsers
  will have to survive, and none of it what we would have invented.
• Provenance is enforced: a test re-checks each recorded artifact against the
  sha256 in tests/fixtures/openid4vci/README.md. For the spec/ vectors the
  _provenance note lives inside the file; for the recorded ones it lives in the README,
  because an artifact recorded to show what the ecosystem actually sends stops being that
  the moment a member is added to it.

What it caught immediately — §8.2 lets each proof type define its element type
(jwt a string, di_vp a JSON object per App. F.2), so a spec-valid di_vp request hit
the "entries must be non-empty strings" shape check and was reported as
CredentialRequestMalformed, not the UnsupportedProofType the module documents. Fixed
in the same PR. Fail-closed either way; what was wrong was the signal a Credential
Endpoint maps to invalid_proof. This is the argument for the issue in one bug.

Still open, which is why this issue is

• Key proofs captured from a real wallet. Nothing here came from a shipping wallet.
  It needs a live Credential Endpoint for the wallet to POST to, which core does not ship
  (ADR-0007 D1) — so it still waits on the downstream Django issuer's interop run, as the
  issue plans. The gap is stated in the fixtures README rather than papered over.
• A pre-authorized-code offer. The EU reference issuer only mints one after a form of
  synthetic personal data is submitted to it. Not a trade worth making for a shape that
  can be read off §4.1.1; it can come from the same downstream run.

[luisgf]

#149 is merged and shipped in v1.23.1.

Staying open for the one thing that still needs an artifact that does not exist yet: key proofs captured from a shipping wallet, which needs a live Credential Endpoint core does not ship (ADR-0007 D1). The downstream Django issuer's interop run is the source, as planned above; a pre-authorized-code Credential Offer can come from the same run.

Everything obtainable without it is in: the spec's own signed App. F.1 proof (verifying under a frozen clock), the §8.2 request shapes, and Issuer Metadata plus two Credential Offers recorded from the EU reference issuer with sha256-enforced provenance.