Remote verification

Remote verification allows verifiers to check the validity of a credential without the need for a physical presence. This is particularly useful for scenarios where the verifier and holder are not in the same location, such as online transactions or remote identity verification processes.

Remote verification is available for the following credential formats:

• mDocs
• JSON credentials

mDocs

The ISO/IEC 18013-7:2025 specification establishes interoperable methods for remote presentation and verification of mDocs such as mobile driver’s licenses (mDLs) and other digital credentials.

Verification requests

The ISO/IEC 18013-7:2025 specification defines two key aspects of remote verification requests:

1. Wallet interaction: Defines how the request and response are transferred between the verifier and the user's wallet:

   • HTTP Redirects: Standard HTTP redirects are used to pass information between the verifier and the wallet, typically via a web browser.

   • Digital Credentials API (DC API): A browser-integrated API for digital credential interactions. The DC API allows web apps to communicate securely and seamlessly with wallet apps, improving user experience by eliminating multiple browser redirects.

2. Request type: Defines how the verifier requests the credential from the user's device and how should the device respond:

   • Device retrieval: Based on the ISO/IEC 18013-5:2021 standard and defined in ISO/IEC 18013-7 Annex A. The verifier directly requests a credential from the user's device, and the device retrieves and presents the necessary credential data in response.

   • OID4VP (OpenID for Verifiable Presentations): Based on the OID4VP protocol and defined in ISO/IEC 18013-7 Annex B. The verifier sends an authentication request, and the device responds with a verifiable presentation containing the requested data.

ISO/IEC 18013-7:2025 Annexes

ISO/IEC 18013-7:2025 defines specific annexes for each combination of wallet interaction and request type:

The next iteration of ISO/IEC 18013-7 is expected to define an additional Annex D:

Apple Verify with Wallet

In addition to the protocols defined in the ISO/IEC 18013-7 specification, Apple has introduced the proprietary Verify with Wallet API. This API can be used to streamline the verification process on iOS same-device flows by allowing direct communication between the verifier and the wallet apps.

Verification flows

The ISO/IEC 18013-7:2025 specification defines different flows for requesting and presenting mDocs based on the type of verifier application and the responding device:

• Verifier web applications: Typically use HTTP redirects or the Digital Credentials API to invoke the wallet from a desktop or mobile browser. Web applications support same-device and cross-device flows:

  • Same-device flow: You start the verification experience in a mobile browser and are redirected to a wallet app (where your mDoc is stored) installed on the same mobile device to respond to the request.

    For example, an online banking portal accessed from your mobile browser prompts you to open your wallet app on the same phone to present your mDoc for identity verification.

  • Cross-device flow: You start the verification experience in a desktop browser and use your mobile device (where your mDoc is stored in a wallet app) to respond to the verification request.

    For example, you visit a government tax website on your desktop computer, and scan a QR code with your mobile wallet app to present your mDoc.

• Verifier mobile applications: Can use platform capabilities or app-to-app communication to initiate and complete the verification. Similar to web applications, mobile applications support both same-device and cross-device flows:

  • Same-device flow: You start the experience on a mobile app, and are redirected to a wallet app installed on the same device to present the credential.

    For example, a tax filing mobile app redirects you to your wallet app on the same phone to verify your identity with your mDoc before filing your return.

  • Cross-device flow: You start the experience on a mobile app, but use a different mobile device to present the credential. This may happen if your credential is only available on another device you own.

    For example, you use your tablet to access a government service app, but the app enables you to scan a QR code using your phone where the required mDoc is available in a wallet app.

The exact protocols and flows used depend on the requesting application and the user's wallet. Different wallets and browsers support different combinations of these request types and transfer methods.

Verification channels

Verifier mobile applications

The following table details the different verification channels for mobile applications, including supported flows, supported wallets, underlying protocols and MATTR support status:

Verifier web applications

The following table details the different verification channels for web applications, including supported flows, supported wallets, underlying protocols and MATTR support status:

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.

JSON credentials

JSON credentials can be verified in one of two methods:

• Direct verification: Assumes you already have an out-of-band way of getting the credential from the holder, and you only need to verify it by making a request to a dedicated MATTR VII endpoint with the credential enclosed in the request body.
• Presentation verification: Use MATTR VII to create a presentation template, which details the information you wish to verify. Then, use this template to create a specific verification request from a specific holder. Presentation verification is only available for JSON credentials.

The following standard checks are performed on all JSON credentials verification requests, regardless of the verification method:

• 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.
• JSON-LD context is valid for credential claims.

The following checks are optional and are 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.