30.04.2024
Midships’ Approach To Digital Transaction Signing

Yuxiang Lin . 6 Minutes Read
Executive Summary
In this paper, we presents Midships' solution for digital transaction signing that enhances the security and integrity of digital banking services. The solution is built on Passwordless and FIDO principles, utilising device-level PKI to facilitate transaction signing. The private key is securely stored in the user's device, while the public key is registered with the backend. This method ensures zero knowledge of the user's signing credential on the backend system, shifting the burden of proof to the customer in the event of repudiation. Through digital signatures and JWTs injected with the transaction details, this solution provides clear and indisputable evidence of a transaction's authenticity.
Midships can provide expertise and capabilities to financial service organisations, integrating this cutting-edge solution into their existing infrastructures.
Background & Purpose
For financial institutions, it is imperative to maintain the integrity and security of their digital banking services. One essential aspect is to incorporate digital transaction signing to ensure the bank’s ability to demonstrate that a transaction could only have been authorised by the customer. This ability is crucial for managing liability and customer repudiation. The process of transaction signing can provide a secure and reliable method of verifying and authenticating digital transactions. By utilising digital signatures, we can unequivocally link a transaction to a specific individual, thereby providing clear and indisputable evidence of a transaction's authenticity. The presence of transaction signing will not only enhance the security of the digitalised services but also allow the bank to effectively counter repudiation claims. In order for these desired outcomes to be realised, the digital transaction signing solution must address a few key considerations, notably:
- Zero Knowledge : The concept of zero knowledge has been widely adopted in user password implementations to ensure that the exposure of users’ stored credentials in the backend does not amount to a password compromised situation. The same concept is equally applicable for a transaction signing solution where the the backend system should have zero knowledge of the user’s credential that is to be used to sign a transaction, thereby is able to effectively shift the burden of proof from the bank to the customer in the event of repudiation.
- Transaction Binding : Transaction signing is more than step-up authentication enforced by transactional authorisation. A key outcome through the process of transaction signing is to bind the attributes of a transaction to an identity such that the authenticity established illustrates clearly the transaction that has been authorised. This is different from a pure step-up authentication where we just want to authenticate the user on a transactional basis in order to provide an extra layer of security.
This paper outlines Midships' digital transaction signing solution that addresses the above considerations and expectations. We provide a straightforward and effective solution framework on transaction signing that can be implemented on any tech stack. We also offer a readily implementable Ping Identity (ForgeRock) native solution. Our approach, which has been successfully implemented with a digital bank in Indonesia, provided a frictionless and secure transaction signing experience on the mobile banking application.
Midships' Solution
Midships’ digital transaction signing solution is built on Passwordless and FIDO principles. Through the establishment of a device level PKI, similar to FIDO2 passkeys, customers can carry out transaction signing using their devices. As the device holds the private key and the backend is registered with the public key, the device will be able to sign a transaction where the digital signature can be verified by the backend. For end-to-end integration, our solution make use of the OAuth 2.0 protocol where JWTs (JSON Web Tokens) containing the transaction attributes are used as the proof of transaction signing completion. Our approach allows the realisation of the below desired outcomes:
- Shift Of Proof : As the private key on the customer device was never held by the bank (zero knowledge), the bank no longer shares the burden of proof on whether or not the private key was compromised. Via reasonable T&Cs terms to indicate that the customers are responsible for their device access, our solution will allow the bank to achieve non-repudiation by demonstrating that the transaction could only have been signed by the customer.
- Enhanced Security : As the mobile device itself serves as the basis of authentication, the solution provides additional security through a Passwordless approach. The customer experience to carry out transaction signing will also be seamless as only OS level authorisation gestures are involved to unlock the private key for signing . Moreover, since there is no OTP sent to the customer, there are no opportunities exposed for malicious actors to trick customers into sharing any credentials.
- Enhanced Security : As the mobile device itself serves as the basis of authentication, the solution provides additional security through a Passwordless approach. The customer experience to carry out transaction signing will also be seamless as only OS level authorisation gestures are involved to unlock the private key for signing . Moreover, since there is no OTP sent to the customer, there are no opportunities exposed for malicious actors to trick customers into sharing any credentials.
- Clear Evidence : In the solution, we make use of JWT that is injected with the transaction attributes that has been signed and verified to act as an immutable evidence that the user has authorised the transaction. A transaction will be submitted with its corresponding JWT such that the backend service that is handling the transaction can rely on the details contained in the JWT to ensure only the authorised transaction is executed.
- Clean Integration : This solution has a clear separation of concerns. The entire transaction signing process is managed by the bank's Customer Identity & Access Management (CIAM) system. End-to-end integration is straightforward via the use of JWT for validation. Our integration approach can address stateless and immutable requirements for different type of enterprise architecture.
This paper outlines Midships' digital transaction signing solution that addresses the above considerations and expectations. We provide a straightforward and effective solution framework on transaction signing that can be implemented on any tech stack. We also offer a readily implementable Ping Identity (ForgeRock) native solution. Our approach, which has been successfully implemented with a digital bank in Indonesia, provided a frictionless and secure transaction signing experience on the mobile banking application.
How it works

Registration & Enrolment
To allow transaction signing ability on the user’s device, an authenticated user will need to first enrol the device with the CIAM system via registration of the device’s meta data (with unique deviceID) and a public key. The private/public key pair needs to be generated by the device such that the private key will be stored in the device’s secure enclave, ensuring zero exposure of the private key outside of the device. The banking app can configure private key access policy to necessitate local authentication using OS-level authenticator options, such as face ID or device pin to further protect the private key.

Digital Transaction Signing On Registered Device
The transaction signing process on registered device involves the banking app to first initiate transaction signing with the CIAM system by informing the CIAM system on the transaction details such as the amount and the beneficiary that the user want to carryout. The CIAM system will then facilitate the app to sign those transaction details. To carryout the signing, the app will ask for the user to carryout an authorisation gesture that can be in the form of a faceID/device pin validation which will unlock the private key. The generated digital signature can then be submitted to the CIAM system for verification using the registered public key against the transaction details. Upon successful digital signature verification, the CIAM system will coordinate with the banking app to issue an short lived transaction token (JWT) that is injected with the transaction details. Once the banking app receives the transaction token, it can submit the transaction request with the transaction token as the authorisation header. The API gateway that is protecting the payment service can locally validate the transaction token to control the access. The payment service can rely on the details contained in the transaction token to ensure the transaction request has not been tampered and only authorised transaction is executed.

Digital Transaction Signing using Registered Device
In our solution, a registered device can also be used for transaction signing when the transaction is initiated on a separate application. For example, the user can be initiating a transaction via the internet banking channel on the browser. The internet banking channel will first initiate transaction signing with the CIAM system by informing the CIAM system on the transaction details that the user want to carryout. The CIAM system will then send push notification to the user’s registered device and facilitate the transaction signing. While the user access his/her registered device to sign the transaction, the internet banking channel will poll against the CIAM system for the result. Once the user has completed the transaction signing process, the CIAM system will coordinate with the internet banking channel to issue the transaction token. Once the banking app receives the transaction token, it can submit the transaction request with the transaction token as the authorisation header.
Other Considerations/Decisions
Non-Replayability
As the transaction token (JWT) can be configured to have an extremely short expiry, the time window for replay is minimised. However this approach does not guarantee non-replayability. To achieve non-replayability of the transaction token, there are 2 approaches in our solution. First is to validate the transaction token against the CIAM system which will also blacklist the transaction token for one time use. CIAM systems that support OAuth 2.0 flows typically also provide token revocation capabilities. Second is for the API gateway to utilise a cache service such as Redis to blacklist the transaction token’s JWT ID (JTI) with the time to live equal to the token’s expiry. This approach will allow the transaction token validation to be carried locally on the API gateway and at the same time guarantee non-replayability.
Extend with transaction Pin
In the above solution, we included only local OS-level authenticator options as part of the transaction signing process. We can also easily include other forms of authentication options such as a transaction pin. Integration of other authentication options in our solution will only require the CIAM service to facilitate the authentication process prior to the unlock of the private key.
Offline support
As a registered device can sign transactions and generate transaction signatures without an internet connection, our solution will allow organisations to utilise the transaction signing ability to handle cases where the customer has limited access to internet connectivity. This will allow more flexibility in the way organisations design their customer journeys.
Are you interested?
If you would like to learn more, please contact ajit@midships.io