OpenID4VP request nonce is incompatible with [certain] payment authorization schemes

It seems that there is a requirement for a nonce in requests:
https://openid.github.io/OpenID4VP/openid-4-verifiable-presentations-wg-draft.html#section-5.2

This is necessary in authentication scenarios, but incompatible with universal payment authorization schemes like https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/issues/388.

Why is that? Because Merchants are not relying parties, the Issuers are, but the actual Issuer is not known at the time of the request.

This may look like a serious problem with the authorization scheme since it would open the door to "replay". However, in similarity to authentication schemes where you create a session, payment authorization objects would rather contain a time-stamp which enables authorization objects received by an Issuer to be temporarily cached. An authorization object that is too new or too old will be rejected. In fact, this scheme potentially enables IDEMPOTENT operation, adding robustness to the authorization process by permitting retransmissions.

Authorization objects would typically be hashed to enable quick lookups.

In addition, payment requests already contain a nonce (a request id), but such identifiers do typically not have "cryptographic" qualities. In my specific implementation, the wallet generates a cryptographically sound nonce. This makes perfect sense since wallets must be able to generate secure keys.

This is essentially a copy of how EMV works.

Start with the OpenID4VP specification section 5.2 and compare its nonce requirement with the payment authorization scheme described in EUDI issue 388. Determine whether the protocol needs a clarified or changed treatment of payment requests, and document the resulting security and replay-handling requirements.