eIDAS 2.0 / EUDI
Règlement (UE) n° 910/2014 modifié par le règlement (UE) 2024/1183
L'exigence. L'identité numérique européenne se déploie (portefeuille EUDI fin 2026) ; la signature électronique aux formats européens (PAdES) devient un standard d'échange.
La réponse AWA. AWA génère et vérifie cryptographiquement des signatures PDF aux formats PAdES B-B, B-T, B-LT, B-LTA directement dans le navigateur ; l'horodatage et les éléments de révocation sont fournis par l'intégration. Le document ne quitte jamais le poste de l'utilisateur : aucun serveur de signature ne voit vos contrats.
Dossier de preuves relatives à la conformité — synthèse exécutive
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.
Dossier généré le 2026-10-01 · preuves vérifiées le 2026-10-01
Statut AwaCloud
Non applicable (justifié) — AwaCloud n'est pas un prestataire de services de confiance · statut au 15/09/2026.