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 sensitive information such as a PIN code or access token with your application, that you only want to be available on the device after a successful operation.

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-operation context is sent from our MobileID backend to the SDK before the user has completed the authentication. This means that you can use the pre-operation context to share information with your application that you want to be available on the device before the operation has been approved.

The SDK then passes the pre-operation 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.

Operation context shown to end-user

"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.

Operation context shown to end-user

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

Diagram showing example of pre-operation context in PSD2-compliant transaction

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 showing PSD2-compliant transaction

Post-operation context

The post-operation context is only sent from our MobileID backend to the SDK after an operation has been successfully completed. This means that you can use the post-operation context to share sensitive 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.

Operation context shown to end-user

"Your new Visa card PIN code is 349283."

Diagram showing example of post-operation context used to send new PIN code

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 showing post-operation context used to share an access token with app

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 for more details on how to do this.