# Operation context

# About operation context

MobileID supports a 'pre-operation context' and a 'post-operation context' for each operation. This feature allows you to send important information to your app, through a secure channel with end-to-end encryption (E2EE).

This information can be passed:

  • Before the operation has been approved (pre-operation context).
  • After the operation has been successfully completed (post-operation context).

# Example use cases

  • Ask the end-user for approval of an operation (such as when the operation is initiated in a different channel to your application).
  • Conduct PSD2 RTS-compliant payment transactions.
  • Share secret information with your application that you only want to be available on the device after a successful operation (such as a PIN code or access token).

# How does operation context work?

The operation context contains a content (content), which is a binary blob. The content has a MIME type (mimeType), so your app can determine how to process the content.

The operation context is specified when you're initiating a device operation. The context is passed from our MobileID backend to our SDK, and then to your application through our secure channel using E2EE.

# Types of operation context

We support two types of operation context:

Object name Description
preOperationContext Context sent to the app, across our secure channel using E2EE, before the operation is approved.
postOperationContext Context sent to the app, across our secure channel using E2EE, only after a successful operation.

# Encrypted channel

In addition to the Transport Level Security (TLS) that our MobileID backend and SDK utilises for all communication, we also leverage an additional E2EE layer inside the TLS channel to further protect the information in your operation context.

We achieve this by including a crypto library within the SDK, and using this to establish an E2EE channel between our MobileID backend and SDK.

This protects against:

  • Instances when malware on the device is manipulating the platform crypto libraries.
  • Man-in-the-middle (MITM) cyberattacks on the device.

# Pre-operation context

The pre-context is sent from our MobileID backend to the SDK before the user has completed the authentication. The pre-operation context can therefore be used to share information with your application that you want to be available on the device before the operation has been approved.

The SDK passes the pre-context back to the application, and then it is up to the application to either display the information in an appropriate way, or use the data without sharing it with the end-user.


Example 1: Use case for pre-operation context


You can use the pre-operation context to ask the end-user for approval of an operation, when it is initiated in a different channel to your application.

"Do you want to log in to www.example.com in Safari, on Jane's MacBook Pro?"


Example 2: Use case for pre-operation context


You can use the pre-operation context to execute a PSD2 payment transaction.

To do this, you must pass the transaction amount and the recipient details as part of the pre-operation context. This is required for PSD2 Dynamic Linking.

"Do you want to transfer $300 to Jane Smith?"

Example 2: Use case for pre-operation context click-to-zoom

# About PSD2 Dynamic Linking

Our product is PSD2 RTS-compliant and can be used for payment transactions.

For payment transactions, you need to pass the transaction amount and the recipient details as part of the pre-operation context.

The Dynamic Linking requirement of the PSD2 RTS is supported in our strong customer authentication (SCA). This is done by cryptographically binding a unique authentication code generated by our server, to the pre-operation context shared by you to the transaction.

This provides non-repudiation for the transaction. If somebody manipulates the pre-operation context, then the operation will fail.


Sequence diagram: Pre-operation context


Sequence diagram illustrating pre-operation context being used for a PSD2-compliant transaction.

Sequence diagram: pre-operation context being used for a PSD2-compliant transaction click-to-zoom

# Post-operation context

The post-operation context is only sent from our MobileID backend to the SDK after an operation has been successfully completed. The post-operation context can therefore be used to share secret information with your application that you want to be available on the device after a successful operation.

After an operation has been successfully approved, we pass the post-operation context back to the application. It is then up to the application to either display the information in an appropriate way, or use the data without sharing it with the end-user.


Example 1: Use case for post-operation context


You can use the post-operation context to send a new PIN code to the end-user.

"Your new Visa card PIN code is 349283"

Example 1: Use case for post-operation context click-to-zoom


Example 2: Use case for post-operation context


You can use the post-operation context to share information or data that is required for the application to communicate with your backend, such as an access token.


Sequence diagram: Post-operation context


Sequence diagram illustrating post-operation context being used to share an access token with the app.

Sequence diagram: post-operation context being used to share an access token with the app click-to-zoom

# Configuration options

You can configure operation context for any of the device operations.

Note

For registration operations, only post-operation context is supported.

# Operation context object

The preOperationContext and postOperationContext objects are made up of 3 fields:

Field name Description
title The title of the context.
content The content of the context.

Note: MobileID handles this as a binary blob.
mimeType The MIME type of the content.

Note: Must be a valid MIME type.

The content of the operation context object can be any MIME type that your application is able to process. For example, you could:

  • Pass a string in the content that you want to show to the user in the app, using text/plain as the MIME type.

  • Pass a PDF document in the content that you want to show to the user in the app, using application/pdf as the MIME type.

  • Pass JSON formatted strings that the app parses and uses for application control or user navigation, using application/json as the MIME type.

You need to provide the operation context when you initiate an operation. See our MobileID API reference documentation (opens new window) for more details on how to do this.

Last updated: 11/04/2024 07:47 UTC