client_id, nonce and state
Three request parameters recur throughout the binding guarantees: client_id, nonce, and state. The table
above already put them to work; here is what each one means on its own, since they travel through the same
request/response cycle and are easy to conflate.
client_id
client_id identifies your Relying Party to the wallet. In the EUDI ecosystem it uses the x509_hash scheme: the
value is x509_hash: followed by the encoded hash of your Access Certificate. Because
that value is derived from one specific certificate, the wallet can check that a signed request really came from the
party holding it. This authenticates who is asking before the
wallet ever shows the user anything, and it is what the holder's proof of possession binds itself to later: that proof
includes your client_id as its audience, so the presentation cannot be silently redirected to a different Relying
Party without invalidating the signature.
For the exact calculation, see Calculating the client_id.
nonce
nonce is a fresh, unpredictable value your backend generates for every presentation request and embeds in the
signed request object served to the wallet. The wallet is required to include that exact value inside the proof of
possession it signs with the holder's private key, alongside your client_id. When the response comes back, you
compare the nonce inside that signed proof against the value you generated. A match confirms the cryptographic proof
was produced for this specific request, not reused from an earlier or unrelated one.
state
state is an opaque value your backend generates per user session and includes in the request. The wallet returns it
unchanged in the response envelope, so your backend can look up which waiting session a given response belongs to.
This is the same role state plays in plain OAuth 2.0 and OpenID Connect redirect flows. Unlike client_id and nonce,
state is not part of the holder's cryptographic proof; it is a correlation handle for your own session bookkeeping.
Further Reading
| Documentation | Read this, when ... |
|---|---|
| OpenID4VP: Terminology | ... you want the formal spec definitions behind holder and session binding |