Mobile Documents (mDOC) (Draft 8/26/2026)
Mobile Document (mDOC) lets a DynaFlex II reader read a verified digital identity document — a mobile driver's license (mDL), a mobile passport, or a simple age check — directly from a cardholder's phone. Instead of scanning a plastic card, the reader engages the phone over NFC or a QR code, retrieves the requested data over an encrypted link, and cryptographically verifies that the data came from a trusted issuer before handing results to the host.
This guide explains how an mDOC transaction works end to end and points to the reference pages for each command, property, and file operation involved. It is the orientation layer; the byte-level detail lives in the reference pages linked throughout.
Applies to: DynaFlex II Go.
What mDOC does
mDOC supports credential-verification flows that need a real, issuer-signed government identity document rather than a self-reported value — for example age-restricted sales, identity checks at pickup or check-in, and onboarding. A transaction can return specific data elements (name, birth date, portrait, document number, and so on), or, when all you need is an age check, run a dedicated age-verification command.
Two standards families are supported:
ISO/IEC 18013-5 — the mobile driver's license (mDL) standard, together with the AAMVA data set used by U.S. jurisdictions.
ISO/IEC 23220-4 / mobile passport (mPassport) — a second namespace for other mobile ID document types, including mobile passports.
Which data elements are available depends on the namespace you select. The full catalog of request items per namespace lives in the request-item tag tables (see Reference below).
Supported wallets and phones
An mDOC credential lives in the cardholder's mobile wallet. The phone hardware and OS versions required to hold a mobile ID or passport are set by the wallet providers and change over time, so this guide links to their documentation rather than restating requirements that would quickly go stale:
Check the relevant provider page for current device, OS, and regional requirements.
How a transaction works
An mDOC transaction moves through four phases. The host starts it with Command 0x1201 – Read Mobile Document (or Command 0x1202 – Age Verification for age-only checks) and follows progress through notifications.
Device engagement. The cardholder presents their phone by tapping (NFC) or by letting the reader scan a QR code shown on the phone. The data exchanged during engagement seeds the ephemeral session keys used to encrypt and decrypt the rest of the exchange, per the key-generation algorithm defined in ISO/IEC 18013-5. The reader reports engagement status back to the host through Notification 0x0101 – Transaction Information Update. If engagement fails, the transaction ends here.
User consent. The reader connects to the phone over BLE and sends the session-encrypted "mdoc request" it built from the request items you specified in the command. The phone then displays a consent message showing the ID holder exactly which data elements the reader is asking for. No data leaves the phone until the holder taps Accept; if they decline, the transaction ends without returning data.
Data retrieval. Once the holder consent, the phone releases the "mdoc response." The response is CBOR-encoded and decoded by the reader.
Authentication and integrity. The reader validates the response locally on the reader itself against its pre-loaded issuer IACA certificates and verifies the SHA-256 hashes of every returned item to confirm the data has not been altered. On success, the results are delivered to the host through Notification 0x0101; on failure, a failure notification is sent instead.
If the operation finishes – whether it timed out or was cancelled – the reader sends Notification 0x0105 – Transaction Operation Complete.
Choosing a command
Use Command 0x1201 – Read Mobile Document for a full transaction where you specify exactly which data elements to request across the ISO 18013-5 / AAMVA / ISO 23220-4 namespaces.
Use Command 0x1202 – Age Verification when you only need to check age. It is a subset of 0x1201, supports the ISO 18013-5 namespace only, and requests just the age-over item — 18, 21, or 25. The response format is identical to 0x1201: the reader returns the requested data element, not a separate pass/fail flag (see Handling results and errors).
To cancel a transaction that is already running, send Command 0x1008 – Cancel Transaction.
Engagement methods
The host enables one or more ways for the phone to start engagement:
NFC — the cardholder taps the phone to the reader.
QR code — the reader reads a QR code presented on the phone.
At least one engagement method must be enabled for a transaction to start. Audio cues (start engagement, finish engagement, BLE transfer complete) can be left on automatic tones or driven explicitly by the host.
Security and trust
mDOC layers two independent protections:
Session security. The engagement exchange derives ephemeral keys that protect the request/response traffic between the reader and the phone (ISO/IEC 18013-5).
Issuer authentication and integrity. The reader hosts an internal Certificate Store of trusted IACA certificates — the issuer certificates supplied by the original credential issuers (states, Apple Wallet, Google Wallet, Samsung Wallet, and others). It validates the returned mDOC locally, on the reader itself, against those certificates and checks the SHA-256 hash of each item, so a response can be trusted to have come, unaltered, from a legitimate issuer without relying on any external service.
Separately, the data returned to the host can optionally be encrypted and MAC-protected (the 0xFD data container). mDOC uses the reader's existing DUKPT keys for this — the same keys shared with the device's other features — so no mDOC-specific key provisioning is required. The container is secured with either a TDES or an AES key, depending on the DUKPT key type in use. See the Security & Key Management guide for details.
Prerequisites
Before a reader can run an mDOC transaction, all of the following must be in place:
Firmware. {{CONFIRM: minimum MagTek Reader firmware/image version that supports the mDOC commands.}} Note that certificate-store file IDs differ between older and newer reader images (see the Certificate Store reference), so confirm the image before scripting file operations.
A valid mDOC subscription. mDOC is a licensed capability. The device must hold a subscription (1.2.9.1.1.1 - Mobile Document Subscription – OID) whose ValidFrom–ValidTo window includes the current date. Transactions are permitted only inside the subscription window. The subscription is provisioned with 0xD112 - Set Property (Secured), delivered inside 0xEEEE - Send Secured Command to Device. Setting both dates to zero disables the subscription. To obtain or renew a subscription, {{CONFIRM: how customers request, purchase, and receive a subscription — business process still under development.}}
A loaded certificate store. The reader needs the issuer trust anchors used to authenticate documents: a VICAL file (the Verified Issuer Certificate Authority List, provided by AAMVA, up to 30 certificates) plus individual IACA certificates supplied by the credentialed issuers--states/DMVs, Apple, Google, Samsung, and others (up to 15). See the Certificate Store reference for loading, fetching, and deleting these files.
A valid device RTC, so subscription and certificate validity windows can be evaluated.
At least one engagement method enabled (NFC and/or QR/BCR).
Subscription expiration warnings
Optionally, configure 1.2.9.1.1.2 - Mobile Document Expiration Notification – OID with a number of "warning days." When the subscription is within that many days of its ValidTo date, the reader emits a subscription-warning notification (on Notification 0x0101) reporting the configured warning-day threshold, the days remaining, and the ValidTo timestamp, letting your application prompt for renewal before transactions stop.
Requesting data elements
For a full read (0x1201), you choose which identity fields to request using the command's bit-mapped request items. The elements available for each namespace — for example family_name, birth_date, portrait, document_number, age_over_21 — are catalogued in the request-item tag tables:
ISO 18013-5 request items — tags start from 0xDFB001
AAMVA request items — tags start from 0xDFB041
Mobile passport (mPassport) request items — tags start from 0xDFB061
See Request Item Tag Tables in the Reference section for the complete lists.
Handling results and errors
On a successful read, the requested data elements are returned to the host. When output security is enabled, the data arrives as an encrypted string (the 0xFD data container) that the host decrypts; when it is disabled, the same data is returned in the clear. A requested portrait is returned as JPEG image data (encrypted along with the rest of the container when output security is on). The 0x1201 and 0x1202 responses share the same format.
Progress updates and successful results arrive on Notification 0x0101 - Transaction Information Update, carried under Payment Technology 0x40 (Mobile Document). The terminal state of the operation arrives on Notification 0x0105 - Transaction Operation Complete.
Common non-success conditions to handle — these behave like the equivalent events in a standard EMV transaction:
Session-data failure — the secure session with the phone could not be established or validated.
Timeout — the cardholder did not complete engagement within the configured timeout.
Host cancel — the host sent Command 0x1008.
User cancel — the cardholder declined consent or cancelled from the phone (display-only reason).
Subscription warning — the subscription is nearing expiration (see above).
Reference
The pages below hold the authoritative, byte-level detail for everything referenced in this guide. (Link targets in the site are wired to these destinations.)
Notification 0x0101 (PT 0x40, mDOC) - Transaction Information Update (Copy & paste this URL: https://app.gitbook.com/o/M1bZIjbUULXeTfuFxR7G/s/EX5FnWhqBiMGA8wVt4Kn/7-30-26-draft-version-scra-dynafamily-programmers-manual/7-30-26-draft-version-notifications/7-30-26-draft-version-0x0101-transaction-information-update#notification-detail-codes-mdoc)
This notification reports information about progress and state changes that occur during a transaction.
This notification reports the final result of a transaction the host initiated using Command 0x1001 - Start Transaction.
mDOC subscription — OID 1.2.9.1.1.1 and expiration notification OID 1.2.9.1.1.2
Device properties used to configure Mobile Document functionality.
Certificate Store — file operations 0xD811 / 0xD812 / 0xD821 / 0xD831; VICAL, individual certificates, Cert Store Table
How DynaFamily readers protect cardholder data and manage keys: encrypting data at the point of read, the keys and key-serial numbers behind DUKPT, verifying message integrity with MACs, loading keys with TR-31, and the PCI requirements deployers must meet.
DynaFamily readers with a contactless interface can exchange commands directly with NFC tags and MIFARE cards through pass-through commands and can present themselves as a card to another reader through NFC card emulation
Need More Help
Last updated