eIDAS 2.0 / EUDI
Reg. (EU) 910/2014 as amended by (EU) 2024/1183
The requirement. European digital identity is rolling out (EUDI wallet, end of 2026); electronic signature in European formats (PAdES) is becoming an exchange standard.
The AWA answer. AWA generates and cryptographically verifies PDF signatures in the PAdES B-B, B-T, B-LT, B-LTA formats — in the browser; timestamps and revocation material are supplied by the integration. The document never leaves the user's device: no signing server sees your contracts. Try the demo: sign a PDF and watch the network tab.
Compliance evidence pack — executive summary
eIDAS-01 proven Art. 26 · ETSI EN 319 142-1 — advanced electronic signature creation (PAdES)
PAdES signature generation at levels B, T, LT and LTA: detached PKCS#7/CMS SignedData, a /ByteRange covering the whole document minus /Contents, ESS signing-certificate-v2 signed attributes, an RFC 3161 timestamp token, a DSS (/Certs, /OCSPs, /CRLs, /VRI) and a /DocTimeStamp layered by genuine incremental updates. A PAdES emitter must explicitly pass subFilter: 'ETSI.CAdES.detached' — the default is adbe.pkcs7.detached.
eIDAS-02 proven Art. 32 · ETSI EN 319 102-1 — signature validation
Verification reconstructs the /ByteRange-covered bytes, recomputes the digest, locates the signer certificate inside the embedded PKCS#7 SignedData and executes the public-key check itself (rsa.pssVerify / ECDSA / ed25519.verify). SubFilters supported: adbe.pkcs7.detached, adbe.pkcs7.sha1 (legacy), ETSI.CAdES.detached, ETSI.RFC3161, plus Ed25519 (ISO/TS 32002). The module's own documentation distinguishes verified / valid / pkVerified; that distinction is part of the claim and must not be flattened to "validates signatures".
eIDAS-03 proven ETSI EN 319 142-1 — PAdES baseline profile identification
Profile detection by /SubFilter with an inferred level (B-B / B-T / B-LT / B-LTA), /Reference array typing, DSS typing, DocMDP validation and the B-LTA chain check per ISO 32000-2 §12.8.4.3. The module does not verify the cryptography — its own API page states "Does NOT verify the cryptography" verbatim, and that limit is part of this row rather than a footnote.
eIDAS-04 gap Art. 3(16)–(20), Annex I–II — qualified trust services (QES, QTSP, EU Trusted Lists, QSCD)
Absence claim. Nothing in the shipped surface consumes an EU Trusted List, integrates a QSCD, or ships an RFC 3161 TSA client: levels T, LT and LTA require the caller to supply a tsaSign callback. The component produces AdES signatures; it is not a trust service and cannot make a signature qualified.
No trust-service layer ships. Conformity of the signature service stays with the buyer's own QTSP. Backlog BL-819 (EU Trusted List consumption + RFC 3161 TSA client) records the closure work; it is scoped to tools/ and unbuilt.
eIDAS-05 gap Reg. (EU) 2024/1183 — EUDI wallet / electronic attestation of attributes
Absence claim. No wallet interface, no attestation-of-attributes format, no proximity or remote presentation flow.
Honest absence, and the most likely buyer question with no answer here. It is a product decision, not a repository task: unowned by design, no owning plan exists and none is implied.
eIDAS-06 proven Art. 32(1)(b) — reliance on trustworthy algorithms
Algorithm agility with an explicit refusal: RSA-PSS, ECDSA over P-256 / P-384 / P-521 and Ed25519 are supported, and PKCS#1 v1.5 is deliberately refused as a framework policy citing the NIST SP 800-131A Rev. 2 deprecation.
| Pack generated | Evidence verified |
|---|---|
| 2026-10-01 | 2026-10-01 |
AwaCloud status
Not applicable (justified) — AwaCloud is not a trust service provider · status as of 2026-09-15.