Skip to main content

Validation

When someone presents a PID (Person Identification Data) from their EUDI Wallet, you cannot simply trust it at face value — just as you would not accept a photocopied ID card without checking it. Validation is the process of confirming, step by step, that a presented PID can actually be trusted before you rely on it.

A presentation could, in principle, go wrong in several ways: it could come from an untrustworthy issuer, be intercepted and replayed by someone else, be presented by a person it was never issued to, contain more data than you asked for, or simply be expired or revoked. Validation is what rules each of these out — one check at a time.

What gets checked​

A verifier works through a series of checks, roughly in this order. Each one answers a plain question:

  1. Is this from a trustworthy source? The verifier confirms the PID issuer and the wallet provider are part of the recognized, official trust framework — not an unknown or fraudulent party.
  2. Is this response really meant for me? The verifier makes sure the presentation was generated specifically in response to its own request, right now — not intercepted, reused from an earlier session, or redirected from somewhere else.
  3. Is this being presented by the right person? Even a completely genuine PID must be proven to belong to the person presenting it, using a cryptographic proof tied to their specific wallet. This stops a copied or stolen credential from being reused elsewhere.
  4. Is the credential itself genuine and current? The verifier checks that the PID was really issued by the claimed authority, has not been altered, is still valid, and has not been revoked.
  5. Did I only receive what I actually need? The verifier confirms that no more personal data was shared than was requested — for example, receiving proof of "over 18" without receiving a full birth date.
  6. Does it meet my own requirements? Only once all the above are confirmed does the verifier apply its own business rules, such as checking that a required attribute has an acceptable value.

Why the order matters​

These checks are performed in sequence, and stop immediately at the first failure. A verifier does not, for example, apply business rules to data whose authenticity has not yet been confirmed. This "fail fast" approach avoids wasted effort and — more importantly — avoids ever acting on data that cannot yet be trusted.