From Back-End to Wallet: OID4VP and OID4VCI in the Gaia-X Compliance Dispatcher

OID4VP (OpenID for Verifiable Presentations) is the “show me your credentials” half – it’s how the dispatcher asks the wallet for proof of who the user/organisation is, and how the wallet packages and signs that proof so the dispatcher can verify it came from a genuine, untampered credential. OID4VCI (OpenID for Verifiable Credential Issuance) is the “here’s your new credential” half – it covers how a fresh credential is offered to a wallet, how the wallet authenticates itself (via the pre-authorised code and proof of possession), and how it pulls down and stores the result. The wallet evaluates this query against whatever credentials it’s holding, picks out the ones that match, and returns them – a structured, machine-readable way of saying “show me exactly these, in exactly this shape,” with no back-and-forth needed. That one identity covers a few different signing jobs, each with its own short lifespan: the issuer and verifier metadata, the authorisation request JWT the wallet fetches (a 5-minute JAR, typ: oauth-authz-req+jwt), and the verifiable presentation the dispatcher itself builds when talking to the extension. There’s also a bit of state to keep track of between the initial QR scan and the vp_token landing later on – handled by Redis with a handful of short-lived, single-use, prefixed keys (nonces, pre-authorised codes, tokens), each consumed atomically so nothing can be replayed. That already works well for mobile wallets that the scheme, but it’s also the foundation for where this is headed next: that same URI can double as a deep link, letting web-based wallets expose it directly to their users and skip the QR code altogether.