ISO 18013-5 feature support
A feature-by-feature reference for how the Verifier Mobile SDKs support ISO/IEC 18013-5 when verifying mDocs in person, covering device engagement, Bluetooth data retrieval, requests, issuer data authentication, mdoc authentication and certificate validation.
Overview
This page is a feature-by-feature reference for how the Verifier Mobile SDKs for iOS, Android and React Native support ISO/IEC 18013-5 when acting as an mdoc reader that verifies mDocs in person.
ISO/IEC 18013-5 defines how a reader and a wallet find each other (device engagement), how they exchange data (data retrieval), and how the reader checks that the data was issued by a trusted issuer and presented by the device it was issued to.
Remote verification, including the Verifier Web SDK, follows ISO/IEC 18013-7 and OID4VP instead. See OID4VP feature support (Verifier).
It complements the in-person verification overview, which explains how in-person verification works. Use this page when you need to know whether a specific clause is implemented in the Verifier SDK before you design a verifier application.
If you are building a wallet, see ISO 18013-5 feature support (Holder) instead.
How to read this page
Each feature is given one of the following support statuses:
- Supported: Implemented and available for use.
- Partial: Implemented with a specific limitation, described in the notes.
- Not supported: Not currently implemented. Some fields may be parsed for specification compliance without any behavior attached.
- Not applicable: Not relevant to the reader role.
The Spec column cites the relevant clause of ISO/IEC 18013-5 second edition, as published in its
Draft International Standard (DIS) form. This is a draft, so clause numbers can still change before
publication. The second edition also reorders the document, so its clause numbers differ from the
2021 edition. Clause numbers beginning with a letter refer to an annex, for example B.1.4.
Features introduced by the second edition, such as extended request information and zero-knowledge proofs, are labeled in the notes.
Support statuses reflect the latest versions of the iOS and Android SDKs. The React Native SDK wraps the native SDKs, so its support matches the platform it runs on. Where iOS and Android genuinely differ, the notes say so. If you need clarification on any feature, contact us.
Device engagement
| Feature | Spec | Status | Notes |
|---|---|---|---|
| QR code engagement | 9.3 | Supported | Your app scans the wallet's QR code and passes the mdoc: string to the SDK, which starts a BLE session. A helper checks the string before you start the session. |
DeviceEngagement parsing | 9.1 | Supported | Any engagement with major version 1 is accepted. The engagement must use cipher suite 1 and offer a BLE device retrieval method. |
OriginInfos and Capabilities | 9.1 | Not supported | Second edition members. They are accepted without error and ignored. |
| NFC engagement, static handover | 9.2 | Supported | Your app registers for NFC engagement and the SDK reads the wallet's handover select message. |
| NFC engagement, negotiated handover | 9.2 | Supported | The SDK's handover request offers BLE only, in both modes, so a wallet that offers only NFC or Wi-Fi Aware data retrieval cannot connect. |
ReaderEngagement in the handover request | 9.2 | Not supported | Second edition feature. |
| Session establishment during NFC handover | 9.2 | Not supported | Second edition feature. The first request is always sent over BLE after the handover. |
| Engagement time-out | 9.4 | Supported | A 300 second inactivity timeout applies, longer than the 30 second minimum the specification recommends. Android starts the timer when the session is created. iOS starts it once the BLE connection is established. |
Data retrieval
The Verifier SDKs retrieve data over Bluetooth Low Energy (BLE) using GATT.
| Feature | Spec | Status | Notes |
|---|---|---|---|
| BLE mdoc central client mode | 11.1.3 | Supported | Preferred on both platforms whenever the wallet offers it. |
| BLE mdoc peripheral server mode | 11.1.3 | Supported | Used when the wallet offers only this mode. The reader checks the wallet's Ident characteristic. |
| Connection state and closure | 11.1.3.3, 11.1.3.5 | Supported | Uses the End command on the state characteristic, and the connection is closed when the session ends. |
| BLE L2CAP | 11.1.4 | Not supported | |
| NFC data retrieval | 11.2 | Not supported | NFC is used only for engagement. Data always moves over BLE. |
| Wi-Fi Aware | 11.3 | Not supported | An engagement that offers only Wi-Fi Aware is rejected. |
| Server retrieval | n/a | Not supported | Defined by the 2021 edition and removed from the second edition. |
Requests
| Feature | Spec | Status | Notes |
|---|---|---|---|
DeviceRequest, DocRequest and ItemsRequest | 10.2.2, 10.2.3 | Supported | Request one or more document types, each with namespaces and data elements. You can send several requests within one session. The request version is always 1.0. |
intentToRetain | 10.2.2 | Supported | Set for each requested data element. |
requestInfo | 10.2.4 | Not supported | Second edition keys such as alternativeDataElements, issuerIdentifiers, uniqueDocSetRequired and maximumResponseSize cannot be sent. |
deviceRequestInfo | 10.2.5 | Not supported | Second edition feature. |
| Zero-knowledge proof request | 10.2.7 | Not supported | Second edition feature. |
| Document response encryption | 10.3.5, 12.6 | Not supported | Second edition feature. |
Reader authentication
| Feature | Spec | Status | Notes |
|---|---|---|---|
Signing requests with readerAuth | 10.2.6, 12.5 | Not supported | In-person requests are not signed, and there is no option to supply a reader certificate. Wallets that check reader authentication report the verifier as unauthenticated. |
readerAuthAll | 10.2.6 | Not supported | Second edition feature. |
| Reader authentication certificate | B.1.5 | Not applicable | The SDK does not present a reader certificate. |
| RICAL | Annex F | Not applicable | A RICAL is used to validate reader certificates, which the SDK does not present. |
Responses
| Feature | Spec | Status | Notes |
|---|---|---|---|
documents and documentErrors | 10.3.2, 10.3.3 | Supported | Each returned document comes back with its claims and its own verification result. A requested document the wallet did not return is reported as a credential error. |
Per-element errors | 10.3.3, 10.3.7 | Supported | A requested data element the wallet did not return is listed by namespace with its error code. |
| Response status codes | 10.3.6 | Supported | A non-zero status is treated as a failed response, and your app receives an error. The response version must be 1.x. |
| Zero-knowledge proof response | 10.3.4 | Not supported | Second edition feature. |
Session security
| Feature | Spec | Status | Notes |
|---|---|---|---|
| Session encryption | 12.2 | Supported | Each session uses a new ephemeral reader key on the wallet's curve, with HKDF and AES-256-GCM. The first request is sent in the session establishment message. |
| Session termination | 12.2.4 | Supported | Ending the session sends status 20 and closes the BLE connection. A status code sent by the wallet, including a response and termination in the same message, is handled and reported to your app. |
| Session transcript | 12.7.1 | Supported | Built from the device engagement, the reader's ephemeral key and the handover. The handover is null for QR code engagement and carries the NFC handover messages for NFC engagement. |
| Cipher suite curves | 12.7.2 | Partial | P-256, P-384 and P-521 only. X25519, X448, Ed25519, Ed448 and the brainpool curves are not supported. |
Issuer data authentication
The Verifier SDKs validate each document against the IACA certificates your app adds as trusted. See trusted issuers.
| Feature | Spec | Status | Notes |
|---|---|---|---|
| MSO signature, digests and document type | 12.3, 12.8.1 | Supported | The issuer signature is verified, every returned data element's digest is checked, and the document type must match the MSO. |
| MSO signature algorithms | 12.3.4, 12.7.2 | Partial | ECDSA only (ES256, ES384 and ES512). EdDSA is not supported. |
validityInfo checks | 12.8.1 | Supported | validFrom and validUntil are checked against the current time, allowing for clock skew. iOS also requires signed to fall within the document signer certificate's validity period. Android checks only that signed is not before the certificate's start date. |
| MSO revocation | 12.3.6 | Partial | Status lists are checked by default, including offline. Identifier lists are not supported. See Token Status List feature support (Verifier). |
mdoc authentication
| Feature | Spec | Status | Notes |
|---|---|---|---|
| mdoc MAC authentication | 12.4.5 | Supported | Verified using the session keys. |
| mdoc ECDSA authentication | 12.4.6 | Supported | keyAuthorizations in the MSO are enforced. |
| mdoc EdDSA authentication | 12.4.6 | Not supported | |
| mdoc authentication result | 12.8.2 | Supported | A failure is reported on the affected document as a device key failure. |
Certificate validation
| Feature | Spec | Status | Notes |
|---|---|---|---|
| Certificate path validation | 12.8 | Partial | The document signer certificate must be issued directly by a trusted IACA. Additional certificates in x5chain are ignored. The country, and the state when both certificates carry one, must match between the two certificates. |
| IACA checks when adding a trusted issuer | B.1.2 | Partial | An IACA must be self-signed, currently valid, valid for no more than 20 years, carry a common name and country, and use an ECDSA signature algorithm. Android also validates the country code and the key curve. keyUsage, basicConstraints, the issuer alternative name and CRL distribution points are not checked. |
| IACA link certificates | B.1.3 | Not supported | Chains are limited to IACA and document signer. |
| Document signer certificate checks | B.1.4 | Partial | Both platforms check the common name, the country and state against the IACA, and the signature algorithm. Android also matches the certificate's authority key identifier to the IACA's subject key identifier. For mDL document types, both platforms also require the mdlDS extended key usage, digitalSignature as the only key usage, a validity of no more than 457 days, and issuing_country and issuing_jurisdiction values that match the certificate. |
| CRL checking | B.2 | Not supported | CRLs are not fetched or evaluated for IACA or document signer certificates. |
| VICAL | Annex C | Not supported | The SDK does not read VICALs. Your app can retrieve and validate a VICAL itself, then add the IACAs it lists as trusted issuers. See how to consume a VICAL. |
Not currently supported
At a glance, the following features are not currently supported by the Verifier SDK for in-person verification:
OriginInfos,CapabilitiesandReaderEngagement(9.1, 9.2)- Session establishment during NFC handover (9.2)
- BLE L2CAP, NFC data retrieval and Wi-Fi Aware (11.1.4, 11.2, 11.3)
- Server retrieval
requestInfoanddeviceRequestInfo(10.2.4, 10.2.5)- Reader authentication, including
readerAuthAll(10.2.6, 12.5) - Zero-knowledge proofs (10.2.7, 10.3.4)
- Document response encryption (12.6)
- Cipher suite curves other than P-256, P-384 and P-521 (12.7.2)
- EdDSA MSO signatures and device keys (12.3.4, 12.4.6)
- Identifier list revocation (12.3.6.4)
- IACA link certificates (B.1.3)
- CRL checking (B.2)
- VICAL consumption in the SDK (Annex C)
Related
How would you rate this page?
Last updated on