Privacy in credential holding

How MATTR's holder products keep credentials under the user's control, support selective disclosure, and minimize the ability to correlate usage across presentations.

Holding is the part of the credential lifecycle that sits closest to the user. The holder's wallet is where credentials are stored, where consent is mediated, and where selective disclosure is enforced. The privacy properties of a credential ecosystem stand or fall on what the wallet does.

This page describes how MATTR's holder products (the MATTR Pi Holder SDKs and the MATTR GO white-label wallet) approach privacy. For the broader picture, see Privacy in MATTR's architecture.

The holder is in control

In a decentralized credential model, the holder is the party that controls the credential. The credential is delivered to the holder once at issuance and is then stored on the holder's device. The holder decides when to present it, to whom, and which attributes to release.

MATTR's holder products implement this principle in three concrete ways:

On-device storage: Credentials are stored on the user's mobile device. Cryptographic keys bound to the credential are protected by platform secure storage (Secure Enclave on iOS, Keystore on Android). MATTR does not hold a server-side copy of the credential.
Explicit consent: Before any credential or attribute is released to a verifier, the wallet prompts the user to consent to the specific request. The user can see which attributes are being requested and decline if the request is excessive.
Local enforcement of issuer policy: Where the credential format and the issuer's policy support it, the wallet enforces the issuer's rules locally. For example, the wallet can refuse to release an attribute to a verifier that has not declared an acceptable purpose.

Selective disclosure

Selective disclosure is the mechanism that lets a holder reveal only the attributes a verifier needs, rather than the entire credential. It is one of the strongest privacy properties of the verifiable credential model.

For a worked explanation of the concept and the business value, see Selective disclosure.

In practice, when a verifier sends a presentation request, the wallet:

Inspects the request to determine which attributes the verifier is asking for.
Identifies which of the holder's stored credentials can satisfy the request.
Shows the user the specific attributes the verifier has requested, along with the verifier's identity where available.
Asks the user to consent to release those attributes.
Produces a cryptographic proof that reveals only the consented attributes, while still proving the credential is signed by the issuer.

The verifier never sees the attributes that were not requested. The proof is mathematically binding: the verifier can be confident that the disclosed attributes came from a credential signed by the issuer, without seeing anything else.

Minimizing correlation across presentations

A separate concern from "what data does this verifier see" is "can multiple verifiers (or the same verifier over time) link their interactions with the same holder." This is the unlinkability problem, and it matters in any ecosystem where credentials are presented frequently.

MATTR's holder products approach this in several ways:

Credential formats that support selective disclosure: mDocs let the holder release only the attributes a verifier needs, reducing the surface available for correlation.
Ephemeral session keys for proximity presentation: When a credential is presented in person using BLE (as defined in ISO/IEC 18013-5), a fresh session key is derived for every interaction. The key is unique to that session and discarded when the session ends. See Proximity presentation for the full engagement flow.
Issuer support for short-lived credentials: Where the use case allows, issuers can issue credentials that expire frequently and are refreshed in the background. This reduces the value of any single credential as a long-term correlator.

Some correlation risk is inherent to any system where a holder presents the same unique attribute to multiple parties. If a holder presents the same driver licence number to two different verifiers, those verifiers can correlate their records if they choose to share them. The architecture cannot prevent this; verifier obligations and trust framework rules do that work.

What MATTR's Holder SDKs do NOT do

The decentralized model gives the wallet a privileged position. It sees every credential the holder receives and every presentation the holder makes. To preserve the architecture's privacy properties, MATTR's holder products explicitly do not:

Report verification activity back to MATTR or to a central server.
Transmit credential content to MATTR's infrastructure.
Build a server-side profile of the user across credentials and presentations.

The mobile applications use a small set of backend services for legitimate operational purposes (license validation, application analytics about device type and OS version for compatibility and billing, error monitoring). These services do not receive credential content and are listed explicitly in the published sub-processor list at /docs/resources/terms/data-sub-processors.

Practical guidance for wallet integrators

If you are building a wallet using the MATTR Pi Holder SDKs or customizing MATTR GO, the following principles support a privacy-preserving holder experience:

Surface the verifier's identity and the specific attributes requested before asking for consent. Users cannot exercise control over what they cannot see.
Default consent UI to releasing the minimum required attributes. Let users opt into releasing more only if they choose.
Avoid logging or analytics that captures the attributes released in a presentation. Aggregate counts are fine; per-presentation attribute logs are not.
If your deployment supports holder analytics, make this opt-in and disclose it clearly in your privacy notice.
Be transparent with users about what device telemetry your wallet sends. The MATTR holder backend collects device model, OS version, and key attestation data for compatibility and licensing purposes. This is documented and should be reflected in the deployment's user-facing privacy notice.

Frequently asked questions

Where do credentials live when a user holds them?

Credentials live in the holder's wallet on their mobile device, protected by the platform's secure storage (Secure Enclave on iOS, Keystore on Android). The credential is not stored on a MATTR server.

Does the issuer know when a credential is presented?

No. The cryptographic design of the credentials MATTR supports lets a verifier confirm authenticity without contacting the issuer. The issuer is out of the verification loop and does not observe individual presentations.

How does selective disclosure work in practice?

When a verifier requests information, the wallet shows the user which attributes the verifier is asking for. The user consents to release only the requested attributes. The credential format and cryptographic scheme produce a proof that reveals only those attributes while still proving the credential is signed by the issuer.

Can two verifiers correlate the same holder across presentations?

The credential formats MATTR supports are designed to limit unintended correlation, but some risk remains if the same long-lived attribute (for example, a unique licence number) is disclosed to multiple verifiers. Best practice is for verifiers to request only the minimum required attributes and for issuers to support short-lived credentials and rotating identifiers where the use case allows.

What happens if a user loses their device?

The credential is bound to keys held in platform secure storage on the lost device. Anyone gaining access to the device must also defeat the device's lock screen and any wallet-level authentication to use the credential. Issuers can revoke compromised credentials via the standard revocation flow.

Privacy in credential holding

On this page