Selective disclosure is one of the most widely promoted and valued features of mobile documents (mDocs). It promises to give users greater privacy, control, and transparency over their personal data. This aligns with rising user expectations and evolving regulatory frameworks around digital identity and data protection.
By enabling users to share only the information necessary for a given interaction, rather than their full credentials, selective disclosure represents a critical shift toward more respectful, purpose-bound data use in digital ecosystems.
But what exactly does selective disclosure mean today in ISO/IEC 18013-5 and the ISO/IEC TS 23220 series? And what enhancements are on the horizon? This overview clarifies how the standard currently works and previews upcoming changes that will unlock more flexible, privacy-preserving use cases.
What selective disclosure means today
At first glance, “selective disclosure” might evoke a familiar user experience pattern: the user sees all their credential claims and toggles on or off which ones to share. But that is not how the current standard works.
Instead, selective disclosure is currently defined as:
- The verifier (relying party) determines which subset of claims they need to complete a given interaction (for example, date of birth or license status)
- This subset is packaged into a verification request, which is sent to the holder
- The holder can see exactly what information is being requested, by whom, and for what purpose. They can then choose to accept or decline the request, but not modify it claim by claim
This model ensures clarity and protects the verifier’s process. Allowing users to arbitrarily choose which claims to disclose would often lead to incomplete responses, interaction failures, and poor user experiences. For example, if a government service or financial institution requires specific identity claims and the holder omits some, the transaction will fail.
Currently selective disclosure is primarily about data minimization and privacy by design, not custom tailoring. The power lies in the holder's ability to accept or decline predefined subsets, not curate them ad hoc.
What’s coming
The upcoming revision of ISO/IEC 18013-5 introduces important changes that aim to resolve gaps in the original specification and enable more advanced, flexible, and user-friendly interactions.
These changes address limitations that became apparent in real-world implementations, particularly around complex document requests, issuer constraints, and multi-document use cases. They also lay the groundwork for future capabilities like zero-knowledge proofs, helping ecosystems evolve toward even stronger privacy and compliance postures.
These limitations made it difficult to support diverse and dynamic real-world scenarios, particularly those that involve regulatory constraints, user consent logic, or multi-step digital workflows.
Key updates and what they unlock
The upcoming revision of ISO 18013-5 introduces two foundational structures (DocRequestInfo and DeviceRequestInfo) that significantly expand the expressiveness of how verifiers request information from holders. These additions are designed to resolve common pain points in real-world deployments while maintaining backward compatibility.
DocRequestInfo: Granular control over document-level requests
This is a document level structure that allows verifiers to specify constraints and request logic for a specific document, including:
DeviceRequestInfo: Higher-level request orchestration across document sets
This is a request level structure that allows verifiers to provide contextual logic for the full set of requested documents/credentials:
Example: how this improves the interaction
Imagine a user trying to open a bank account online, where the verifier must confirm both identity and residency using government-issued documents.
With DocRequestInfo, the verifier specifies that they need an address, but will accept one of several options:
- Full address (street, city, zip)
- Or alternatively: just state and postal code
The verifier also requires that the document be issued by a trusted government authority, using certificate-based issuer constraints.
At the same time, the verifier needs to satisfy two use cases:
- Identity verification, which requires both passport and national ID
- Residency verification, which prefers a utility bill which includes a proof of address, but can also accept a bank statement with the same proof if a utility bill is unavailable
With DeviceRequestInfo, these two use cases are grouped logically, with one marked as mandatory and the other as optional. The wallet can then clearly display:
"This verifier is requesting documents for:
• Identity verification (mandatory): passport + national ID
• Residency verification (optional): utility bill or bank statement"
The user sees the purpose of the request, understands which combinations of documents satisfy each use case, and can choose to respond, without trial and error or unnecessary data sharing.
This structured model enables verifiers to ask for what they actually need, while giving users clarity, choice, and control. It’s a major step forward from today’s all-or-nothing or one-size-fits-all request patterns.
What Happens Next
The revision of ISO/IEC 18013-5 has just entered the Committee Draft (CD) stage, marking a pivotal moment in the evolution of mDoc standards. This phase is now open for comments from ISO P-members and Working Group participants—making it an ideal time for implementers, regulators, and industry partners to engage with the process and influence what comes next.
At MATTR, we are playing an active role in the standardization effort, contributing to working groups and helping shape how capabilities like selective disclosure, multi-document orchestration, and zero-knowledge proof compatibility are defined. This gives us a front-row seat—not just to observe, but to inform and support the development of standards that reflect real-world needs and promote privacy, interoperability, and user trust.
Once the revision reaches FDIS, the technical content is considered stable and ready for product teams to build against confidently—only editorial changes are allowed beyond that point.
Why this matters for MATTR partners and customers
Because MATTR is contributing directly to the revision process, we’re able to:
Whether you're planning pilots, responding to regulatory changes, or building digital trust into your products, MATTR is uniquely positioned to help you stay ahead—with clarity, speed, and confidence.
This is a moment of opportunity, not just observation. By engaging now—through working groups, consultations, or collaboration—you can ensure the standard evolves to support your needs, and be ready to move when it lands.
