EUDI infrastructure
IACA (Issuing Authority Certificate Authority)
An IACA, or Issuing Authority Certificate Authority, is the root certificate authority an mdoc issuing authority operates. Trust in an mdoc is decided by whether its Document Signer certificate chains to an IACA root the verifier already holds, so the IACA list is the mdoc equivalent of a trusted list.
Also called: IACA, issuing authority certificate authority, IACA root, Document Signer
At a glance
- Stands for
- Issuing Authority Certificate Authority
- Role
- Root of trust for an mdoc issuing authority
- Signs credentials
- No: the Document Signer does, and chains to the IACA
- Trust decided by
- Chain anchoring; the issuer string is not consulted
- Certificate profile
- ISO/IEC 18013-5 Annex B, commonly unenforced
How mdoc trust is decided
Two certificates matter. The IACA is the root, held by the issuing authority, for example a member state or a licensing body. The Document Signer is the certificate that actually signs each credential's Mobile Security Object, and it chains to that root.
A verifier decides trust purely by chain anchoring: does this Document Signer chain to a root I already trust. Unlike a trust model keyed on an issuer string, the identifier inside the document is not consulted at all, so an attacker choosing what the document claims about itself cannot move the answer. That is a good property, and it means the whole question reduces to which roots you loaded.
The check most verifiers skip
Chaining is necessary and not sufficient. ISO/IEC 18013-5 Annex B specifies a profile for the Document Signer certificate: what extended key usage it must carry, what key usage, and how long it may live. A verifier that checks only the chain will accept a certificate that anchors correctly but is not a valid Document Signer under that profile.
It is worth asking any mdoc library whether it enforces the Annex B profile, because the answer is often no, and a library that does not should say so. A green result implies it did.
Where the roots come from
That is the practical difficulty. Unlike the eIDAS world, which has a published list of lists, mdoc IACA distribution is still fragmented: roots come from the issuing authorities themselves, from national registries, or from the EU ecosystem's trusted entity lists as those fill out.
Until you have loaded real roots, every real mdoc will correctly report as untrusted, which is a configuration state, not a verdict about the document, and a verifier should distinguish the two.
Check one yourself
Reading about it only gets you so far. These are free validators in Tessio Labs, no signup, and nothing you paste is stored.
Why it matters
If every mdoc you test reports untrusted, check which roots you loaded before suspecting the documents. An empty root set produces a confident and meaningless no.
Ask your mdoc library whether it enforces the Annex B Document Signer profile. Chain anchoring alone accepts certificates the spec would not.
Frequently asked
Is an IACA the same as a trusted list?
It plays the same role and is distributed differently. An eIDAS trusted list is a signed, published list you fetch; IACA roots are certificates you obtain and configure. The eIDAS side has a single root to start from, the mdoc side doesn't yet.
Can one issuing authority have several IACA roots?
Yes, and rotation is normal, which is why a verifier holds a set of them and why an expired root doesn't necessarily mean an invalid document.
Does anchoring on an IACA prove the document is genuine?
It proves the Document Signer chains to an authority you trust. You still need the Mobile Security Object signature to verify and the disclosed elements to match its digests, otherwise you have trusted a signer without checking what they signed.
Primary sources
This is a plain language explanation, not legal advice. Specifications and dates in this area move, so check anything you are going to rely on against the primary sources.
Keep reading
Age verification API
Or skip the theory and build against it
Tessio proves someone is over 18 from their EU Digital Identity Wallet and stores no personal data. Access is invite only while we onboard design partners. Tell us what you're building.