Learn

Communication protocol

One of the key features of Mobile Credentials is being able to perform offline in-person exchange. Our implementation of Mobile Credentials uses Bluetooth Low Emission (BLE) as the communication protocol between the holder and verifier devices as defined in ISO/IEC 18013-5:2021. The entire workflow can be completed end-to-end with no internet access for either the holder or the verifier.

In-person exchange comprises two phases:

  1. Engagement phase: The exchange begins with the two devices attempting to establish a secure communication channel for transferring data. In the context of Mobile Credentials, this is between the holder’s and the verifier’s devices.

  2. Data retrieval phase: Once a secure communication channel is available, data can be securely exchanged between the two devices. For Mobile Credentials, this would be exchanging various data objects required for the verification workflow.

Engagement phase

The engagement phase requires two mobile devices to:

  • Become aware of one another: Enabling the holder’s device to explicitly select a verifier’s device to engage with.

  • Establish a secure communication channel: As wireless technologies are essentially insecure, additional security layers are required to prevent third parties from eavesdropping transactions. The ISO/IEC 18013-5:2021 standard defines this layer, and it is quite similar to the usage of Transport Layer Security (TLS) for internet based protocols.

https://www.datocms-assets.com/38428/1694396838-engagement.png?auto=format

This phase is always initiated  by the holder, who generates a QR code to be read by the verifier. 

While it is true that any device can read this QR code, the assumption is that the holder will only show the QR code to a verifier they trust and wish to share information with.

The information in the QR code details:

  • Wireless communication protocols supported by the holder.

  • How the verifier is to connect with the holder.

  • Ephemeral session public key.

  • Additional feature negotiations.

Assuming the verifier device supports the same protocol requirements, it will generate its own ephemeral session public key, and attempt to establish a secure connection via a hand-shake response.

As the two devices connect, a unique session transcript is created. Any attempt to use the same transcript in a different session would fail, even if the session is between the same two devices.

The ephemeral key pairs are unique for every session, and removed when the session is terminated.

Note: The verifier response also includes an encrypted presentation request. However, for clarity purposes this step is described as part of the data retrieval phase.

When the verifier public key is successfully received by the holder, the engagement phase concludes and both parties are ready for data transmission.

Data retrieval phase

Once a secure connection is established, the following flow takes place:

https://www.datocms-assets.com/38428/1694397194-data.png?auto=format

  1. Request: The verifier sends a presentation request. This details what type of information they wish to verify. Note that the encrypted presentation request is actually sent alongside the verifier ephemeral public key during the last step of the engagement phase. However, for clarity purposes this step is described as part of the data retrieval phase.

  2. Consent: The holder receives the request and asks for the user’s consent to share the information. When applying selective disclosure, the holder device should show the user which of their Mobile Credentials include the required information, and enable the user to select which one to share.

  3. Respond: When the user agrees to share the information, a presentation is sent back to the verifier with all of the information the user has consented to share.

  4. Verify: The verifier will check the presentation, its signature and its issuer to complete the verification workflow with a verified/rejected conclusion.

Security considerations

The Mobile Credential communication protocol has a further control to assist with security attacks from Replay Attacks. Where a credential is presented to an incorrect verifier or it's presented multiple times.  Device and session binding prohibit this by ensuring  that a middle man hasn't poached the credential during transmission and that the credential is only fresh and valid for the intended transaction.

What’s next?

You should now have a good understanding of the key concepts and technologies that are used by Mobile Credentials, as well as how secure communication channels are established. In the next section we will understand how Mobile Credentials are constructed, and how that structure serves their functionalities.