mDocs proximity (in-person) verification
Proximity (in-person) verification comprises two phases:
- Engagement phase: The interaction begins with the two devices attempting to establish a secure communication channel for transferring data. In the context of mDocs, this is between the holder’s and the verifier’s devices.
- Data retrieval phase: Once a secure communication channel is established, data can be securely requested and exchanged between the two devices. For mDocs, 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 share engagement information with a verifier’s device they wish to interact 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.
Holder generates a QR code
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 can connect with the holder.
- Ephemeral session public key.
- Additional feature negotiations.
Verifier returns session key
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.
The verifier response also includes an encrypted presentation request. However, for clarity purposes this step is described as part of the data retrieval phase.
Secure communication established
As the two devices connect, a unique session transcript is created and used alongside the holder and verifier keys to derive a unique session key that is used to encrypt any exchanged data.
This session key is unique for every session and removed when the session is terminated. Any attempt to use the same session key in a different session would fail, even if the session is between the same two devices.
The holder will use the session key to decrypt the message (e.g. request from the verifier) and encrypt the responses (e.g. shared mDocs).
Data retrieval phase
Once a secure connection is established, the following flow takes place:
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.
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 mDocs include the required information, and enable the user to select which one to share.
Response
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.
Verification
The verifier will check the presentation, its signature and its issuer to complete the verification workflow with a verified/rejected conclusion.
Security considerations
The mDocs communication protocol has a further control to mitigate replay attacks, where a credential is presented to an incorrect verifier or 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.