There is a pattern that repeats every time an industry digitizes documents. Each new document type arrives with its own product: one SDK for driver's licenses, another for national IDs, a third for whatever comes next. Each has its own integration, its own version treadmill, its own line item. The verifier's architecture ends up mirroring the vendor's price list instead of the actual structure of the technology.
We took a different path, and this post explains the reasoning.
The per-credential trap
Imagine you run verification at a retail chain, an airline, or a government service counter. You integrated a mobile driver's license SDK two years ago. Now your customers start carrying national IDs on their phones, then EU wallet credentials, then a photo ID derived from a passport. In the per-credential model, each of those is a new integration project: new SDK, new certification cycle, new upgrade schedule, new budget line.
The cost is not only money. Every additional SDK is another dependency to patch, another vendor relationship to manage, and another way for two components to disagree about what a valid presentment looks like. Verifiers in that model are punished for the ecosystem's success. The more credential types their customers carry, the heavier their stack becomes.
The insight: these credentials are siblings
The reason we reject that model is not commercial preference. It is technical: the major mobile credentials are not separate technologies. They are siblings in one family.
A mobile driver's license under ISO 18013-5, a Photo ID under the ISO/IEC 23220 series, and the EU Digital Identity wallet's PID all share the same underlying construction, the mdoc. They use the same data model of namespaces and attributes, the same engagement patterns, the same session encryption, the same issuer signature scheme, and the same selective disclosure mechanism that lets a holder share an age threshold without sharing a birth date.
What differs between them is essentially the document type identifier, the namespace of attributes inside, and the trust anchors that sign them. That is configuration, not architecture. If you have built a real verification pipeline for one mdoc credential, you have built almost all of what you need for the whole family. We wrote about the Photo ID side of this family in our guide to digital identity credentials, at /understanding-digital-identity.
One pipeline in practice
That structure is why every ONEPROOF product runs a single verification pipeline. Engagement, session establishment, decryption, signature validation, trust chain evaluation, and selective disclosure are implemented once, tested once, and hardened once. A new credential type is a new profile flowing through proven machinery, not a new machine.
For verifiers, the consequence is simple: whichever sibling arrives, the pipeline verifies it through the same integration. A mobile driver's license today, a Photo ID tomorrow, an EUDI PID from a traveler next summer. No add-on modules, no per-credential SDKs, no second integration project.
There is a quality argument here too, not just a convenience one. Verification code is security code. Every additional parallel implementation of session crypto and signature validation is another surface to audit and another place for the implementations to drift apart. Concentrating that logic in one pipeline means every credential type benefits from every hardening pass, and a fix made for one is inherited by all.
Wallets are becoming multi-credential. Readers must too.
For the first years of this technology, a phone held at most one relevant credential, so a single-credential verifier could get by. That era is ending. Wallets now hold driver's licenses next to passport-derived photo IDs, and European wallets are being built from day one to carry a person's identity alongside other attestations.
That changes the requirement at the reader. When a customer taps their phone, they should not need to know which of their credentials your hardware happens to support, and your staff should not have to adjudicate it. The verifier's job is to accept whichever valid credential arrives and apply the same cryptographic bar to it.
The mdoc family made that possible by design. The standards bodies did the hard convergence work of making these credentials siblings. Building a separate product for each sibling would throw that gift away. One pipeline keeps it: every credential, every wallet, one integration, one bar for trust.
That is why we build it this way.
