Privacy in credential verification

Verification is the moment when a presented credential is checked against a set of trust rules. This page describes how MATTR's verification capabilities handle the presented data, why verification does not require contacting the issuer, and the practical guidance for verifiers who want to minimize the data they hold.

For the broader picture, see Privacy in MATTR's architecture.

Verification is a local cryptographic check

MATTR's verification capabilities check four things on each presented credential:

• The credential's digital signature is valid.
• The signing key chains back to a trusted issuer (either via a local trust list or via an external Digital Trust Service).
• The credential structure conforms to the relevant standard (for example, ISO/IEC 18013-5 for mDocs).
• Optional time-based checks (validity period, expiry, revocation status) where applicable.

All four checks can be performed locally by the verifier. There is no protocol-level requirement to contact the issuer at presentation time. This is a deliberate architectural property: it lets verification work offline, removes a single point of failure, and prevents the issuer from observing verification activity.

For details on the checks performed on each credential type, see Credential verification and the format-specific overviews.

What MATTR's verifier sees and what it does not retain

The verifier receives only the attributes the holder consented to release. With selective disclosure, this is typically a small subset of the credential. The verification capability:

• Computes the cryptographic checks.
• Returns the verification result to the calling application.
• Does not persist the credential content.

If the verifier's business application wants to retain attributes from the presentation (for example, the user's age band to demonstrate compliance with an age-restricted purchase law), that retention is an application-level decision. It is not done by MATTR's verification capability by default.

The cryptographic proof itself can be discarded once the verification result has been recorded. The proof is bound to a specific presentation and is not designed to be re-presented later.

Selective disclosure in verification

The flip side of selective disclosure on the holder side is that the verifier requests only what it needs.

When a verifier sends a presentation request, it specifies the attributes it wants. The wallet shows the user what is being requested, the user consents, and the wallet produces a proof that reveals only those attributes. The verifier receives the requested attributes and a cryptographic proof that they came from a credential signed by the issuer.

This shifts the verifier's data discipline upstream. Instead of receiving the full credential and then storing only what is needed, the verifier requests only what is needed in the first place and never sees the rest.

See Selective disclosure for a fuller treatment of the concept.

Checking revocation without exposing the holder

Revocation is the area where verification comes closest to a live issuer interaction, and care is needed to preserve privacy properties.

MATTR supports revocation via status lists. A status list is a published list of indices and binary revocation values that the issuer maintains and the verifier fetches when it needs to check status. Two privacy properties matter here:

• Status lists do not contain personal information. The list is a sequence of binary values indexed by position. There is no link from a status list entry to the holder's identity.
• Fetching a status list does not identify the holder. The verifier requests the list as a whole (or a chunk of it). The issuer can see that some verifier fetched the list, but cannot tell which specific credential or holder triggered the check.

Verifiers who care about minimizing issuer-side correlation can cache status lists locally and refresh them on a schedule independent of individual verifications.

Trust establishment

The verifier needs a way to know which issuers it should trust. There are two patterns:

• Local trust lists. The verifier maintains its own list of trusted issuer IACAs or DIDs and evaluates each presentation against that list.
• External trust via a Digital Trust Service. The verifier consumes trust information from a DTS (for example, via a VICAL or an Ecosystem policy). The DTS is the network operator's tool for managing trust across many participants. See Privacy in digital trust services for how DTS consumption preserves the architecture's privacy properties.

In neither case does the verifier need to contact the issuer at presentation time.

Practical guidance for verifiers

• Request only the attributes you need to make the decision you are making. If you are checking age eligibility, request the age-attestation attribute, not the date of birth.
• Treat the cryptographic proof as transient. Record the verification result, not the proof itself, unless you have a specific evidentiary requirement.
• Cache status lists locally and refresh them on a schedule. Do not fetch the list once per verification if you can avoid it.
• If you need to retain disclosed attributes for compliance reasons, scope the retention period to the minimum required by law and document the basis. The architecture supports a minimal retention model; the deployment has to honor it.
• Be transparent with the holder about why you are requesting each attribute. Trust frameworks increasingly require verifiers to declare a purpose as part of the presentation request, and many wallets surface this to the user.
• Choose the regional MATTR deployment that matches your data residency obligations. Verifier configuration data stays within the chosen AWS region except for listed sub-processors.

Frequently asked questions

Does the verifier need to contact the issuer to verify a credential?

No. The credentials MATTR supports carry a cryptographic signature that can be verified locally against the issuer's published public key or the relevant trust anchor. The verifier does not need a live connection to the issuer at presentation time.

Does MATTR's verifier store the presented credential?

Not by default. The verification capability performs the cryptographic checks required to confirm the credential's authenticity and validity, returns the result, and does not retain the credential content. If the verifier wants to retain specific attributes, that retention is a deliberate, application-level decision.

Is the issuer told when a credential is verified?

No. The verification check is local. The only case where a verifier may interact with an issuer-controlled endpoint is when checking a status list for revocation, and even that interaction does not identify the holder.

How do I check whether a credential has been revoked without leaking the holder's identity?

Revocation is checked against published status lists. A status list contains an index and a binary revocation value. The verifier fetches the status list (which may cover many credentials) and reads the relevant index. The issuer cannot tell which specific holder's status was checked.

Can a verifier request more attributes than it needs?

Technically, yes. The architecture cannot prevent a verifier from asking for too much. The protections against over-collection are the user's ability to decline, the wallet's consent UI, the issuer's policy, and accreditation rules in the relevant trust framework.

Related reading

• Privacy in MATTR's architecture
• Selective disclosure
• Decentralized trust model
• Remote verification overview
• In-person verification overview
• Digital Trust Service