Mock Service
The Mock Service, also known as the Smart-ID Relying Party API version 3 automated testing interface, is a component of the Smart-ID Demo environment. It simulates the behavior of a mobile device running the Smart-ID application, allowing RPs to test their Smart-ID integrations without the need for an actual phone or real user interaction. Instead of waiting for a user to interact with their device, the Mock Service automatically produces predefined outcomes such as a successful transaction, a cancelled transaction, or a timeout. When the RP sends a request to the Smart-ID Demo environment, the Mock Service steps in to act as the “user” and completes the request with the result that corresponds to the document number provided in the request. All the steps that the RP does, such as creating the request, polling the results, and validating the returned signature, are exactly the same as they would be with actual mobile devices. From the RP’s point of view, the flow behaves as though a real end-user had taken part in the transaction.
How to use
The Mock Service can be used in two main ways: through the notification flow and through the device link–based flow. In both cases, the RP follows the same sequence of actions as in Live environment, with the only difference being that the user’s mobile device is replaced by the Mock Service. The notification flow is the most straightforward, where the Smart-ID Core communicates directly with the mobile app. With device link–based flows introduced in RP API v3, the user is expected to interact with a device link that opens the Smart-ID app. Device links can appear in different forms: a QR code scanned by the user, a Web2App link clicked in a browser on the same device, or an App2App link opened from another mobile application. The Mock Service provides simulation for all of these cases, ensuring that RPs can test every supported scenario in the Demo environment.
Each document number corresponds to a specific result type. For instance, one document number may consistently provide a successful authentication, while another may always produce an error or a timeout. When a RP submits a request to the RP API using one of these document numbers, the Service retrieves the number, identifies the associated outcome, and responds accordingly.
Notification flow
In the Notification based flow, the Mock Service operates exactly like an actual mobile device. RP initiates a request, indicating one of the preconfigured document numbers, and the Service delivers the corresponding mapped result. Then, the RP polls for the transaction outcome and proceeds with validation as if the process had been executed on a real device.
The following diagram describes the simplified version of the notification based flow for the signature session in Live environment (authentication session is omitted to avoid duplication). The full version of the diagram can be found at the Notification based flow page.
The following diagram describes the notification based flow for the signature session via Mock Service.
Device link flow
The Device link flow requires one additional step compared to the notification flow. Unlike the notification flow, where Core communicates directly with the mobile application, the device link flow requires the RP to generate and handle a special type of URL known as a device link. This link is then delivered to the user, who normally interacts with it on their device, which in turn opens the Smart-ID app. To achieve this flow in the Demo environment, the Mock Service requires the RP to simulate the user interaction.
When the RP creates a device link request, it first receives three values from the RP API: sessionId, sessionToken, and sessionSecret. In the Live environment, these would be bound to the device link opened by the user. In the Demo environment, RP must send these values to the Mock Service through the device-link endpoint. This step simulates the user clicking or scanning the device link and guarantees that the Service can continue with the simulation of the outcome. After this link has been “used”, the Mock Service finalizes the transaction and generates the mapped result.
Same-Device Flows (Web2App and App2App)
In the Web2App and App2App flows, there is an additional step that occurs after the user has entered their PIN in Smart-ID app - the user is automatically re-directed to RP’s website or app.
To replicate this in the Demo environment, the Mock Service processes the signing or authentication request and performs a GET request to the Callback URL supplied by the RP. It includes the appropriate cookies and additional parameters, such as the userChallengeVerifier and sessionSecretDigest, which the RP would normally receive via the callback URL from the real application.
The following diagram describes the the simplified version of the device link based flow for the authentication session in Live environment. The full version of the diagram can be found at the Device link flow page.
The following diagram describes the device link based flow for the authentication session via Mock Service.
