Mobile ID app development: certificate lifetimes disagree

Mobile ID app development comes with a number you can't take on trust: how long each certificate lives. InfoQ's October 2026 blueprint says Document Signer keys must rotate every 30 to 90 days. GOV.UK cites ISO/IEC 18013-5 for 457 days. AAMVA recommends 30 days, for a different object. Choose your rulebook before your SDK.

We have not built a mobile driver's licence (mDL) verifier or wallet at Creuto, so this is a reading of primary documents, not a field report. We compared InfoQ's architecture blueprint, AAMVA's v1.6 guidelines, GOV.UK's wallet documentation, NIST and ISO's own catalogue pages, as read on 20 October 2026. Where they disagree, or where we could not check, we say so.

Mobile ID app development starts with a rulebook, not an SDK

The base standard, ISO/IEC 18013-5:2021, is a 152-page document that costs CHF 227 on ISO's catalogue page, and that page marks it as due for revision with a draft next edition already listed. Its abstract puts two things out of scope: how the holder's consent to share data is obtained, and requirements on storage of mDL data and private keys.

That is the first thing a vendor comparison tends to skip. The consent screen and the key storage are the parts an app team actually ships, and the standard leaves both to someone else. AAMVA's v1.6 guidelines fill part of that gap for US and Canadian issuers: the mDL app must show what data was requested and whether the verifier intends to retain it, and the holder must control which elements are shared.

Online presentation sits in a second document. ISO/IEC TS 18013-7 adds presentation of a mobile driving licence to a reader over the internet. ISO's stage table shows edition 2 published on 29 May 2025, with the 2024 edition withdrawn.

What one vendor guide covers, and what it never mentions

Didit's developer deep dive (7 March 2026, updated 21 May 2026) lists five adoption hurdles: standard complexity, interoperability, compliance, user experience and fraud. It mentions certificate revocation lists once, in a single clause. We searched the page text for offline operation, Document Signer certificates, key rotation, trust lists and ISO/IEC 18013-7 and found none of them. Its answer is that a platform abstracts the cryptography away, which is a fair pitch, not a hidden flaw.

The InfoQ piece, written by Praveen Kumar Gopalakrishnan, argues that abstraction is acceptable for implementation but not for responsibility: "outsourcing implementation is not the same as outsourcing architectural responsibility." It gives six areas a provider should be able to explain:

• cryptographic architecture, including key generation and lifecycle;
• trust and PKI, including trust anchors and Document Signer certificates;
• privacy and data minimisation;
• offline operation, including cached trust material and stale information;
• interoperability with independently built wallets and verifiers;
• operational resilience when the provider is down.

It also warns that a demonstration over a fast internet connection does not demonstrate offline readiness. That is the test to put to any vendor table, ours included.

The certificate chain has no single lifetime table, so sources give different numbers

Source	What it limits	Figure it gives
InfoQ, 16 Oct 2026	Root Trust Anchor	10 to 20 years
InfoQ, 16 Oct 2026	Document Signer	30 to 90 days
GOV.UK Wallet docs	IACA root certificate	No more than 9 years, citing ISO/IEC 18013-5
GOV.UK Wallet docs	Document Signing Certificate	No longer than 457 days, citing ISO/IEC 18013-5
AAMVA v1.6	IACA root certificate	Maximum 20 years
AAMVA v1.6	Credential data (MSO) validity	Recommended not to exceed 30 days

Most of these do not contradict each other, because they limit different objects. AAMVA explains its own 20 years: the same root could also issue ISO/IEC 18013-3 licences, whose signing certificates can run up to 15 years, and it says 9 years is enough if the root only issues mDLs. GOV.UK's signing guidance gives the 9-year and 457-day ceilings and says to rotate signing keys "regularly", with no interval.

The 30-to-90-day Document Signer figure is the one we could not trace. InfoQ lists it among its governance policies without naming the body that sets it. We read the AAMVA v1.6 text for a rotation requirement and found none. A 30 to 90 day lifetime sits comfortably under a 457-day ceiling, so it is a legitimate design choice. We cannot show it is a rule.

The 30 days in AAMVA's guidance is the validity of the signed credential data, which an issuer sets so that outdated information expires on its own. Mixing that up with key rotation is easy, and the two figures need separate fields in your configuration.

MATTR's certificate guidance explains why rotation costs differ by layer. Signer certificates should be short-lived, and rotation overhead is low because the certificate travels inside each credential it signs. Replacing a root is expensive because the new one must be distributed to every verifier. So your verifier needs a plan for the root, not just for the signer.

One more mismatch matters for testing. InfoQ's table lists "ECDSA P-384 / RSA 4096" for the root, while the IACA root summary in AAMVA's appendix lists elliptic curve keys on P-256, P-384 or P-521 and, in the summary we read, no RSA. If US issuers are in your scope, test against AAMVA's curves.

Offline verification works, but only as fresh as what you cached

SpruceID's explainer says both NFC and QR presentation use device retrieval, with no internet connection needed, and that the verifier checks the signature against known public keys from the issuing authority. AAMVA states that ISO/IEC 18013-5 requires device retrieval support and that its own guidelines prohibit the server retrieval method, partly to prevent tracking.

The trust material itself still has to arrive somehow. AAMVA says the verifier must trust that a certificate truly comes from a valid issuer, that this does not need to happen at transaction time, and that in North America its Digital Trust Service, a minimally viable product, plays the aggregator role. InfoQ adds that offline terminals cache Document Signer certificates and revocation lists, and that a reader rejects a credential once the phone's secure clock passes the credential's validUntil.

NIST's June 2026 presentment post is blunt about the cost: verifiers refresh trusted issuer keys periodically or in batches, and "some latency remains where invalid credentials may remain active for a short period after they are revoked." It says the IETF Token Status List draft will be referenced in the next version of ISO/IEC 18013-5.

For an enterprise badge or check-in flow, that means your revocation delay is the cache refresh interval plus whatever validity the credential carries. Write that number down as a policy. Then test the cases InfoQ lists: stale revocation data, expired credentials, a wrong device clock and a provider outage.

ISO/IEC TS 18013-7 adds the online path, and parts of it are still moving

AAMVA's Appendix C lists what the second edition of 18013-7 contains: Annex A, a REST-style device retrieval to a website; Annex B, OpenID for Verifiable Presentations built on Draft 18, with a migration to OID4VP 1.0 under way and no timeline; and Annex C, retrieval through a digital credentials API such as the W3C Digital Credentials API. It also notes a protocol based on OID4VP 1.0 was being drafted as Annex D.

NIST describes the consequence for developers. Two online presentation protocols mean wallets and verifiers that want full coverage must implement and maintain both, and an OpenID Foundation working group was being chartered to harmonise them. It adds that implementations "often reflect different interpretations, feature sets, or draft-era assumptions."

On encryption, InfoQ states that Hybrid Public Key Encryption (HPKE) per RFC 9180 secures online exchanges, with DHKEM(P-256, HKDF-SHA256), HKDF-SHA256 and AES-128-GCM. RFC 9180 confirms those identifiers name that suite. What we cannot confirm is that 18013-7 mandates it: the specification is paywalled at CHF 181, and none of the free sources we read mention HPKE. Take that suite from the standard, not from a blog.

Logging every scan can be the tracking your own rulebook forbids

AAMVA's no-tracking section says any stakeholder, explicitly including service providers and mDL verifiers, "must not track mDL holders or the usage of any mDL except as required by law." It adds that tracking by a verifier becomes possible as soon as two transactions can be linked to each other. InfoQ lists a similar data minimisation mandate and ends on an open question: how to reconcile regulatory audit requirements with privacy laws that discourage keeping personal data.

The scope matters. AAMVA writes for driver's licences issued in the US and Canada, and an employee access log stands on a different legal footing. We have not worked out how either applies to a corporate deployment, and that is a question for counsel. The engineering consequence is still clear: an entry log that ties each scan to a named person is exactly the linkable record these documents warn about. Log the decision, the time and the terminal, and request only the elements the transaction needs. InfoQ's liquor-store example asks for an age_over_21 flag and a portrait and omits name, address and document number.

This is the wrong build if you only need an age check or a US-style tap

InfoQ's build, buy and govern model puts wallet SDKs, protocol implementations, the NFC stack and cryptographic libraries in "buy"; disclosure policy, authorisation rules, audit and orchestration in "build"; and key management, certificate infrastructure, revocation and telemetry in "govern". If your need is a single age check at a counter, buying and moving on is the right call.

Check what you are actually issuing, too. A company badge is not a driver's licence. MATTR describes ISO/IEC 23220 as the generalisation of the 18013-5 foundations to other mobile documents, which means the standard that governs your credential type may not be the one in this article.

Geography changes the answer as well. TSA's participating-states page, read on 20 October 2026, lists 22 issuers: 21 states and Puerto Rico, with more than 250 checkpoints. For the UAE we found no source stating that UAE Pass uses ISO/IEC 18013-5, so we won't assume it. Our separate post on UAE Pass integration explains why the approval is the hard part.

The slice we would take on is InfoQ's "build" slice: the app and the policy layer around a bought SDK, in React Native or Flutter, with a Node API behind it. InfoQ puts NFC session handling and secure storage APIs behind the SDK, and we would not claim to have written them. Our mobile app development team works in React Native, and the verification and audit side is API development and integration work.

Write down four decisions before your next vendor call

1. Which rulebook binds you: AAMVA's guidelines, GOV.UK's documentation, or your own jurisdiction's profile.
2. The lifetimes you will configure for the root, the signer and the credential data, kept as three separate settings.
3. The staleness you accept offline, as a number of hours or days.
4. What you log per scan, and who is allowed to read it.

Settle the first one before anything else, because it fixes the other three. Then ask each vendor to show their answer to it, offline, with the Wi-Fi off.