ISO 18013-5 feature support
A feature-by-feature reference for how the MATTR Pi Holder SDKs support ISO/IEC 18013-5 when presenting mDocs in person, covering device engagement, Bluetooth data retrieval, session encryption, reader authentication and mdoc authentication.
Overview
This page is a feature-by-feature reference for how the MATTR Pi Holder SDKs support ISO/IEC 18013-5 when acting as an mdoc that presents mDocs to a reader in person.
ISO/IEC 18013-5 defines how a wallet and a reader find each other (device engagement), how they exchange data (data retrieval), and the security mechanisms that protect the exchange. Remote presentation is defined by ISO/IEC 18013-7 instead, and is covered by OID4VP feature support.
It complements the proximity presentation overview, which explains how in-person presentation works. Use this page when you need to know whether a specific clause is implemented in the Holder SDK before you design a wallet integration.
If you are building an in-person verifier, see ISO 18013-5 feature support (Verifier) 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 wallet 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.5.
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 |
|---|---|---|---|
DeviceEngagement structure | 9.1 | Supported | Version 1.0, carrying the security information and a single BLE device retrieval method. |
| Cipher suite identifier | 9.1, 12.7.2 | Supported | Cipher suite 1. |
OriginInfos and Capabilities | 9.1 | Not supported | Second edition members. They are not advertised, so a reader treats the wallet as not supporting the capabilities they describe. |
| QR code engagement | 9.3 | Supported | The SDK returns the engagement as an mdoc: string for your app to display as a QR code. |
| NFC engagement, static handover | 9.2 | Supported | See the NFC device engagement guide. |
| NFC engagement, negotiated handover | 9.2 | Supported | The default NFC handover mode. If the reader offers both BLE modes, the SDK prefers mdoc central client mode. |
| Session establishment during NFC handover | 9.2 | Not supported | Second edition feature. The reader sends its first request over BLE after the handover completes. |
| Engagement time-out | 9.4 | Supported | A single 300 second inactivity timer covers the session from engagement to response, longer than the 30 second minimum the specification recommends. When it expires, the session ends with a time-out error. |
Data retrieval
The Holder SDKs retrieve data over Bluetooth Low Energy (BLE) using GATT. You choose the BLE mode when you create a proximity presentation session.
| Feature | Spec | Status | Notes |
|---|---|---|---|
| BLE mdoc central client mode | 11.1.3 | Supported | The default on both platforms. The wallet checks the reader's Ident characteristic. |
| BLE mdoc peripheral server mode | 11.1.3 | Supported | Selected through the BLE mode option. Recommended when presenting to point-of-sale terminals. With NFC engagement, the mode comes from the NFC configuration or from negotiation with the reader. |
| Connection state and closure | 11.1.3.3, 11.1.3.5 | Supported | Uses the End command on the state characteristic. |
| Connection re-establishment | 11.1.3.6 | Not supported | If the BLE connection drops, the session ends and the holder starts a new presentation. |
| 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 | |
| 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 | Requests with major version 1 are accepted. Each DocRequest is passed to your app with its document type, the requested data elements and the stored credentials that match the document type. |
intentToRetain | 10.2.2 | Supported | Passed to your app for each requested data element, so your consent screen can show it. |
requestInfo | 10.2.4 | Partial | Decoded but not passed to your app. None of the second edition keys, such as alternativeDataElements, issuerIdentifiers, uniqueDocSetRequired or maximumResponseSize, change how the request is handled. |
deviceRequestInfo | 10.2.5 | Not supported | Second edition feature. |
| Zero-knowledge proof request | 10.2.7 | Not supported | Second edition feature. |
Reader authentication
Reader authentication lets the wallet confirm who is asking before the holder shares data. The SDK verifies the reader and reports the outcome, and your app decides what to do with an untrusted reader. See verifier authentication.
| Feature | Spec | Status | Notes |
|---|---|---|---|
readerAuth on each DocRequest | 10.2.6, 12.5 | Supported | The SDK verifies the signature against the verifier root certificates your app adds as trusted. Each request is reported as trusted, untrusted or unsigned. The SDK does not reject an untrusted request. |
readerAuthAll | 10.2.6 | Not supported | Second edition feature. Only per-request readerAuth is verified. |
| Reader authentication certificate profile | B.1.5 | Partial | Android checks the full profile for every document type, including key usage, the mdlReaderAuth extended key usage and the 1187 day maximum validity. iOS checks validity, common name and signature algorithm for every document type, and adds the key usage, extended key usage and maximum validity checks only for mDL document types. Neither platform accepts the mdocReaderAuth extended key usage in place of mdlReaderAuth. |
| RICAL | Annex F | Not supported | Your app supplies trusted verifier root certificates directly. |
Responses
| Feature | Spec | Status | Notes |
|---|---|---|---|
Document with IssuerSigned and DeviceSigned | 10.3.2, 10.3.3 | Supported | Only the requested data elements the credential holds are disclosed. DeviceSigned carries no device-signed data elements. |
| Holder consent | 10.3.3 | Partial | The holder shares or declines each requested document by choosing one credential per document type. Your app cannot remove individual requested data elements from a shared document. |
| Response status codes | 10.3.6 | Supported | Uses 0, 10, 11 and 12. After sending an error status, Android also ends the session, while iOS keeps it open. |
documentErrors and per-element errors | 10.3.7 | Supported | A requested document that is not shared, and a requested data element the credential does not hold, are both reported with error code 0 (data not returned). |
| Zero-knowledge proof response | 10.3.4 | Not supported | Second edition feature. |
| Document response encryption | 10.3.5, 12.6 | Not supported | Second edition feature. |
Security mechanisms
| Feature | Spec | Status | Notes |
|---|---|---|---|
| Session encryption | 12.2 | Supported | ECDH key agreement, HKDF with SHA-256 to derive the session keys, and AES-256-GCM. |
| Session termination | 12.2.4 | Supported | Ending the session sends status 20. A status 20 received from the reader ends the session cleanly. |
| Ephemeral session key curves | 12.7.2 | Partial | The wallet always generates a P-256 ephemeral key. |
| 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. |
| mdoc ECDSA authentication | 12.4.6 | Supported | The default. Device keys are P-256 hardware-backed keys, and EdDSA is not used. See device key authentication. |
| mdoc MAC authentication | 12.4.5 | Supported | Selected through the device authentication option. On Android it requires Android 12 or later, and it is unavailable for credentials whose device key requires user authentication on every use. |
Not currently supported
At a glance, the following features are not currently supported by the Holder SDK for in-person presentation:
OriginInfosandCapabilitiesin device engagement (9.1)- Session establishment during NFC handover (9.2)
- BLE connection re-establishment (11.1.3.6)
- BLE L2CAP, NFC data retrieval and Wi-Fi Aware (11.1.4, 11.2, 11.3)
- Server retrieval
- Acting on
requestInfo, anddeviceRequestInfo(10.2.4, 10.2.5) readerAuthAll(10.2.6)- RICAL (Annex F)
- Zero-knowledge proofs (10.2.7, 10.3.4)
- Document response encryption (12.6)
- Ephemeral session key curves other than P-256 (12.7.2)
- EdDSA device keys (12.4.6)
Related
How would you rate this page?
Last updated on