The two titles set up the split. "mDL Metadata Requirements to support Know Your Customer (KYC)" and "Customer Identification Program (CIP) compliance and OIDF Extended KYC Considerations" [3] are a schema and a compliance discussion. A schema tells a verifier how to parse what arrived and what each field means [4]. Papers with "Considerations" in the title rarely arrive with a governance model attached.
What happens on presentation is described in the source's own terms: the verifier does not inspect the document, it checks a signature chain back to a trusted issuer and reads standardized metadata about assurance level and status, replacing the human who used to look at a plastic card or scan a PDF417 barcode [8]. The load-bearing word there is trusted. The chain walk is cheap. Establishing that a particular certificate really belongs to a state DMV, and keeping that judgement current, is the expensive half, and nothing in the description of these papers says who publishes or attests that list [16].
That is the asymmetry between the two routes the post sets side by side. The European version of this model comes with eIDAS 2.0 and the EU Digital Identity Wallet; the US version arrives through a different standards body and a different regulatory path [9]. George Fletcher of the OpenID Foundation says the work is key to making deployments viable in the United States, "where no other trust framework exists" [5]. That sentence describes the hole the papers are aimed at. Describing the hole does not fill it.
The metadata is still worth standardising. The failure mode the Foundation names is fragmented implementations that increase operational risk and compliance audits and undermine assurance for account opening [6], and a parser per state is exactly that kind of cost.
Here is the part worth reading with a hand on the spec. The post states its own scope: Hypersign does not today natively ingest the ISO/IEC 18013-5 mdoc wire format an mDL wallet speaks, and does not implement the OpenID4VP or OpenID4VCI flows this initiative is built around [11]. It then characterises the remaining work as "extending a wire format, not replacing an architecture" [12]. The named gaps are one wire format and two presentation protocols [15]. Presentation protocols are where request authorisation, session binding and selective disclosure live. That is integration work with its own failure modes.
The same test applies to the coverage figure. 14,000+ document types across 189+ countries [13] counts templates for image-based document checks, including scanned driver's licenses. For that number to say anything about mDL acceptance, the mdoc and OpenID4VP path would have to exist and reuse the same pipeline, and the post says the path is not there [11]. The revocation design is the genuinely reusable piece: a credential checked against a signature and an on-chain revocation registry, with no synchronous callback to the original issuer [14]. Status you can check without calling the DMV is the property a relying party actually wants.
If the papers ship metadata fields and nothing else, a bank gets one parser instead of one per state [4] and keeps maintaining its own issuer list [16]. That is a real cut in integration work. The registry question stays exactly where it was.
