You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
cyberphone
changed the title
OpenID4VP request nonce is incompatible with [certain] payment authorizations
OpenID4VP request nonce is incompatible with [certain] payment authorization schemes
Feb 9, 2025
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 eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework#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.
The text was updated successfully, but these errors were encountered: