Privacy in credential issuance

MATTR VII is the platform component that issues verifiable credentials. This page describes how MATTR VII handles personal data during issuance, what is retained after a credential is delivered, and the configuration choices that determine the data footprint of an issuance flow.

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

Issuance is a transit operation

MATTR VII is designed as a transit platform for credential issuance. The role of the platform is to take inputs from authoritative systems, produce a cryptographically signed credential, and deliver it to the holder's wallet. It is not designed as a long-term store of credential content.

In practice, this means:

• Claims are fetched at issuance time from the configured Claims source or supplied via the credential offer.
• The claims are used to populate the credential and to compute the cryptographic signature.
• The signed credential is delivered to the holder.
• The claim values are not persisted by default.

The issuer's system of record remains the authoritative source for the underlying data. MATTR VII does not become a parallel store of credential content.

What MATTR VII retains by default

To support audit, billing, and lifecycle operations such as revocation, MATTR VII retains a limited set of metadata for each credential it issues. By default, this includes:

• A reference to the User the credential was issued to.
• The credential configuration used.
• A hash of the issued credential (for mDocs, a hash of the MSO).
• The device public key bound to the credential.
• Issuance timestamps and status.

This metadata does not include the actual claim values inside the credential. It is enough to support credential lifecycle operations without recreating the data minimization properties the architecture is designed to provide.

If the customer wants to track which users have been issued which credentials, the User object is the intended hook. The claims map on a user is deliberately small and is intended for pseudonymous identifiers (for example, an external user ID that maps back to the customer's system of record), not for storing the credential content itself.

Claims sources

A Claims source is the customer-controlled endpoint that MATTR VII calls during issuance to retrieve the data that will go into a credential. The platform acts purely as a client of that endpoint:

• Requests are made over HTTPS using either an API key or OAuth client credentials.
• MATTR VII passes only the request parameters configured by the customer, which can include identifiers from the authentication flow or the credential offer.
• The response is used to populate the credential being issued.
• The response is not retained beyond what is necessary to complete the issuance request.

The customer controls what data their claims source returns. The privacy principle for this integration is the same one that applies elsewhere: return only the data needed for the credential being issued, not the full record about the user.

OID4VCI flows and user data

The OID4VCI flows used by MATTR VII have different user-data implications. The Authorization Code flow involves authenticating the user against the customer's authentication provider before the credential is issued. MATTR VII stores the relationship between the MATTR VII user and the authentication provider subject (so that future credentials can be associated with the same user), but it does not store the authentication provider's identity attributes.

The Pre-authorized Code flow does not involve a direct authentication interaction. The customer's backend has already established the user's identity before generating the credential offer. The flow can pass a pre-authorized code and an optional transaction code to bind the offer to a specific holder.

In both flows, the data minimization principle is the same: pass only what is needed to identify the user for the issuance interaction. Anything else belongs in the customer's system of record.

After issuance

After a credential is delivered to the holder's wallet, MATTR VII's involvement in the credential ends, except for lifecycle operations the customer initiates:

• Revocation is supported by publishing status lists. Status lists contain only an index and a binary revocation value. They do not contain personal information.
• Update flows allow the holder's wallet to obtain an updated credential when one is available. The update interaction follows the same data-handling rules as initial issuance.

MATTR VII does not observe where the credential is presented, by whom it is verified, or what specific attributes are disclosed. There is no central log of credential usage at the issuer.

Practical guidance for issuers

• Use Claims sources to fetch data at issuance time rather than uploading bulk datasets to the platform.
• Keep User claims to a pseudonymous external identifier where possible. Do not persist sensitive personal information on the User object.
• Choose the regional cloud deployment that matches your data residency requirements at onboarding. Customer data stays within the chosen AWS region except for the listed sub-processors.
• Make sure your end-user privacy notice reflects what your issuance flow actually collects and retains, and obtain consent from the user for anything you intend to persist. The architecture supports a minimal footprint, and the customer-facing notice should describe what the deployment actually does.
• Handle data subject requests through the Users API. The Get user and Get user credentials endpoints return what MATTR VII holds about a given subject, and Delete user removes that record to support right-to-be-forgotten requests. Note that credentials already issued to the user remain valid after the User record is deleted. If a right-to-be-forgotten request requires invalidating those credentials, revoke them via the status list as a separate step.
• For dedicated cloud customers, configure analytics at Level 1 or Level 2. Level 3 (full event data) is only appropriate for short-lived debugging and should be paired with a reduced retention period. See the platform events registry for the available levels.

Frequently asked questions

Does MATTR VII store the claims contained in credentials it issues?

No, not by default. MATTR VII operates as a transit platform during issuance. Claims flow through the platform to be signed into a credential and are then delivered to the holder. Claim values are not persisted unless the customer has explicitly configured them to be.

Can MATTR VII track how a credential is used after it is issued?

No. Once a credential is delivered to the holder's wallet, MATTR VII has no visibility into where, when, or how it is later presented. The decentralized architecture makes this technically impossible from the issuer side.

What information about issued credentials is retained?

Limited audit information is retained, such as a hash of the credential, the credential configuration used, and a reference to the user the credential was issued to. The actual claim values are not retained by default.

How are claims sources protected?

Claims sources are called over HTTPS using either an API key or OAuth client credentials. MATTR VII fetches only the data required for the specific credential being issued, uses it to populate the credential, and does not persist the response beyond what is needed to complete issuance.

What if I need to retain claims for business reasons?

Selected attributes can be configured to be persisted on the MATTR VII user via the claims source configuration. This is an explicit, opt-in choice. Best practice is to avoid persisting sensitive personal information and to favor pseudonymous external identifiers over full identity attributes.

Related reading

• Privacy in MATTR's architecture
• Selective disclosure
• Decentralized trust model
• Claims source
• Users
• Revocation