Offline transaction signing verification

Organizations that use transaction signing for high-value payments or trades may need to retain independently verifiable evidence of each approval. For example, a financial institution can store the signing artifacts with its transaction record and use them to review a disputed transaction or support an audit.

Offline verification for transaction signing provides the artifacts required to verify that an approval corresponds to the transaction details presented to the customer. You can retain these artifacts in your own systems and verify them outside Mosaic.

For Passkeys and Mobile Biometrics in transaction-signing flows, include approval_data when you start the flow. This object contains the transaction details that the customer reviews and approves. After a successful transaction approval, the final authentication response returns signing artifacts.

For TOTP, the transaction start response returns approval_data and the transaction challenge. The final authenticate response returns authenticator_id, but does not return signing artifacts.

Use the following APIs to complete API-based transaction-signing flows:

• Passkeys: Authenticate WebAuthn API.
• Mobile Biometrics: call Create Mobile Biometrics Challenge, then Authenticate with Mobile Biometrics. See the Mobile Biometrics API reference.
• TOTP: call Start a Transaction Signing Flow with TOTP, then Authenticate Transaction Signing TOTP. See the TOTP API reference.

For journeys, add the transaction-signing step for Mobile Biometrics, Mobile PIN, Passkeys, or TOTP, and configure its output variable. After a successful transaction approval, the output variable contains the transaction-signing result.

For Web to Mobile, use the Web to Mobile Transaction Signing step and implement the required web and mobile Orchestration SDK calls as described in the transaction-signing sections of Login with Push or Login with Push using Web OTP. The web journey output includes signing artifacts from the mobile approval. You can view the output in Journey Analytics.

The following sections describe the verification data available for each authenticator.

The fields in signing_artifacts depend on the authenticator used to approve the transaction. Unless stated otherwise, the payloads below are returned both in the final API response and in the result stored in the configured journey output variable. In API responses, authenticator_id is a top-level field alongside signing_artifacts. In journeys, both are included in the transaction-signing step result.

For Passkeys, this is the payload returned by both the Authenticate WebAuthn API and by Transaction Signing with Passkeys step. It contains the WebAuthn data required to retain and verify the approval.

{
  "signing_artifacts": {
    "approval_data": "<APPROVAL_DATA>",
    "public_key": "<PUBLIC_KEY>",
    "signature": "<SIGNATURE>",
    "credential_id": "<CREDENTIAL_ID>",
    "webauthn_session_id": "<WEBAUTHN_SESSION_ID>",
    "authenticator_data": "<AUTHENTICATOR_DATA>",
    "client_data_json": "<CLIENT_DATA_JSON>",
    "raw_challenge": "<RAW_CHALLENGE>"
  }
}

authenticator_data contains data asserted by the passkey authenticator, including the relying party ID hash and whether the user was verified. client_data_json contains the browser context, including the request type, origin, and challenge.

To verify the signature, base64-decode authenticator_data, calculate the SHA-256 hash of the base64-decoded client_data_json, concatenate those two values, and verify the resulting data against signature using public_key. To confirm that the approval data is bound to the signature, use raw_challenge and approval_data to calculate the expected challenge, then compare it with the challenge in client_data_json.

The transaction-signing result includes an authenticator_id field, which identifies the passkey used for the approval:

• In API-based flows, it is a top-level field alongside signing_artifacts
• In journeys, it is included in the transaction-signing step result

For Mobile Biometrics, this payload is returned by the Authenticate with Mobile Biometrics API and by Transaction Signing with Mobile Biometrics. For Mobile PIN, it is returned by Transaction Signing with Mobile PIN. It contains the approved transaction data, challenge, signature, public key, and signing algorithm.

{
  "signing_artifacts": {
    "approval_data": "<APPROVAL_DATA>",
    "signature": "<SIGNATURE>",
    "public_key": "<PUBLIC_KEY>",
    "algorithm": {
      "name": "ecdsa",
      "namedCurve": "P-256",
      "hash": "sha-256"
    }
  }
}

algorithm specifies how to verify the signature. Depending on the algorithm, it includes either namedCurve for ECDSA or saltLength for RSA-PSS, as well as the hash algorithm. For example, an RSA-PSS algorithm is returned as { "name": "rsa-pss", "hash": "sha-256", "saltLength": 32 }.

The transaction-signing result includes an authenticator_id field, which identifies the Mobile Biometrics or Mobile PIN authenticator used for the approval:

• In API-based flows, it is a top-level field alongside signing_artifacts
• In journeys, it is included in the transaction-signing step result.

Transaction Signing with TOTP and the Authenticate Transaction Signing TOTP API do not return signing_artifacts and cannot be independently verified cryptographically offline.

The transaction-signing result includes an authenticator_id field, which identifies the TOTP authenticator used for the approval:

• In API-based flows, it is a top-level field in the final response
• In journeys, it is included in the transaction-signing step result

When you use Web to Mobile Transaction Signing, the web journey output includes the signing_artifacts generated on the mobile device. Its fields match the authenticator used to approve the transaction. The output also includes authenticator_id, separately from signing_artifacts, which identifies the authenticator used for the approval. If it was provided during authentication, device_id is returned separately alongside signing_artifacts.

Store the signing data with your own transaction record and the user identifier used by your application. The data required depends on the authenticator:

• For Passkeys, store approval_data, authenticator_data, client_data_json, raw_challenge, public_key, and signature.
• For Mobile Biometrics and Mobile PIN, store the complete signing_artifacts object.

For example, when reviewing a disputed payment:

1. Retrieve the stored transaction record and signing data.
2. Verify the signature using the relevant public key and verification data.
3. Confirm that the approval data matches the transaction record. For Passkeys, also confirm that the challenge in client_data_json corresponds to the stored approval_data and raw_challenge.

A valid signature and matching approval data provide evidence that the transaction was approved with the associated authenticator.