Every other page in these docs assumes you already know what a wallet, a credential, and a “verifiable presentation” are. This page doesn't. Read it first if any of that is new, then come back to Verify API or Age API for the implementation.
Right now, proving something about yourself to a website usually means uploading a photo of your passport, or a scan of a utility bill. The site asked for one fact, maybe that you're over 18, or that your name matches a bank account, and in exchange it received your full name, date of birth, address, document number, nationality, and a photo, all of it now sitting on someone else's server indefinitely. You had no way to hand over less. The document is all-or-nothing.
That's the gap eIDAS 2.0 is built to close. eIDAS (electronic IDentification, Authentication and trust Services) is the EU regulation governing digital identity across member states. Its first version, from 2014, mainly let citizens log into other countries' government services. eIDAS 2.0, in force since 2024 and rolling out through 2026 and beyond, goes much further: it requires every EU member state to make its citizens a Digital Identity Wallet, a phone-based wallet holding officially issued, cryptographically signed credentials, starting with a digital version of your national ID or passport data (called a PID, Person Identification Data credential), with things like driving licences and diplomas following.
This does more than turn a photo ID into an app. One government-issued credential can be reused everywhere, and the wallet, not the site asking, controls exactly what gets shared each time. A bar checking your age and a bank running a KYC check are asking fundamentally different questions, and for the first time, they can each get an answer sized to what they asked.
The wallet is issued under the authority of your own government, the same authority that issues your passport today. That's the trust anchor: when Nexiel receives a claim from your wallet, the cryptographic signature behind it traces back not to Nexiel, and not to whichever company built the wallet app, but to a national authority's published, auditable trust list. Trusting the claim means trusting that chain, the same way a border officer trusts your passport because it chains back to your government's passport-signing key, not because they trust the plastic.
Selective disclosureis what makes the wallet more useful than a passport photocopy: each individual fact on your credential, given name, family name, birthdate, nationalities, is signed in a way that lets you prove any one of them on its own, without revealing the rest, and without the signature becoming any less valid. Think of a notarized document where you can redact every line except the one a specific request needs, and the remaining line is still provably signed by the notary, so nobody has to take your word for what you blacked out. A paper ID can't do that. A wallet built around selective disclosure can, and it makes minimal disclosure the technical default.
Strip away the protocol names and this is what happens when a site or app asks you to verify with your EU Digital Identity Wallet:
Behind the scenes, for an age check, the site that asked never sees your birthdate at any point in that flow: it gets back a boolean and nothing else. Nexiel's own server briefly holds the raw birthdate just long enough to compute that boolean, then discards it immediately, never storing it, logging it, or returning it in any response. There is no native “over 18” claim a real PID credential can disclose directly, so birthdate, used this narrowly, is the closest a real EUDI wallet gets to that. For an identity-linked AML check (Nexiel Screen's aml-identity check type), your wallet discloses a few more claims, given name, family name, birthdate, nationalities, because that specific check genuinely needs them to run sanctions and PEP screening. Even then, only the screening outcome and boolean proofs get kept afterward, never the underlying claim values, and a possible match is always sent to a human to review, never auto-decided.
Everything above has names. Nexiel Verify and Nexiel Age implement three specifications together, and it's worth knowing what each one is responsible for.
OpenID4VP (OpenID for Verifiable Presentations) is the protocol a verifier (Nexiel, asking) and a wallet (your app, answering) use to have that conversation. Nexiel builds an authorization request naming exactly what it wants, the wallet resolves it (via a scanned QR code or an openid4vp:// deep link on the same device), and posts its response straight back to a response_uriNexiel controls, a “direct post” response with no browser redirect involved. Nexiel Verify and Nexiel Age implement OpenID4VP 1.0 Final, published 2025-07-09.
DCQL (Digital Credentials Query Language) is the syntax for stating “these claims, from this credential, and no others.” Here's the exact query Nexiel Age sends for an age check. It offers a wallet two alternative ways to answer, via DCQL credential_sets: the EU's official Age Verification (AV) attestation, if the wallet holds one (a native age_over_18boolean, no birthdate ever disclosed at all), or the PID's birthdateclaim as a fallback where it doesn't. A conformant wallet answers exactly one of the two:
{
"credentials": [
{
"id": "av_age_over_18",
"format": "mso_mdoc",
"meta": {
"doctype_value": "eu.europa.ec.av.1"
},
"claims": [
{
"path": [
"eu.europa.ec.av.1",
"age_over_18"
]
}
]
},
{
"id": "pid_birthdate",
"format": "dc+sd-jwt",
"meta": {
"vct_values": [
"urn:eudi:pid:1"
]
},
"claims": [
{
"path": [
"birthdate"
]
}
]
}
],
"credential_sets": [
{
"options": [
[
"av_age_over_18"
],
[
"pid_birthdate"
]
],
"required": true
}
]
}Neither alternative can also ask for your name or nationality: the request has nowhere to put them. If the wallet answers with the AV attestation, Nexiel already receives a yes/no boolean and nothing else. If it answers with the PID fallback, Nexiel Age computes that same age_over_18 boolean from the one disclosed birthdate server-side and discards it immediately, so the site that asked never receives, stores, or sees the raw value either way.
SD-JWT VC (Selective Disclosure JWT Verifiable Credential, specified in RFC 9901) is the credential format that backs all of this. When your national authority issues your PID credential, each individual claim gets hashed separately, with a random salt, and only those hash digests get signed, not the claim values themselves. To disclose a claim later, your wallet reveals the salt-and-value pair that hashes to a digest the issuer already signed. Nexiel can then check that one claim was genuinely part of what your government issued, without ever seeing, or being able to reconstruct, any claim you didn't disclose. The maths, not a UI setting, is what makes minimal disclosure enforceable.
A valid signature only proves a credential was signed by somekey. Deciding whether that key belongs to a real, currently-authorized national PID issuer is a separate step: checking it against that country's eIDAS Trusted List, an auditable, government-published registry of exactly which authorities are allowed to issue which kind of credential right now. Verifying a wallet presentation means checking both: is the signature valid, and does the specific key that made it trace back to a currently-granted entry on a real Trusted List.
OpenID4VP 1.0 Final request/response handling, the DCQL templates shown above, SD-JWT VC issuance and verification, and eIDAS Trusted List parsing and signature verification are built and tested against live EU, Irish, and German government trust lists.
No EU member state has published a PID-Provider entry on its Trusted List yet, so there is no live anchor to verify a real wallet credential against in production. Every example in these docs, including the ones on this page, runs in sandbox modeagainst a synthetic test issuer, and production mode fails closed rather than trust anything it can't trace to a real anchor. On our roadmap: live PID Provider verification, the moment a real Trusted List anchor exists to verify against.
For the full technical walkthrough with request and response examples, see the Verify API quickstart and Age API quickstart. For the product-level view, see Nexiel Verify & Screen and Nexiel Age. For who needs to be registered before a wallet credential can be verified at all, see Two ways to get relying party status.