mdoc is a mobile document format that lets a device store credentials and present only the attributes a verifier requests. It uses device-based presentation and cryptographic proofs so the verifier can check issuer authenticity and detect tampering. Organisations should define acceptable device security, reader trust, and data minimisation rules before relying on mdoc claims.
How mdoc presentation works in practice
mdoc is designed around selective disclosure. The holder device keeps the credential locally and only reveals the data elements that the verifier asks for, rather than sending a full identity record. That means the protocol is less about “transferring a document” and more about proving that a specific set of claims exists and can be trusted.
The verifier does not simply accept a screenshot or a copied payload. It checks a cryptographic presentation that is bound to the device and the session, so the verifier can tell whether the response came from the expected credential and whether the data was altered in transit. In a mobile driving licence flow, that presentation model is part of the broader Mobile Driving Licence (mDL) Guide.
Issuer trust is built into the proof process. The verifier validates the issuer signature or related trust material, then checks that the presented attributes are consistent with what was originally issued. In other words, mdoc is built to answer two questions at once: “who issued this?” and “has this specific attribute set remained intact?”
What selective disclosure changes for verifiers and holders
Selective disclosure is the main privacy and operational difference between mdoc and a conventional credential exchange. A verifier can request only an age claim, a licence class, or another minimal attribute set, which reduces unnecessary data sharing and narrows what the relying party receives. That is why mdoc is often discussed alongside broader verifiable credential patterns, including the Verifiable Credentials Guide.
For the holder, the practical effect is that the device becomes the presentation point, not just a storage container. The wallet or app must protect access to the credential, mediate presentation, and keep the user aware of what is being released. If the device is compromised, the security of the whole interaction can degrade even when the underlying cryptography is sound.
For the verifier, the key design issue is trust calibration. A verifier should not treat “mobile” as automatically trustworthy, nor should it assume that any signed response is fit for every use case. The system works best when the verifier limits requests to the minimum needed for the transaction and uses a trust framework that defines which issuers, device conditions, and reader behaviors are acceptable.
Where mdoc depends on trust, device security, and protocol choices
mdoc relies on a chain of trust that spans the issuer, the holder device, and the verifier. If any one of those links is weak, the overall assurance drops. A compromised device can expose credentials or allow fraudulent presentation attempts; a weak verifier implementation can accept malformed or replayed presentations; and weak issuer governance can undermine confidence in the claims themselves.
The protocol also depends on correct reader behavior. Verifiers must authenticate themselves where required, request only the necessary data, and validate the response in the intended session. If a reader accepts more than it asked for, or cannot reliably bind the presentation to the live transaction, the privacy and anti-tampering benefits of mdoc are weakened.
This is why deployment rules matter as much as the cryptography. Organisations need policies for device security posture, reader trust, retention of presentation data, and exception handling before they rely on mdoc for access decisions or identity proofing.
Risk and Threat Considerations
mdoc reduces data exposure, but it also concentrates trust into the device, the presentation flow, and the verifier implementation. The main risks are over-disclosure, acceptance of weak or non-compliant readers, and abuse of a compromised device or wallet to present claims the user should not be able to rely on.
Failure mechanism: An attacker or fraudster can target the presentation path by stealing the device, abusing a compromised wallet, replaying a presentation into an unsafe verifier flow, or exploiting weak reader validation and trust decisions.
Impact: The result can be false acceptance, unnecessary disclosure of personal data, or a broken assurance chain where the verifier thinks it has validated a live, authentic credential when it has not.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and NIST SP 800-63 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | mdoc presentations depend on credential lifecycle and controlled presentation material |
| IA-2 — Identification and Authentication (Organizational Users) | Verifiers must authenticate parties and bind presentations to a live session | |
| AC-6 — Least Privilege | Selective disclosure is a least-privilege pattern for attribute release | |
| Recommendation — Manage issuance, rotation, and revocation of presentation credentials and related secrets. Require strong authentication before accepting mdoc-derived access decisions. Limit requested attributes to the minimum needed for the transaction. | ||
| NIST SP 800-63 | Digital Identity Guidelines | mdoc presentation and verifier assurance align with digital identity assurance and proofing concepts |
| Recommendation — Align assurance, binding, and verification steps to digital identity guidance. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | mdoc deployments require defined reader trust and access rules |
| Recommendation — Document and enforce who may request, receive, and use each credential attribute. | ||
Practitioner Guidance
What to verify: Define which device states are acceptable before production use, including unlock conditions, local protection of the credential, and whether a reader may proceed when the device is degraded or partially trusted. Also verify that the verifier checks issuer authenticity, session binding, and attribute minimisation every time.
Decision rule: If the transaction can be completed with fewer attributes, request fewer attributes. If the verifier cannot explain what it trusts, what it validates, and what it retains, the deployment is not mature enough for high-assurance use.
Practitioner takeaway: mdoc is strongest when organisations treat it as a controlled proof mechanism, not a generic digital identity channel. The assurance comes from tight device policy, strict verifier behavior, and minimal disclosure, not from the format alone.