In-person verification

In-person verification is a process where a credential holder presents their credential directly to a verifier in a proximity-based interaction. This may involve showing the credential to a person using a verifier device or to a self-service kiosk. Engagement methods include scanning a QR code, using a secure reader, or leveraging other proximity technologies.

In-person verification is available for the following credential formats:

• mDocs
• CWT credentials (including Semantic CWT)

mDocs

Overview

mDocs can be verified in-person using proximity based technologies such as Bluetooth Low Energy (BLE), and support offline verification, as defined in ISO/IEC 18013-5. Refer to the proximity verification overview for more information.

Verification flow

Proximity (in-person) verification comprises two phases:

1. 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.
2. 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.

Data retrieval phase

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

Verification checks

The following standard checks are performed on all mDocs verification requests:

• Issuer IACA is valid as per ISO/IEC 18013-5:2021.
• Credential was issued by a trusted issuer (by checking the issuer's IACA against a local or external list of trusted issuers).
• Digital signature is valid.
• Credential structure complies with ISO/IEC 18013-5:2021.

The following checks are optional and defined as part of the verification request:

• Current time is after the beginning of the credential validity period.
• Current time is not after the end of the credential validity period.
• Credential has not been revoked.

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.

CWT credentials

Overview

CWT and Semantic CWT credentials are verified via Direct verification. The holder physically presents the credential to a verifying device, which makes a direct API request to a MATTR VII endpoint with the credential enclosed in the request body. The endpoint then verifies the presented presented CWT or Semantic CWT credential and returns the verification result in the response.

Verification flow

CWT and Semantic CWT credentials can be provided for verification in one of two formats:

• Signed credential encoded as a string. This will be the encoded element of the credential issuance response.
• Signed credential encoded as a QR code and represented as a PDF document or an image file with the following limitations:
  • File size must be 1MB or under. Larger files are rejected with a 413 error.
  • Only the first page of PDF documents is processed.
  • Image files must contain a QR code of sufficient quality and resolution. This depends on many factors such as the size of the QR relative to the image, and whether the image was processed in any way.
  • For optimal performance, ensure that only a single QR code is present on the file.

Verification checks

The following standard checks are performed on all CWT or Semantic CWT credentials verification requests:

• Conformance of the string and encoded data.
• All string representations of CWT credentials must be prefixed with CSC/1.
• All string representations of Semantic CWT credentials must be prefixed with CSS/1.
• Decoded payload structure is a valid CWT or Semantic CWT credential.
• Issuer DID can be used to resolve its DID document.
• Public key from issuer's DID document validates the proof signature, confirming the credential has not been tampered with.

The following checks are optional and are defined as part of the verification request:

• Credential was issued by a trusted issuer.
• Current time is after the beginning of the credential validity period.
• Current time is not after the end of the credential validity period.
• Credential has not been revoked.