Transaction Approval with FIDO2

This article explains how to implement transaction approval with FIDO2 and highlights the conditions under which this makes sense.

Introduction

Airlock IAM extends FIDO2 authentication to support transaction approval. While FIDO2 does not provide this functionality natively, IAM can include transaction details in the FIDO challenge sent to the browser and eventually to the user's FIDO authenticator. The user’s FIDO authenticator signs the challenge and returns the signature to IAM. IAM then verifies the signature and ensures that the signed challenge resulted from the specific transaction data. This mechanism guarantees that the transaction was explicitly approved using the user’s registered FIDO authenticator.

Compared to other transaction approval methods, this approach comes with specific limitations and important security considerations (see below).

 
Info

W3C Secure Payment Confirmation standard

The W3C Secure Payment Confirmation standard aims to standardize payment confirmation using FIDO2 and WebAuthn. The IAM feature described in this article is not based on the W3C standard.

At the time the feature was introduced, the above W3C standard was still in draft form and not yet fully supported by browsers. Airlock IAM may implement the standard once it's final and well-supported by browsers. This may replace the feature described here in a future IAM release.

Security considerations

Although using FIDO keys for transaction approval provides a phishing-resistant connection to the relying party (e.g., the e-banking web server), several additional security aspects must be considered. The following list gives a detailed overview.

  • Security fully depends on the FIDO authenticators
    To achieve a high level of assurance in transaction approval, the involved FIDO authenticator must prevent the extraction or sharing of its private keys. This requirement is generally only met by device-bound authenticators.
    Unlike other transaction approval methods, FIDO allows end-users to choose their own authenticators, which can differ significantly in form (hardware versus software) and security properties.
    For strong assurance, it is essential that Airlock IAM can verify the type and quality of the authenticator in use. Currently, such verification is only possible through digitally signed attestations, effectively limiting strong assurance to FIDO hardware keys. Using non-verifiable authenticators (e.g., synced passkeys) has important security implications that must be carefully considered.
  • “Phishing protection” versus “no second channel”
    Using FIDO for transaction approval does not involve a second channel (as provided by Airlock 2FA, Cronto, or mTAN). Therefore, it does not protect against threats resulting from man-in-the-browser attacks, or malware in general. On the other hand, FIDO does prevent real-time phishing based on man-in-the-middle attacks and can provide hardware-bound strong crypto if used with verifiably secure hardware keys (see attestation).
  • Dynamic linking but no strict payer awareness (WYSIWYS)
    FIDO transaction approval provides dynamic linking, meaning the transaction details are bound to the signature. In other words, any change to the signed transaction details results in a different signature.
    However, it is not possible to present the signed transaction details to the end-user within the FIDO protocols. Instead, the transaction details to be signed are shown to the end-user outside of the FIDO protocol. Therefore, there is no guarantee that the end-user actually signs what they see. Thus, the feature cannot strictly ensure “what you see is what you sign” (WYSIWYS) or “payer awareness”.

Prerequisites and limitations

Keep the following prerequisites and limitations in mind when using the feature:

  • IAM license
    A license including FIDO and transaction approval is required.
  • Only available in Transaction Approval module
    The feature is only available in IAM's Transaction Approval module. FIDO approval steps are also available for self-services, but they only provide “re-authentication” and do not include transaction data in the signatures.
  • REST API, no UI
    Like all other transaction approval methods, Airlock IAM provides only a REST API, not a UI. It is up to the REST client (e.g., an e-banking application) to interact with the end-user's browser. In this case, this involves JavaScript to interact with the browser's WebAuthn interface and get FIDO challenges signed by the end-user.
  • Common domain / relying party ID
    To provide phishing protection, the FIDO protocol ensures that an authenticator can only be used in the domain it was registered for. FIDO authenticators are registered in Airlock IAM but used for transaction approval with the application presenting the transaction approval (e.g., e-banking web application). Thus, the two applications (IAM Loginapp and e-banking) must use the same domain. Different subdomains are possible if the relying party ID has been chosen accordingly before any authenticators have been registered. Refer to the plugin documentation of the property Relying Party ID in the FIDO Settings plugin for details.
  • Limit to verifiably secure authenticators
    As mentioned in the “Security considerations” section above, it is strongly recommended that you configure Airlock IAM to use only verifiably secure FIDO authenticators.

Configuration

Transaction approval with FIDO is configured the same way as other types of transaction approval. It involves a user identification step, a parameter step, and the FIDO approval step. See Transaction approval REST API for a general description of transaction approval flows.

To configure the FIDO transaction approval step, proceed as follows:

  1. In the transaction approval flow, create and add the FIDO Transaction Approval Step plugin.
  2. If the selection of the FIDO transaction approval step is based on the AuthTokenID, use the condition plugin FIDO was used for login (Transaction Approval only). For this, go to the Tags/Guards section, Pre Condition field in the FIDO Transaction Approval Step.
  3. The FIDO Settings plugin referenced in the FIDO Transaction Approval Step includes all security-relevant settings. As mentioned in the “Security considerations” section above, we strongly recommend limiting the set of registrable FIDO authenticators to verifiably secure hardware keys by verifying signed attestations. See FIDO Settings >> Attestation Verifier. Note that this has to be done before FIDO keys are registered.
  4. If FIDO signatures on transaction details must be verifiable in retrospect based on log data, the property Verification Logging must be enabled in the FIDO Transaction Approval Step configuration (Advanced Settings).

Verifying signatures based on logs

If Verification Logging is enabled in the FIDO Transaction Approval Step, Airlock IAM writes sufficient information to the log file to allow signature verification.

If enabled, the following information is written to the log file as a JSON object:

  • S: The signature value.
  • T: The transaction details that were taken into account in the signature.
  • CAD: A random value added by the FIDO authenticator during signing.
  • CCD: The challenge object for the FIDO authenticator.
  • N: The nonce (random value) used in the challenge.
  • P: The FIDO authenticator's public key.
 
Example
{
    "S": "MEUCIA-h1SXusQwdhlrya9wluvZy-yIaFEviN9BmMNlrR2COAiEAkMmfoOhzTMS_Fjj6KKCGgNYkwvXbTa9Y9u4R-U-R2VU",
    "T": "{\"type\":\"payment\",\"amount\":\"300000000\",\"currency\":\"CHF\"}",
    "CAD": "SZYN5YgOjGh0NBcPZHZgW4_krrmihjLHmVzzuoMdl2MFAAAAAg",
    "CCD": "{\"type\":\"webauthn.get\",\"challenge\":\"mmdHgeMzJBIEkiQrZbg_ntEPUYvQilNeCG4qQyjEuhrMKiGsRQ8UhDOVtLVLrqcipijZXWDXtcbkE_rbek3hzA\",\"origin\":\"https://localhost\"}",
    "N": "PsJaxWAfuBcDYB4ZA79viZ17AuWMLP0iO2yMkW9-bgE",
    "P": "pQECAyYgASFYIDiiceH54t9pRqOX03nq96wJpQty5GRsv3rhwIHSrDjsIlggQGT8iVfqTmzYXbicDBMmPMZyFLqPyKP9Ul65P-h4lyU"
}
 
Notice

Note that transaction information is written to the log file. This may affect how log files are handled or protected.

Refer to the plugin documentation of the FIDO Transaction Approval Step for further information on signature verification.

The Python script verify_dynamic_linking.py shows how signatures can be verified in detail. It may serve as a basis for your own verification code. The script has been tested with Airlock IAM 8.5 using Python libraries available at the time this documentation was written (Q3 2025). It only serves as an illustration. There is no guarantee that the script will work with future Python or IAM versions.

 
Notice

Evidence drawn from signature verification based on log data depends greatly on the authenticity of the public key used for verification. To convince a third party that a specific end-user's authenticator was involved in generating a transaction signature, it must be apparent that the public key used is linked to that user.
One way to achieve this is to use data stored in the IAM database (FIDO public key linked to a user account). This may require using backups of the database since the end-user may have removed the FIDO authenticator from their account after signing the transaction.