Requirements on nonce and client_id inclusion too specific for QES

[sander]

I’m working on a “Wallet-centric” model for creating Qualified Electronic Signatures or Seals (QES) over OID4VP. In this use case, we are facing issues with some OID4VP requirements as of WG-Draft 2025-05-16.

Use case context

In the “Wallet-centric” design:

• Credential = X.509 certificate
  • Format: https://cloudsignatureconsortium.org/2025/x509 from CSC DM v0.2.0
  • Claims:
    • Subject Distinguished Name / Alternative Name
    • Subject Public Key Info
    • Qualified Certificate Statements
• Issuer = Qualified Trust Service Provider issuing the certificate
• Holder = EUDIW user where:
  • the Wallet Instance has an integrated Signature Creation Application
  • the Signature Creation Application applies a (local/external/remote) Qualified Signature or Seal Creation Device (QSCD)
  • the QSCD protects the private key to which the Subject Public Key Info refers
• Verifier = Driving Application, a Relying Party Instance that in a transaction:
  • can provide a document in any format (usually XML/JSON/PDF) and QES creation parameters
  • can validate a QES over that document
• Presentation = QES
  • Transaction Data: https://cloudsignatureconsortium.org/2025/qes from CSC DM v0.2.0 where:
    • the data includes or referes to the document, QES creation parameters, and QES creation rules
    • the returned VP Token includes the QES, verifiably bound to these data

In my interpretation:

• The transaction entails:
  • the request for QES;
  • the QES or rejection response.
• The QES provides Cryptographic Holder Binding, as required for the application of OID4VP transaction data.
• The QES provides no replay detection capabilities. There is no guarantee that it was generated in response to a specific request. However, the Verifier may choose to include fresh application-specific data in the QES request that is expected to be signed in the QES response.

Problematic requirements in OID4VP

• Required nonce creation. § 5.2 Existing Parameters: the Verifier is REQUIRED to create a nonce. This serves two purposes:
  • “securely link the request and response” (transaction binding): redundant in QES-only transactions, since the document or QES parameters in transaction_data fulfills exactly this role.
  • “replay protection in the Holder Binding proof” (replay protection): not applicable in a standard way to QES.
• Required nonce and client ID presentation. § 14.1.2 Verifiable Presentations requires the Wallet to include the client_id and the nonce in the VP, and the Verifier to verify this binding. This serves one purpose:
  • “to detect and prevent replay attacks” (replay protection): not applicable in a standard way to QES.

We may find more conflicting requirements as we dive deeper into this application. We should look carefully at use cases where QES is combined with other transactions in a single OID4VP interaction.

There may be impact to OID4VP applications that depend on nonce as a request identifier for response correlation.

Proposed approach

Generalise these requirements so that the credential format must/should/can enable the Verifier to implement transaction binding and/or replay protection, providing the inclusion of nonce and client_id as one possible means.

First, I’m curious if the WG agrees with this interpretation and approach. Then, we can look for a way to communicate this in the OID4VP specification or supplementary material. In parallel, CSC can take this information into its work on CSC DM.

[sander]

Related issues:

• Define how other specifications define profiles of OID4VP for other credential formats #170
• Binding Response Code to Session #27
• Allow VP as authorization in authorization request #26
• OpenID4VP request nonce is incompatible with [certain] payment authorization schemes #416
• Use of client_id #600
• Clarification to mandatory use of client_id #599

[Sakurann]

WG discussion:

WG believes this has already been addressed by allowing non-key bound credentials in https://openid.net/specs/openid-4-verifiable-presentations-1_0.html#nkb-credentials, which says

Without the key binding proof, nonce is not returned in the response. To maintain the binding between request and response

clarification: RP would always need to generate a nonce even when only non-key bound credentials are returned.

clarification of the flow: RP needs a QES. RP asks wallet for QES using openid4vp with transaction data. wallet somehow creates and returns QES (x509?) to the RP (without crypto key binding in the sense of how it's defined in openid4vp).

action point might be to clarify how transaction data is used with non-key bound credentials (@paulbastian @sander to follow up)

[sander]

@paulbastian FYI we actually have two use cases for QES transaction data:

• Wallet-centric: RP asks Wallet to approve QES creation. The X.509 certificate is presented with QES.
• Provider-centric: QTSP asks Wallet to approve QES creation. A service credential (typically mdoc or SD-JWT) is presented with Cryptographic Holder Binding to QES transaction data. This resembles the payments use case.

[sander]

The clarification is sufficient: the QES presentation is not an OID4VP Verifiable Presentation, since no Cryptographic Holder Binding is defined that protects against replaying it. This means that the nonce and client_id requirements are not problematic for this use case.