Every engineer who works on mobile credentials owes something to open source. The reference implementations, the test vectors, the conformance tools, the sample wallets: these taught the industry what an mdoc actually looks like on the wire, long before most of us had ever seen a real one presented at a counter. We learned from them too. If you are exploring digital identity for the first time, an open source verifier is the right place to start. Clone it, run it, present a test credential to it. That experience is worth more than any slide deck.
So this is not a post about open source being wrong. It is a post about what open source is for, and about the moment when the job changes.
The demo works. Now what?
Getting a first successful verification is a milestone, and open source will get you there. A QR code appears, a phone taps, attributes come back, the signature checks out. It feels done.
Production begins after that moment, and production is a different job with a different definition of done. Done no longer means "the happy path verified a credential." It means the ninety eighth percentile of real presentments, across real wallets, on real phones, at a real counter with a line forming behind the customer. It means the system still works next month, after two wallet updates and an OS release you did not plan for.
Across our deployments in the United States, Spain, and Australia, credentials are verified every day at more than 10,000 locations. What follows is the list of things that turned out to matter at that scale. None of them appear in a reference implementation, because none of them are the reference implementation's job.
Trust lists do not manage themselves
Cryptographic verification is only as good as the certificates you trust. Issuing authorities rotate certificates. New states and countries come online. Certificates expire, sometimes with notice, sometimes at two in the morning before a holiday weekend. A verifier that shipped with last year's trust list will politely and correctly reject perfectly genuine credentials, and the person standing at the counter will not care whose fault that is.
Somebody has to own that lifecycle: sourcing trust anchors, validating them, distributing updates to fleets of devices that may be offline by design. That is unglamorous operational work, it never ends, and it is invisible right up until the moment it fails.
Wallets change under your feet
Here is the uncomfortable truth about interoperability: it is not a property you achieve, it is a practice you maintain. Every major phone OS release can change how a wallet engages. Bluetooth behavior shifts. NFC handover details change. A wallet that presented one way in the spring presents differently in the fall.
A maintained product absorbs those changes for you. Someone retests the wallet matrix against every release, catches the regression before your customers do, and ships the fix as an update you barely notice. With a self-supported stack, that someone is you, on a schedule set by companies that do not know you exist.
Security response needs an owner
Verification code sits in a sensitive position. It parses attacker-supplied input, handles personal data, and gates real-world decisions. When a vulnerability is found in that path, the clock starts immediately.
Open source security response quality varies from excellent to nonexistent, and even the excellent projects owe you nothing on timing. A maintainer's weekend is not a service level. Production systems need a security process with an owner: someone whose job is to assess, patch, and notify, with a timeline they are accountable for.
When it fails at the door, who do you call?
Every verification system eventually produces a moment where a legitimate customer's credential does not verify and nobody on site knows why. What happens next is the real difference between a project and a product.
With a repository, the answer is a GitHub issue and hope. With a vendor, the answer is a support engineer who has seen this exact wallet on this exact phone before, because they support thousands of locations that hit the same edge cases before you did. Field experience compounds. Every odd presentment we debug at one deployment becomes a fix that every other deployment inherits.
Where the line actually sits
Our honest advice is the advice we would want ourselves:
Use open source to learn. Use it to prototype. Use it to hold your vendors accountable, because you will ask sharper questions once you have seen the protocol run.
Then be clear-eyed about the moment the job changes. It changes when a failed verification costs you a customer or a compliance finding. It changes when your deployment count means you can no longer walk over to the one kiosk that is acting up. It changes when the credentials you accept grow from one type to several, each with its own issuers, trust chains, and quirks.
At that point what you need is not more code. It is reliability you can measure, security response you can hold someone to, interoperability that someone else retests every month, and support that answers. That is the job we signed up for. The demo was the easy part, for us too.
