De la puce de votre carte d'identité à une signature qualifiée validée, message par message.
Signature électronique ou numérique, identification ou authentification, ce que « qualifiée » garantit vraiment : cette page présente les messages et structures de données prévus par les protocoles, étape par étape. Les exemples sont illustratifs : valeurs fictives, messages parfois tronqués, et formats non publiés signalés comme tels.
Référentiel technique complet
Version textuelle directement présente dans le HTML. Chaque section peut être consultée sans exécuter JavaScript.
00Acteurs et chaîne de confiance
Cadre et définitions
Chaque flux de cette page met en jeu les mêmes familles d'acteurs. Le point à retenir : chaque acteur ne fait confiance qu'à des clés publiques précises, et chacune de ces clés remonte à une ancre de confiance publiée.
eIDAS et normes techniques : deux rôles complémentaires
eIDAS 2 (règlement 2024/1183, modifiant le règlement 910/2014) fixe les obligations juridiques ; ses actes d'exécution désignent les normes et spécifications qui permettent de les remplir. Pour les services de confiance, les références comprennent notamment les normes ETSI ; pour les échanges du portefeuille européen, les spécifications OpenID et ISO. Il ne s'agit donc pas d'un abandon de l'ETSI au profit d'eIDAS 2.
Les règlements d'exécution 2025/1943 (certificats qualifiés) et 2025/1945 (validation des signatures et cachets) désignent des versions précises de normes ETSI, avec les adaptations de leurs annexes, pour bénéficier d'une présomption de conformité. Adoptés le 29 septembre 2025 et publiés le 30 septembre, ils sont entrés en vigueur le 20 octobre 2025. Une norme publiée plus récemment ne remplace pas automatiquement la version désignée par un acte.
Qui fait confiance à quoi
Les flèches pointent de celui qui vérifie vers ce qu'il considère comme ancre de confiance. Aucune vérification n'est possible sans une clé publique obtenue par un canal déjà sûr.
Les acteurs, ce qu'ils détiennent et ce qu'ils croient
Personne
- Détient
- Code personnel ou PIN, caractéristiques biométriques, consentement.
- Fait confiance à
- Ce que l'interface lui affiche.
Puce CNIe
- Détient
- Données d'identité signées (EF.SOD), clé privée d'authentification de puce.
- Fait confiance à
- Le mot de passe PACE (CAN).
France Identité
- Détient
- Session PACE, données lues, liaison locale au déverrouillage du téléphone.
- Fait confiance à
- Certificat CSCA France pour l'authentification passive.
Portefeuille
- Détient
- Attestations (PID, EAA), logique de consentement, journal des transactions.
- Fait confiance à
- Listes de confiance des fournisseurs de PID et des services enregistrés.
WSCD
- Détient
- Clés privées liées aux attestations (P-256), jamais exportées.
- Fait confiance à
- Authentification locale de l'utilisateur.
Fournisseur de portefeuille
- Détient
- Clé de signature des attestations d'instance et de clés.
- Fait confiance à
- Attestation du système d'exploitation sur l'appareil.
Fournisseur de PID
- Détient
- Clé de signature des PID (certificat X.509), listes de statut.
- Fait confiance à
- Attestation de portefeuille, moyen d'identification national.
Service utilisateur
- Détient
- Certificat d'accès, clé de chiffrement éphémère, nonce.
- Fait confiance à
- Listes de confiance des émetteurs de PID.
FranceConnect+
- Détient
- Clés de signature ES256, sessions.
- Fait confiance à
- Fournisseurs d'identité substantiel et élevé.
Application de signature
- Détient
- Document, structure PAdES en construction.
- Fait confiance à
- Certificat du signataire.
Service de signature du QTSP
- Détient
- Clé privée du titulaire dans le HSM, contrôlée par le SAM.
- Fait confiance à
- Données d'activation (SAD) liées au condensat.
Autorité d'horodatage
- Détient
- Clé de l'unité d'horodatage, horloge UTC.
- Fait confiance à
- Source de temps traçable.
Validateur
- Détient
- Politique de validation, contraintes cryptographiques.
- Fait confiance à
- LOTL de la Commission et listes nationales.
LOTL et listes de confiance
- Détient
- Statut des prestataires qualifiés et leurs certificats.
- Fait confiance à
- Signature de la Commission (LOTL) et des organes de contrôle.
Sources
- Règlement (UE) n° 910/2014, texte consolidé au 18 octobre 2024
- Règlement (UE) 2024/1183 (eIDAS 2)
- Règlement d'exécution (UE) 2025/1943 (certificats qualifiés, annexes I et II)
- Règlement d'exécution (UE) 2025/1945 (validation, annexes I et II)
- Commission européenne, listes de confiance (article 22)
- ETSI, prestataires de services de confiance et LOTL
01Enrôlement : lire la CNIe et créer l'identité numérique
Production et spécifié
Les échanges avec la puce suivent des normes publiques (ICAO 9303, BSI TR-03110). Le protocole entre l'application France Identité et ses serveurs n'est pas publié : ces étapes sont signalées.
C'est l'étape qui lie une personne physique à des données. L'application lit la puce de la carte d'identité par NFC, vérifie que les données ont été signées par l'État et que la puce n'est pas un clone, puis crée une identité numérique que l'usager peut faire certifier en mairie.
Saisir le numéro d'accès à la carte
Personne → France Identité · Saisie du CAN
Entrée
Numéro imprimé sur la carte, utilisé comme mot de passe PACE.
CNIe (format ID-1, émise depuis août 2021)
CAN (Card Access Number) : 6 chiffres imprimés au recto
Exemple : 123456Traitement
- L'application demande le CAN : sans lui, la puce refuse tout accès sans contact.
- Le CAN devient le mot de passe π du protocole PACE ; il n'est jamais transmis tel quel à la puce.
- Une clé Kπ est dérivée de π par la fonction de dérivation de BSI TR-03110 (compteur 3).
Sortie
Matériel local prêt pour PACE.
π = "123456"
Kπ = KDF(π, 3) -- clé de 128 bits pour une suite AES-128 (selon la suite annoncée par la puce)Suite : Kπ sert à déchiffrer le nonce envoyé par la puce à l'étape suivante. Empêcher la lecture à distance à l'insu du titulaire est le but : il faut voir la carte pour connaître le CAN.
Établir un canal sécurisé avec la puce (PACE)
France Identité → Puce CNIe · PACE (APDU)
Entrée
Commandes ISO 7816-4 envoyées par NFC. Suite cryptographique donnée à titre d'exemple : la CNIe l'annonce dans EF.CardAccess.
→ MSE:Set AT (choix du protocole et du mot de passe)
00 22 C1 A4 0F
80 0A 04 00 7F 00 07 02 02 04 02 02 -- OID id-PACE-ECDH-GM-AES-CBC-CMAC-128 (exemple)
83 01 02 -- référence du mot de passe : 02 = CAN
← 90 00
→ General Authenticate, étape 1 : demande du nonce chiffré
10 86 00 00 02 7C 00 00
← 7C 12 80 10 <z = E(Kπ, s), 16 octets> 90 00
→ étape 2 : mapping générique (clés éphémères de mapping)
10 86 00 00 45 7C 43 81 41 <PK_map,PCD : point P-256 non compressé> 00
← 7C 43 82 41 <PK_map,PICC> 90 00
→ étape 3 : accord de clés éphémères sur le générateur G' = s·G + H
10 86 00 00 45 7C 43 83 41 <PK_PCD> 00
← 7C 43 84 41 <PK_PICC> 90 00
→ étape 4 : jetons d'authentification mutuelle
00 86 00 00 0C 7C 0A 85 08 <T_PCD = MAC(KS_MAC, PK_PICC)> 00
← 7C 0A 86 08 <T_PICC = MAC(KS_MAC, PK_PCD)> 90 00Traitement
- La puce tire un nonce s et l'envoie chiffré sous Kπ ; seule une partie connaissant le CAN peut le déchiffrer.
- Le mapping générique dérive un nouveau générateur G' à partir de s et d'un secret Diffie-Hellman éphémère.
- Un second échange Diffie-Hellman sur G' donne le secret K, dont on dérive KS_Enc et KS_MAC.
- Chaque côté prouve qu'il a obtenu le même K en renvoyant un MAC de la clé publique éphémère de l'autre.
Sortie
Canal de messagerie sécurisée (ISO 7816-4 secure messaging).
KS_Enc, KS_MAC -- clés de session
SSC -- compteur de séquence
Toutes les commandes suivantes sont chiffrées (DO'87') et authentifiées (DO'8E').Suite : Toutes les lectures de données de l'étape suivante passent par ce canal : un observateur radio ne voit que du chiffré.
Lire les données d'identité et l'objet de sécurité
France Identité → Puce CNIe · Lecture EF.SOD, DG
Entrée
Commandes sous messagerie sécurisée (représentées ici en clair).
→ SELECT application eMRTD
00 A4 04 0C 07 A0 00 00 02 47 10 01
→ SELECT EF.DG1 00 A4 02 0C 02 01 01 → READ BINARY ...
→ SELECT EF.SOD 00 A4 02 0C 02 01 1D → READ BINARY ...
(+ les autres groupes de données nécessaires à l'usage)Traitement
- DG1 contient la zone de lecture automatique (MRZ, format TD1 : trois lignes de 30 caractères).
- EF.SOD contient l'objet de sécurité du document : la liste des condensats de chaque groupe de données, signée.
- La puce ne délivre ces fichiers qu'à travers le canal PACE.
Sortie
Structures lues (forme abrégée).
EF.DG1 :
61 5B 5F 1F 58 <MRZ TD1 : 3 lignes de 30 caractères>
-- type de document, État émetteur FRA, numéro, date de naissance,
-- sexe, date d'expiration, nationalité, noms et prénoms
EF.SOD : CMS SignedData {
eContent : LDSSecurityObject {
version 0,
hashAlgorithm id-sha256 (2.16.840.1.101.3.4.2.1),
dataGroupHashValues {
{ dataGroupNumber 1, dataGroupHashValue <SHA-256(DG1)> },
{ dataGroupNumber 2, dataGroupHashValue <SHA-256(DG2)> },
{ dataGroupNumber 14, dataGroupHashValue <SHA-256(DG14)> }, ...
}
}
certificates : { certificat du Document Signer }
signerInfos : { signature du Document Signer sur les attributs signés }
}Suite : Les condensats de EF.SOD permettent de vérifier chaque groupe de données lu, et la signature de EF.SOD permet de remonter à l'État émetteur.
Vérifier que les données ont été signées par l'État
France Identité → France Identité · Authentification passive
Entrée
EF.SOD, groupes de données lus, certificat CSCA France connu de l'application.
DG1, DG14, ... (octets lus)
EF.SOD (CMS SignedData)
CSCA FR (ancre de confiance, publiée par l'État et via l'ICAO PKD)Traitement
- Recalculer SHA-256 de chaque groupe de données lu et le comparer à la valeur inscrite dans LDSSecurityObject.
- Vérifier la signature CMS de EF.SOD avec la clé publique du certificat Document Signer.
- Vérifier que le certificat Document Signer est signé par la CSCA France et qu'il n'est pas révoqué (CRL de la CSCA).
Sortie
Résultat.
Authentification passive : OK
=> les données n'ont pas été modifiées depuis leur personnalisation par l'État.
=> limite : une copie exacte des fichiers sur une autre puce passerait aussi ce contrôle.Suite : Comme la copie n'est pas détectée, il faut prouver que la puce elle-même est authentique : c'est l'étape suivante.
Prouver que la puce est authentique
France Identité → Puce CNIe · Anti-clonage
Entrée
Clé publique de la puce, lue dans un groupe de données dont le condensat est déjà vérifié.
Chip Authentication : clé publique Diffie-Hellman de la puce dans DG14
Active Authentication : clé publique de signature de la puce dans DG15Traitement
- Chip Authentication : accord Diffie-Hellman entre la clé statique de la puce et une clé éphémère de l'application ; seule la vraie puce peut calculer le secret, et le canal est re-chiffré avec de nouvelles clés. La preuve n'est pas transférable à un tiers.
- Active Authentication : l'application envoie un défi aléatoire, la puce le signe avec sa clé privée de DG15.
- Dans les deux cas, la clé publique est authentifiée par l'étape précédente, puisque DG14 ou DG15 figure dans EF.SOD.
Sortie
Résultat.
Puce authentique : OK
La clé privée de la puce n'a jamais quitté le composant.Suite : Les données sont authentiques et proviennent d'une vraie puce : l'application peut créer l'identité numérique.
Créer l'identité numérique France Identité
France Identité → Serveurs France Identité · Création de l'identité
Entrée
Parcours public décrit par France Identité et FranceConnect.
1. Saisie du CAN et lecture NFC de la carte
2. Vérification de l'identité via FranceConnect ou par courrier recommandé (au choix)
3. Choix d'un code personnelTraitement
- L'application transmet aux serveurs de l'État les éléments nécessaires à la création de l'identité numérique.
- Une vérification complémentaire est faite par FranceConnect ou par courrier recommandé.
- Le format des messages et la nature exacte des données envoyées ne sont pas publiés.
Sortie
État de l'identité.
Identité numérique créée (non certifiée)
Utilisable sur FranceConnect, pas sur FranceConnect+Suite : Pour accéder aux démarches sensibles (FranceConnect+), l'identité doit être certifiée en mairie.
Certifier l'identité en mairie
Personne → Agent en mairie · QR code, face-à-face
Entrée
Parcours public de certification.
Dans l'application : confirmer l'adresse e-mail, saisir le code personnel,
relire la carte en NFC => l'application génère un QR code
En mairie : présentation du QR code et de la carte à un agentTraitement
- L'agent compare la personne présente au titre présenté : c'est le face-à-face, qui n'a pas d'équivalent cryptographique.
- Le QR code relie ce contrôle à l'identité numérique créée sur le téléphone.
- Depuis avril 2025, l'identité numérique peut aussi être créée à la remise de la carte en mairie ou en consulat.
Sortie
État de l'identité.
Identité numérique certifiée
=> accès à FranceConnect+ (niveaux eidas2 et eidas3 côté fédération)Suite : L'identité certifiée sert ensuite d'authentification forte auprès de FranceConnect+ (section 4) et sera la base d'un PID dans le portefeuille européen (section 2).
Sources
- France Identité, identité numérique certifiée
- FranceConnect, compte France Identité (création, certification)
- France Identité, authentification sans lecture de carte
- ICAO Doc 9303 partie 11 (PACE, Chip et Active Authentication) et BSI TR-03110 partie 3, normes de référence
02Activation du portefeuille et émission du PID
Spécifié, déploiement fin 2026
Protocoles finaux : OpenID4VCI 1.0 (16 septembre 2025), HAIP 1.0 (24 décembre 2025). Cadre juridique : règlements d'exécution (UE) 2024/2977 et 2024/2979, modifiés par (UE) 2026/1731 (en vigueur le 11 août 2026). Portefeuilles certifiés attendus au 24 décembre 2026.
Le portefeuille obtient de l'État des attestations d'identité (PID) liées à des clés qu'il détient dans un composant sécurisé. Chaque échange est conçu pour que l'émetteur sache qu'il parle à une instance de portefeuille certifiée et que les clés auxquelles il lie le PID ne peuvent pas être extraites.
Générer les clés liées aux futurs PID
Portefeuille → WSCD · Génération des clés
Entrée
Demande du portefeuille au composant sécurisé.
Générer N paires de clés ECDSA P-256 (une par exemplaire du lot de PID)
Usage : signature, non exportables, déverrouillage par authentification de l'utilisateurTraitement
- Le WSCD (élément sécurisé ou équivalent certifié) génère les paires de clés en interne.
- Les clés privées ne sortent jamais du composant ; seules les clés publiques sont exportées au format JWK.
- Le système d'exploitation peut fournir une attestation matérielle de ces clés, que le fournisseur de portefeuille vérifiera.
Sortie
Clés publiques (JWK).
[
{ "kty": "EC", "crv": "P-256", "x": "…", "y": "…" },
{ "kty": "EC", "crv": "P-256", "x": "…", "y": "…" }
]Suite : Ces clés publiques seront attestées par le fournisseur de portefeuille, puis inscrites par l'émetteur dans chaque PID (champ cnf).
Obtenir l'attestation d'instance et l'attestation de clés
Portefeuille → Fournisseur de portefeuille · Attestations
Entrée
Le portefeuille présente au fournisseur la preuve d'intégrité de l'appareil et les clés publiques.
Attestation de la plateforme (intégrité de l'application et de l'appareil)
Clés publiques générées à l'étape 1Traitement
- Le fournisseur vérifie l'intégrité de l'instance et la certification du WSCD.
- Il signe une attestation d'instance (Wallet Attestation, OpenID4VCI annexe E) qui servira d'authentification client OAuth.
- Il signe une attestation de clés (OpenID4VCI annexe D) listant les clés publiques et leur niveau de protection.
- HAIP impose que l'attestation d'instance ne contienne aucun identifiant propre à l'instance : son sub est commun à toutes les instances du même produit.
Sortie
Deux JWT décodés (exemple).
// Attestation d'instance (authentification client)
{ "typ": "oauth-client-attestation+jwt", "alg": "ES256", "x5c": ["MIIC…"] }
{
"iss": "https://wallet-provider.example.eu",
"sub": "eudi-wallet-fr-v1",
"iat": 1759478400,
"exp": 1759564800,
"cnf": { "jwk": { "kty": "EC", "crv": "P-256", "x": "…", "y": "…" } }
}
// Attestation de clés
{ "typ": "key-attestation+jwt", "alg": "ES256", "x5c": ["MIIC…"] }
{
"iss": "https://wallet-provider.example.eu",
"iat": 1759478400,
"exp": 1759564800,
"attested_keys": [ { "kty": "EC", "crv": "P-256", "x": "…", "y": "…" }, … ],
"key_storage": ["iso_18045_high"],
"user_authentication": ["iso_18045_high"],
"certification": "https://…/certificat-du-wscd"
}Suite : L'attestation d'instance authentifie le portefeuille auprès du serveur d'autorisation (étapes 4 et 6) ; l'attestation de clés accompagne la preuve de possession (étape 8).
Recevoir l'offre d'émission
Fournisseur de PID → Portefeuille · Offre d'attestation
Entrée
Offre transmise par lien ou QR code (flux à l'initiative de l'émetteur).
haip-vci://?credential_offer=%7B%22credential_issuer%22%3A…%7D
{
"credential_issuer": "https://pid.example.fr",
"credential_configuration_ids": ["pid_dc_sd_jwt", "pid_mso_mdoc"],
"grants": {
"authorization_code": { "issuer_state": "eyJhbGciOiJSU0Et…" }
}
}Traitement
- Le portefeuille récupère les métadonnées de l'émetteur (/.well-known/openid-credential-issuer) et du serveur d'autorisation.
- HAIP rend obligatoire la prise en charge du flux authorization_code par le portefeuille et l'émetteur.
- Le règlement 2024/2982 impose de demander le PID dans tous les formats proposés : ici SD-JWT VC et mdoc.
Sortie
Paramètres retenus.
issuer = https://pid.example.fr
configurations = pid_dc_sd_jwt, pid_mso_mdoc
issuer_state = eyJhbGciOiJSU0Et…Suite : Le portefeuille ouvre une demande d'autorisation poussée (PAR) en se présentant avec son attestation d'instance.
Pousser la demande d'autorisation
Portefeuille → Fournisseur de PID · PAR + PKCE
Entrée
Requête HTTP (RFC 9126), authentification client par attestation.
POST /par HTTP/1.1
Host: pid.example.fr
Content-Type: application/x-www-form-urlencoded
OAuth-Client-Attestation: eyJ0eXAiOiJvYXV0aC1jbGllbnQtYXR0ZXN0YXRpb24rand0Ii…
OAuth-Client-Attestation-PoP: eyJ0eXAiOiJvYXV0aC1jbGllbnQtYXR0ZXN0YXRpb24tcG9wK2p3dCI…
response_type=code
&client_id=eudi-wallet-fr-v1
&scope=pid_dc_sd_jwt%20pid_mso_mdoc
&code_challenge=E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM
&code_challenge_method=S256
&redirect_uri=https%3A%2F%2Fwallet.example.eu%2Fcb
&issuer_state=eyJhbGciOiJSU0Et…
&state=af0ifjsldkjTraitement
- Le serveur vérifie l'attestation d'instance (signature, chaîne x5c jusqu'à la liste des fournisseurs de portefeuille) et sa preuve de possession.
- Il conserve le code_challenge PKCE, condensat d'un secret que seul le portefeuille connaît.
- Il enregistre les paramètres et renvoie une référence opaque.
Sortie
Réponse.
HTTP/1.1 201 Created
{
"request_uri": "urn:ietf:params:oauth:request_uri:6esc_11ACC5bwc014ltc14eY22c",
"expires_in": 60
}Suite : Le portefeuille redirige l'utilisateur vers /authorize avec cette seule référence : les paramètres ne transitent plus par le navigateur.
Authentifier la personne auprès du fournisseur de PID
Personne → Fournisseur de PID · Authentification nationale
Entrée
Redirection vers l'autorisation.
GET /authorize?client_id=eudi-wallet-fr-v1
&request_uri=urn%3Aietf%3Aparams%3Aoauth%3Arequest_uri%3A6esc_11ACC5bwc014ltc14eY22cTraitement
- Le fournisseur de PID authentifie la personne avec un moyen d'identification électronique de niveau élevé (en France, la CNIe par exemple).
- Il affiche ce qui va être émis et recueille le consentement.
- Il émet un code d'autorisation à usage unique, lié au code_challenge.
Sortie
Retour vers le portefeuille.
HTTP/1.1 302 Found
Location: https://wallet.example.eu/cb?code=SplxlOBeZQQYbYS6WxSbIA
&state=af0ifjsldkj
&iss=https%3A%2F%2Fpid.example.frSuite : Le portefeuille vérifie state et iss (RFC 9207), puis échange le code contre un jeton lié à sa clé DPoP.
Obtenir un jeton d'accès lié à une clé
Portefeuille → Fournisseur de PID · Token + DPoP
Entrée
Requête au point de terminaison token.
POST /token HTTP/1.1
Host: pid.example.fr
Content-Type: application/x-www-form-urlencoded
OAuth-Client-Attestation: eyJ0eXAiOiJvYXV0aC1jbGllbnQtYXR0ZXN0YXRpb24rand0Ii…
OAuth-Client-Attestation-PoP: eyJ0eXAiOiJvYXV0aC1jbGllbnQtYXR0ZXN0YXRpb24tcG9wK2p3dCI…
DPoP: eyJ0eXAiOiJkcG9wK2p3dCIsImFsZyI6IkVTMjU2Iiwiandr…
grant_type=authorization_code
&code=SplxlOBeZQQYbYS6WxSbIA
&code_verifier=dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
&redirect_uri=https%3A%2F%2Fwallet.example.eu%2Fcb
// En-tête DPoP décodé
{ "typ": "dpop+jwt", "alg": "ES256", "jwk": { "kty": "EC", "crv": "P-256", "x": "…", "y": "…" } }
{ "jti": "-BwC3ESc6acc2lTc", "htm": "POST", "htu": "https://pid.example.fr/token", "iat": 1759478460 }Traitement
- Le serveur vérifie que BASE64URL(SHA-256(code_verifier)) est égal au code_challenge reçu en PAR.
- Il vérifie la preuve DPoP : signature par la clé jwk, méthode et URL, fraîcheur.
- Il émet un jeton d'accès lié à l'empreinte de cette clé : un jeton volé est inutilisable sans elle.
Sortie
Réponse.
{
"access_token": "Kz~8mXK1EalYznwH-LC-1fBAo.4Ljp~zsPE_NeO.gxU",
"token_type": "DPoP",
"expires_in": 300
}Suite : Le jeton DPoP autorise l'appel au point de terminaison credential, après récupération d'un nonce frais.
Obtenir un nonce pour la preuve de possession
Portefeuille → Fournisseur de PID · Nonce
Entrée
Requête.
POST /nonce HTTP/1.1
Host: pid.example.frTraitement
- L'émetteur génère une valeur aléatoire à usage unique ; HAIP rend ce point de terminaison obligatoire dès que les attestations sont liées à des clés.
Sortie
Réponse.
HTTP/1.1 200 OK
Cache-Control: no-store
{ "c_nonce": "wKI4LT17ac15ES9bw8ac4" }Suite : Le nonce est signé dans la preuve de possession : une preuve ancienne ne peut pas être rejouée.
Demander le PID avec preuve de possession
Portefeuille → Fournisseur de PID · Requête credential
Entrée
Requête et preuve décodée.
POST /credential HTTP/1.1
Host: pid.example.fr
Content-Type: application/json
Authorization: DPoP Kz~8mXK1EalYznwH-LC-1fBAo.4Ljp~zsPE_NeO.gxU
DPoP: eyJ0eXAiOiJkcG9wK2p3dCIs… (htu = …/credential, ath = SHA-256 du jeton)
{
"credential_configuration_id": "pid_dc_sd_jwt",
"proofs": { "jwt": [ "eyJ0eXAiOiJvcGVuaWQ0dmNpLXByb29mK2p3dCIs…" ] }
}
// Preuve décodée : signée dans le WSCD par une clé attestée
{ "typ": "openid4vci-proof+jwt", "alg": "ES256",
"jwk": { "kty": "EC", "crv": "P-256", "x": "…", "y": "…" },
"key_attestation": "eyJ0eXAiOiJrZXktYXR0ZXN0YXRpb24rand0Ii…" }
{ "aud": "https://pid.example.fr", "iat": 1759478470, "nonce": "wKI4LT17ac15ES9bw8ac4" }Traitement
- L'utilisateur déverrouille la clé dans le WSCD (PIN ou biométrie) pour signer la preuve.
- L'émetteur vérifie l'attestation de clés (signature, chaîne x5c, niveau iso_18045_high), puis que la clé de la preuve figure dans attested_keys.
- Il vérifie aud, iat et le nonce. Avec une attestation de clés, une seule preuve suffit : l'émetteur devrait émettre un exemplaire par clé attestée, dans la limite de sa taille de lot.
Sortie
Décision.
Clés à lier : attested_keys[0..n-1]
Format : dc+sd-jwt (puis mso_mdoc par une seconde requête)Suite : L'émetteur construit et signe un SD-JWT VC par clé.
Construire le PID au format SD-JWT VC
Fournisseur de PID → Fournisseur de PID · Construction SD-JWT VC
Entrée
Attributs du PID (règle PID de l'ARF, identifiant de type urn:eudi:pid:1).
family_name : "DUPONT"
given_name : "Camille"
birthdate : "1990-04-12"
nationalities : ["FR"]
+ métadonnées : issuing_authority, issuing_country, date d'expiration, statutTraitement
- Chaque attribut divulgable devient une divulgation : un tableau JSON [sel, nom, valeur], encodé en base64url.
- Le condensat SHA-256 de chaque divulgation encodée est placé dans le tableau _sd du JWT. Les valeurs ci-dessous sont réellement calculées.
- L'émetteur ajoute la clé publique du portefeuille dans cnf, un pointeur de liste de statut, et signe le JWT en ES256 avec son certificat dans x5c (exigence HAIP).
Sortie
JWT de l'émetteur et divulgations (valeurs de condensat calculées sur ces divulgations exactes).
// En-tête
{ "alg": "ES256", "typ": "dc+sd-jwt",
"x5c": ["MIIC…(certificat de signature du fournisseur de PID)", "MIIC…(AC intermédiaire)"] }
// Charge utile
{
"iss": "https://pid.example.fr",
"iat": 1759478480,
"exp": 1767225600,
"vct": "urn:eudi:pid:1",
"_sd_alg": "sha-256",
"_sd": [
"OxAyE-k0HohdXrCjOFh0lGISjvAvNTGA7RStoHkS5uo",
"QrHO3rDeFV-UD_NxWKSUa_4VKJoM1naxJH3AUTHELNQ",
"X8GtBRkhhNtoPq7Rw0EOo3bkv4X042nmtFXTBSxhOcc",
"7ik4-30XvbGwD_Zc7OaUbI8R4KfwNCa43H_3Q6wPjkQ"
],
"issuing_authority": "FR",
"issuing_country": "FR",
"cnf": { "jwk": { "kty": "EC", "crv": "P-256", "x": "…", "y": "…" } },
"status": { "status_list": { "idx": 41207, "uri": "https://pid.example.fr/statuslists/7" } }
}
// Divulgations : [sel, nom, valeur] => base64url => SHA-256 => entrée de _sd
["2GLC42sKQveCfGfryNRN9w", "family_name", "DUPONT"]
WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgImZhbWlseV9uYW1lIiwgIkRVUE9OVCJd
["eluV5Og3gSNII8EYnsxA_A", "given_name", "Camille"]
WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImdpdmVuX25hbWUiLCAiQ2FtaWxsZSJd
["6Ij7tM-a5iVPGboS5tmvVA", "birthdate", "1990-04-12"]
WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgImJpcnRoZGF0ZSIsICIxOTkwLTA0LTEyIl0
["eI8ZWm9QnKPpNPeNenHdhQ", "nationalities", ["FR"]]
WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgIm5hdGlvbmFsaXRpZXMiLCBbIkZSIl1dSuite : Le portefeuille stocke le JWT et toutes les divulgations ; il n'en révélera qu'une partie à chaque présentation.
Recevoir le lot de PID
Fournisseur de PID → Portefeuille · Réponse credential
Entrée
Réponse du point de terminaison credential.
HTTP/1.1 200 OK
Content-Type: application/json
{
"credentials": [
{ "credential": "eyJhbGciOiJFUzI1NiIsInR5cCI6ImRjK3NkLWp3dCIs…~WyIyR0xD…~WyJlbHVW…~WyI2SWo3…~WyJlSTha…~" },
{ "credential": "eyJhbGciOiJFUzI1NiIsInR5cCI6ImRjK3NkLWp3dCIs…~…~" }
],
"notification_id": "3fwe98js"
}Traitement
- Le portefeuille vérifie la signature de chaque exemplaire et que cnf correspond bien à l'une de ses clés.
- Chaque exemplaire porte un sel et un index de statut différents : présentés à des services distincts, ils ne sont pas corrélables par leurs valeurs techniques.
- Le portefeuille inscrit l'émission dans son journal de transactions.
Sortie
État du portefeuille.
n exemplaires de PID SD-JWT VC, chacun lié à une clé distincte du WSCD
+ exemplaires mdocSuite : Le portefeuille peut présenter ce PID à un service (section 3) ; chaque exemplaire n'est utilisé qu'une fois pour limiter la corrélation entre services.
Sources
- OpenID for Verifiable Credential Issuance 1.0
- OpenID4VC High Assurance Interoperability Profile 1.0
- RFC 9901, Selective Disclosure for JWTs
- ARF, annexe 3.01, règle PID (urn:eudi:pid:1, eu.europa.ec.eudi.pid.1)
- Règlement d'exécution (UE) 2024/2977 (PID et attestations)
- Règlement d'exécution (UE) 2024/2982 (protocoles et interfaces)
- Règlement d'exécution (UE) 2026/1731 du 15 juillet 2026 (JO du 22 juillet ; mise à jour des normes du portefeuille)
- iGrant.io, comparaison OpenID4VCI 1.0 et TS3 v1.5
03Identification auprès d'un service avec le portefeuille
Spécifié, déploiement fin 2026
Protocole final : OpenID4VP 1.0 (9 juillet 2025), profilé par HAIP 1.0. Enregistrement des parties utilisatrices : règlement d'exécution (UE) 2025/848 ; la validation des certificats d'enregistrement par le portefeuille est différée au 11 août 2028 par le règlement 2026/1731.
Le service demande des attributs précis, le portefeuille vérifie qui demande, l'utilisateur consent, et le portefeuille ne révèle que les attributs demandés, liés à la transaction par une signature de sa clé. Flux représenté : HAIP, redirection sur le même appareil.
Construire la demande signée (JAR)
Service utilisateur → Service utilisateur · Requête signée
Entrée
Ce que le service veut savoir, et ce qui l'identifie.
Attributs nécessaires : nom, prénom, date de naissance
Identité du service : certificat d'accès X.509 délivré dans le cadre de l'enregistrementTraitement
- Le service génère un nonce aléatoire, un state et une clé éphémère P-256 pour chiffrer la réponse.
- Il exprime sa demande en DCQL : la nationalité n'étant pas demandée, elle ne sera pas divulguée.
- Il signe l'objet de requête avec la clé de son certificat d'accès ; HAIP impose le préfixe x509_hash, condensat SHA-256 du certificat.
Sortie
Objet de requête décodé.
{ "typ": "oauth-authz-req+jwt", "alg": "ES256",
"x5c": ["MIIC…(certificat d'accès du service)", "MIIC…(AC d'accès)"] }
{
"client_id": "x509_hash:Uvo3HtuIxuhC92rShpgqcT3YXwrqRxWEviRiA0OZszk",
"aud": "https://self-issued.me/v2",
"response_type": "vp_token",
"response_mode": "direct_post.jwt",
"response_uri": "https://verifier.example.fr/post",
"nonce": "n-0S6_WzA2Mj",
"state": "eyJhb…6-sVA",
"wallet_nonce": "qPmxiNFCR3QTm19POc8u",
"dcql_query": {
"credentials": [ {
"id": "pid",
"format": "dc+sd-jwt",
"meta": { "vct_values": ["urn:eudi:pid:1"] },
"claims": [
{ "path": ["family_name"] },
{ "path": ["given_name"] },
{ "path": ["birthdate"] }
]
} ]
},
"client_metadata": {
"jwks": { "keys": [ { "kty": "EC", "crv": "P-256", "x": "…", "y": "…",
"use": "enc", "alg": "ECDH-ES", "kid": "ac-1" } ] },
"encrypted_response_enc_values_supported": ["A128GCM", "A256GCM"],
"vp_formats_supported": { "dc+sd-jwt": { "sd-jwt_alg_values": ["ES256"],
"kb-jwt_alg_values": ["ES256"] } }
}
}Suite : La requête est déposée derrière une request_uri : le portefeuille viendra la chercher.
Invoquer le portefeuille et récupérer la requête
Navigateur du service → Portefeuille · Invocation
Entrée
Lien d'invocation puis requête du portefeuille.
haip-vp://?client_id=x509_hash%3AUvo3HtuIxuhC92rShpgqcT3YXwrqRxWEviRiA0OZszk
&request_uri=https%3A%2F%2Fverifier.example.fr%2Frequest%2Fvapof4ql2i7m41m68uep
&request_uri_method=post
POST /request/vapof4ql2i7m41m68uep HTTP/1.1
Host: verifier.example.fr
Content-Type: application/x-www-form-urlencoded
Accept: application/oauth-authz-req+jwt
wallet_metadata=%7B%22vp_formats_supported%22%3A…%7D&wallet_nonce=qPmxiNFCR3QTm19POc8uTraitement
- Le navigateur ouvre le portefeuille (schéma haip-vp://, lien https revendiqué, ou API Digital Credentials du navigateur).
- Le portefeuille envoie ses capacités et un nonce à lui, pour empêcher le rejeu d'une requête ancienne.
Sortie
Réponse du service.
HTTP/1.1 200 OK
Content-Type: application/oauth-authz-req+jwt
eyJ0eXAiOiJvYXV0aC1hdXRoei1yZXErand0IiwiYWxnIjoiRVMyNTYiLCJ4NWMiOlsi…Suite : Le portefeuille doit maintenant établir qui est ce service avant de montrer quoi que ce soit à l'utilisateur.
Vérifier l'identité du service
Portefeuille → Portefeuille · Contrôle du service
Entrée
Objet de requête signé.
En-tête x5c : [certificat d'accès, AC d'accès]
client_id : x509_hash:Uvo3HtuIxuhC92rShpgqcT3YXwrqRxWEviRiA0OZszkTraitement
- Vérifier typ = oauth-authz-req+jwt, sinon rejet.
- Calculer BASE64URL(SHA-256(DER du certificat feuille)) et le comparer au client_id après le préfixe.
- Vérifier la signature avec la clé du certificat feuille et la chaîne jusqu'à une ancre de la liste des fournisseurs de certificats d'accès.
- Vérifier que client_id est identique dans l'URL et dans l'objet, et que wallet_nonce est celui envoyé.
Sortie
Écran de consentement (contenu).
Service : <nom figurant dans le certificat d'accès>
Demande : nom, prénom, date de naissance (issus de votre PID)
Non demandé : nationalitéSuite : L'utilisateur accepte et déverrouille la clé liée au PID.
Construire la présentation et la lier à la transaction
Portefeuille → WSCD · KB-JWT
Entrée
Divulgations retenues et paramètres de la requête.
JWT émetteur : eyJhbGciOiJFUzI1NiIsInR5cCI6ImRjK3NkLWp3dCIs…
Divulgations retenues : family_name, given_name, birthdate (nationalities exclue)
aud = x509_hash:Uvo3HtuIxuhC92rShpgqcT3YXwrqRxWEviRiA0OZszk
nonce = n-0S6_WzA2MjTraitement
- Assembler le SD-JWT présenté : JWT émetteur, puis les trois divulgations retenues, séparés par ~.
- Calculer sd_hash = BASE64URL(SHA-256) de cette chaîne, tilde final compris.
- Faire signer par le WSCD le KB-JWT (Key Binding) avec la clé dont la publique figure dans cnf. aud et nonce rattachent la preuve à ce service et à cette transaction.
Sortie
KB-JWT décodé et vp_token.
{ "typ": "kb+jwt", "alg": "ES256" }
{
"iat": 1759482000,
"aud": "x509_hash:Uvo3HtuIxuhC92rShpgqcT3YXwrqRxWEviRiA0OZszk",
"nonce": "n-0S6_WzA2Mj",
"sd_hash": "<BASE64URL(SHA-256(JWT~d1~d2~d3~))>"
}
vp_token = {
"pid": [ "eyJhbGci…~WyIyR0xDNDJz…~WyJlbHVWNU9n…~WyI2SWo3dE0t…~eyJ0eXAiOiJrYitqd3QiLCJhbGci…" ]
}Suite : La réponse est chiffrée pour le seul service avant d'être envoyée.
Envoyer la réponse chiffrée
Portefeuille → Service utilisateur · direct_post.jwt
Entrée
Contenu à chiffrer.
{ "vp_token": { "pid": ["eyJhbGci…~…~eyJ0eXAiOiJrYitqd3Qi…"] }, "state": "eyJhb…6-sVA" }Traitement
- Accord ECDH-ES entre une clé éphémère du portefeuille et la clé ac-1 du service, sur P-256.
- Chiffrement A256GCM ; le résultat est un JWE compact, non signé (la signature est déjà dans le KB-JWT).
- Envoi en POST au response_uri, paramètre response.
Sortie
Requête et réponse.
// En-tête JWE
{ "alg": "ECDH-ES", "enc": "A256GCM", "kid": "ac-1",
"epk": { "kty": "EC", "crv": "P-256", "x": "…", "y": "…" } }
POST /post HTTP/1.1
Host: verifier.example.fr
Content-Type: application/x-www-form-urlencoded
response=eyJhbGciOiJFQ0RILUVTIiwiZW5jIjoiQTI1NkdDTSIsImtpZCI6ImFjLTEi…
HTTP/1.1 200 OK
Content-Type: application/json
{ "redirect_uri": "https://verifier.example.fr/cb#response_code=091535f699ea575c7937fa5f0f454aee" }Suite : Le service valide la présentation ; le portefeuille suit la redirection pour rattacher le résultat à la session d'origine.
Valider la présentation
Service utilisateur → Service utilisateur · Validation
Entrée
JWE reçu.
response = eyJhbGciOiJFQ0RILUVTIi…Traitement
- Déchiffrer avec la clé éphémère ac-1, puis vérifier state.
- JWT émetteur : vérifier ES256 avec la clé du certificat x5c et la chaîne jusqu'à la liste de confiance des fournisseurs de PID ; vérifier vct, exp.
- Divulgations : recalculer SHA-256 de chacune et vérifier sa présence dans _sd.
- KB-JWT : vérifier la signature avec cnf.jwk, puis aud = client_id du service, nonce = celui de la session, sd_hash recalculé, iat récent.
- Statut : récupérer la liste de statut et lire le bit à l'index 41207.
Sortie
Liste de statut (jeton décodé) et résultat.
{ "typ": "statuslist+jwt", "alg": "ES256", "x5c": ["MIIC…"] }
{
"sub": "https://pid.example.fr/statuslists/7",
"iat": 1759478400,
"exp": 1759564800,
"ttl": 43200,
"status_list": { "bits": 1, "lst": "eNrt3AENwCAMAEGWzbeCNb…" }
}
// lst : tableau de bits compressé (zlib). Bit à l'index 41207 : 0 = VALID, 1 = INVALID
Résultat : family_name = DUPONT, given_name = Camille, birthdate = 1990-04-12
Émetteur : fournisseur de PID inscrit sur la liste de confiance, attestation non révoquéeSuite : Le service ne libère le résultat qu'à la session qui présente le response_code reçu par redirection.
Rattacher le résultat à la bonne session
Portefeuille → Navigateur du service · Redirection
Entrée
Redirection suivie par le portefeuille.
GET /cb#response_code=091535f699ea575c7937fa5f0f454aee HTTP/1.1
Host: verifier.example.frTraitement
- Le navigateur de l'utilisateur transmet le response_code à l'interface du service.
- Le service vérifie que ce code correspond à la session qui a initié la demande ; sinon il rejette la présentation (exigence HAIP contre la fixation de session et le relais).
Sortie
Résultat.
Session authentifiée avec les trois attributs vérifiésSuite : Le portefeuille journalise la transaction : date, service, données demandées et partagées (considérant 13 du règlement 2024/1183).
Sources
- OpenID for Verifiable Presentations 1.0
- OpenID4VC High Assurance Interoperability Profile 1.0
- Règlement d'exécution (UE) 2024/2982 (protocoles et interfaces)
- Règlement d'exécution (UE) 2026/1731, article 4 (certificats d'enregistrement : application au 11 août 2028)
- iGrant.io, synthèse du règlement 2026/1731
- lawandtechnology.eu, calendrier des actes d'exécution
04Identification en production aujourd'hui : FranceConnect+
En production
Flux OpenID Connect en production, documenté par la DINUM. Les exemples reprennent la documentation partenaires ; les valeurs propres à FranceConnect+ (acr, iss) sont adaptées et signalées.
Avant le portefeuille, l'identification de niveau substantiel ou élevé passe en France par la fédération FranceConnect+. La différence de modèle est nette : ici, c'est la fédération qui signe une assertion sur l'utilisateur ; l'utilisateur ne signe rien lui-même.
Demander une authentification de niveau substantiel
Fournisseur de service → FranceConnect+ · authorize
Entrée
Requête d'autorisation (flux code, seul flux implémenté).
GET /api/v2/authorize?response_type=code
&acr_values=eidas2
&scope=openid%20given_name%20family_name%20birthdate%20birthplace%20birthcountry%20gender
&client_id=<CLIENT_ID>
&redirect_uri=https%3A%2F%2Ffs.example.fr%2Foidc-callback
&state=6f9986e85da4f2855defbbbae9eb6ef53dc0e9d06f95426c014edfde2787e31d
&nonce=3441bb3a2c2c41a070d9200aa78b389c5d477a4787a4b479170819d55f7f8df2 HTTP/1.1
Host: auth.franceconnect.gouv.frTraitement
- acr_values = eidas2 (substantiel) ou eidas3 (élevé) ; eidas1 renvoie une erreur sur FranceConnect+.
- state protège contre le CSRF, nonce contre le rejeu : tous deux aléatoires, d'au moins 32 caractères.
Sortie
Réponse.
HTTP/1.1 303 See Other
Location: /api/v2/interaction/{interactionHash} -- choix du fournisseur d'identitéSuite : L'usager choisit son fournisseur d'identité, par exemple France Identité.
S'authentifier avec France Identité
Personne → Fournisseur d'identité · Authentification
Entrée
Parcours public.
1. Choisir France Identité
2. Scanner le QR code avec l'application
3. Saisir le code personnel
4. Lire la carte en NFC (requis pour certains services FranceConnect+)Traitement
- L'application déverrouille l'identité certifiée et, si demandé, relit la puce de la carte (section 1).
- Le fournisseur d'identité renvoie à FranceConnect+ le niveau réellement atteint.
Sortie
Résultat transmis à la fédération.
Identité de niveau substantiel, avec la méthode d'authentification utiliséeSuite : FranceConnect+ redirige l'usager vers le fournisseur de service avec un code.
Recevoir le code d'autorisation
FranceConnect+ → Fournisseur de service · code
Entrée
Redirection.
GET /oidc-callback?code=EIkPNC7db4tziWvGJvKQFaYFAjCEV0YBqbl9Im9xhpD
&state=6f9986e85da4f2855defbbbae9eb6ef53dc0e9d06f95426c014edfde2787e31d HTTP/1.1
Host: fs.example.frTraitement
- Le fournisseur de service vérifie que state est celui de sa session.
Sortie
code à usage unique, à échanger côté serveurSuite : Échange du code contre l'id_token, de serveur à serveur.
Échanger le code contre l'id_token
Fournisseur de service → FranceConnect+ · token
Entrée
Requête.
POST /api/v2/token HTTP/1.1
Host: auth.franceconnect.gouv.fr
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code&client_id=<CLIENT_ID>&client_secret=<CLIENT_SECRET>
&redirect_uri=https%3A%2F%2Ffs.example.fr%2Foidc-callback&code=EIkPNC7db4tziWvGJvKQFaYFAjCEV0YBqbl9Im9xhpDTraitement
- FranceConnect+ récupère la clé publique de chiffrement du fournisseur de service (URL JWKS déclarée).
- Il signe l'id_token en ES256, puis le chiffre (RSA-OAEP-256 ou ECDH-ES, avec AES-256-GCM) : JWE contenant un JWS.
Sortie
Réponse (id_token chiffré).
{
"access_token": "goSq0H6mF__-FqxLyD0z13SAtq9-D-LNJ489Znua2Qa",
"expires_in": 60,
"id_token": "eyJhbGciOiJSU0EtT0FFUC0yNTYiLCJlbmMiOiJBMjU2R0NNIi…",
"scope": "openid given_name family_name birthdate birthplace birthcountry gender",
"token_type": "Bearer"
}Suite : Le fournisseur de service déchiffre, puis vérifie la signature.
Déchiffrer et vérifier l'id_token
Fournisseur de service → Fournisseur de service · Vérification
Entrée
JWE reçu, clés JWKS de FranceConnect+ (régulièrement renouvelées).
GET https://auth.franceconnect.gouv.fr/api/v2/jwksTraitement
- Déchiffrer le JWE avec la clé privée du fournisseur de service.
- Vérifier la signature ES256 avec la clé désignée par kid dans les JWKS.
- Vérifier iss, aud = client_id, nonce = celui envoyé, exp.
- Vérifier que acr est au moins égal au niveau demandé (eidas3 est accepté si eidas2 était demandé).
Sortie
JWS décodé (exemple ; acr et iss adaptés à FranceConnect+).
{ "alg": "ES256", "typ": "JWT", "kid": "sign_20211013_e6e32b46" }
{
"sub": "739d6f6a14be39575ec3745bdcf8aec44d687b752b47054196d15ae4d7a7b2c6v1",
"auth_time": 1759482000,
"acr": "eidas2",
"nonce": "3441bb3a2c2c41a070d9200aa78b389c5d477a4787a4b479170819d55f7f8df2",
"aud": "<CLIENT_ID>",
"exp": 1759482060,
"iat": 1759482000,
"iss": "https://auth.franceconnect.gouv.fr/api/v2"
}Suite : Avec l'access_token, le fournisseur de service récupère les attributs d'identité.
Récupérer l'identité pivot
Fournisseur de service → FranceConnect+ · userinfo
Entrée
Requête.
GET /api/v2/userinfo HTTP/1.1
Host: auth.franceconnect.gouv.fr
Authorization: Bearer goSq0H6mF__-FqxLyD0z13SAtq9-D-LNJ489Znua2QaTraitement
- Réponse application/jwt : JWE à déchiffrer, puis JWS ES256 à vérifier, comme l'id_token.
Sortie
Charge utile décodée (valeurs de la documentation partenaires).
{
"sub": "f5b288566867cb435099290b879ea20f5c89ed0a106a99ae050a94f60c369802v1",
"gender": "female",
"birthdate": "1962-08-24",
"birthcountry": "99100",
"birthplace": "75107",
"given_name": "Angela Claire Louise",
"given_name_array": ["Angela", "Claire", "Louise"],
"family_name": "DUBOIS",
"aud": "<CLIENT_ID>",
"iss": "https://auth.franceconnect.gouv.fr/api/v2",
"iat": 1759482010,
"exp": 1759482070
}Suite : Ces champs forment l'identité pivot, que le service ne doit pas laisser modifier.
05Identification, authentification, signature : ce que chacune produit
Cadre et définitions
Trois opérations voisines utilisent les mêmes primitives mais ne produisent pas la même chose. La différence tient à ce qui est signé, par qui, et à ce que la trace permet de prouver à un tiers.
Trois opérations, trois résultats
| Opération | Ce qui est établi | Matériel utilisé | Ce qui est signé | Preuve transférable à un tiers | Exemple sur cette page |
|---|---|---|---|---|---|
| Identification | Qui est la personne : attributs liés à une personne réelle | Attestation signée par un émetteur (PID) ou assertion d'une fédération | Les attributs, par l'émetteur | Oui, la signature de l'émetteur | Section 3 (PID), section 4 (userinfo) |
| Authentification | Que le détenteur légitime est présent maintenant | Clé privée de l'utilisateur ou de son dispositif, débloquée par PIN ou biométrie | Un défi frais (nonce), lié au destinataire | Selon le protocole : oui avec une signature de défi (KB-JWT), non avec Chip Authentication ou un MAC | Section 3 (KB-JWT), section 1 (anti-clonage) |
| Signature | Que la personne s'engage sur un contenu | Clé de signature avec certificat d'usage contentCommitment | Le condensat d'un document | Oui, c'est son objet | Sections 7 et 8 |
Niveaux de garantie des moyens d'identification
Les niveaux sont définis par le règlement d'exécution (UE) 2015/1502 : ils portent sur l'enrôlement, la gestion du moyen, l'authentification et l'organisation de l'émetteur. FranceConnect les expose dans le claim acr.
| Niveau eIDAS | Valeur acr FranceConnect | Plateforme | Exemple de moyen |
|---|---|---|---|
| Faible | eidas1 | FranceConnect | Comptes des fournisseurs d'identité historiques |
| Substantiel | eidas2 | FranceConnect+ | France Identité avec identité certifiée |
| Élevé | eidas3 | FranceConnect+ | Moyens proposés pour le niveau élevé ; seuls ceux-ci sont présentés quand eidas3 est demandé |
Le point qui sépare authentification et signature
Les deux opérations peuvent utiliser la même primitive ECDSA. Si une même clé servait aux deux, un service malveillant pourrait présenter comme défi d'authentification le condensat d'un contrat. D'où la séparation des clés et des usages de certificat : la carte d'identité estonienne, par exemple, porte une clé d'authentification (PIN1) et une clé de signature (PIN2) distinctes, et le portefeuille européen ne signe des documents que via un parcours de signature qualifiée dédié.
06Signature électronique simple, telle que pratiquée par le marché
En production
Pratique courante des plateformes. Le dossier de preuve est dans un format propriétaire propre à chaque prestataire : il n'est montré que dans sa structure. Le cachet final, lui, est un PAdES normalisé.
Le parcours décrit ici (invitation, code à usage unique, consentement, journal horodaté, cachet de la plateforme) est une pratique courante du marché, pas une exigence juridique. Au sens de l'article 3, point 10, du règlement eIDAS, une signature électronique simple désigne des données sous forme électronique jointes ou associées logiquement à d'autres données, que le signataire utilise pour signer. Sa valeur probante dépend des éléments de preuve qui l'accompagnent. Ce qui fait la valeur probatoire d'une signature simple, ce n'est pas l'image apposée mais le dossier de preuve constitué autour, et le cachet électronique du prestataire qui scelle le document final.
Figer le document à signer
Plateforme de signature → Plateforme de signature · Empreinte
Entrée
Document déposé par l'émetteur.
contrat-2026-118.pdfTraitement
- La plateforme calcule l'empreinte SHA-256 du document et l'enregistre.
Sortie
SHA-256(contrat-2026-118.pdf) = <32 octets>Suite : Cette empreinte permettra de démontrer que le document signé est celui présenté.
Identifier faiblement le signataire
Plateforme de signature → Signataire · Invitation, OTP
Entrée
Canaux utilisés.
Lien unique envoyé par e-mail
Code à usage unique envoyé par SMS au numéro fourni par l'émetteurTraitement
- Le lien prouve l'accès à la boîte de messagerie, le code l'accès au téléphone.
- Aucune vérification d'identité officielle n'est faite à ce niveau.
Sortie
Événements journalisés : envoi, ouverture, saisie correcte du codeSuite : Le signataire consulte le document et clique pour signer.
Recueillir l'acte de signature
Signataire → Plateforme de signature · Consentement
Entrée
Action de l'utilisateur.
Case « J'ai lu et j'accepte » + clic « Signer »Traitement
- La plateforme horodate l'événement et l'associe à l'empreinte du document, à l'adresse IP, au navigateur et au code validé.
Sortie
Dossier de preuve (structure ; format propriétaire, illustratif).
{
"document_sha256": "…",
"signer": { "email": "…", "phone": "+33 6 …" },
"events": [
{ "t": "2026-10-03T08:10:02Z", "type": "invitation_sent" },
{ "t": "2026-10-03T08:12:40Z", "type": "otp_validated" },
{ "t": "2026-10-03T08:13:05Z", "type": "consent", "ip": "…", "user_agent": "…" }
]
}Suite : La plateforme scelle le document final.
Sceller le document final
Plateforme de signature → Autorité d'horodatage · Cachet + horodatage
Entrée
Document avec l'apparence visuelle de signature.
PDF final + certificat de cachet électronique de la plateforme (personne morale)Traitement
- La plateforme appose un cachet PAdES avec son propre certificat (QcType eseal si qualifié), mécaniquement identique à la signature de la section 7.
- Elle obtient un jeton d'horodatage RFC 3161 (section 9).
Sortie
Résultat.
PDF scellé par la plateforme
=> intégrité du document depuis le scellement : prouvée cryptographiquement
=> lien entre la personne et le document : prouvé seulement par le dossier de preuveSuite : En cas de contestation, c'est ce dossier que le juge examine.
07Signature avancée : construire une signature PAdES B-B
En production
Formats normalisés et implémentés par tous les outils de signature européens : ETSI EN 319 142-1 (PAdES), CMS (RFC 5652), ESS (RFC 5035). Algorithmes : ETSI TS 119 312 V2.1.1.
À format PAdES équivalent, une signature qualifiée est une signature avancée qui repose en outre sur un certificat qualifié et qui est créée au moyen d'un dispositif de création de signature qualifié (QSCD). Elle reste soumise aux exigences de l'article 26 : lien univoque avec le signataire, capacité à l'identifier, création à l'aide de données que le signataire peut utiliser sous son contrôle exclusif, et détection de toute modification ultérieure des données signées. Cette section construit la structure, octet par octet, avec un jeton personnel.
Réserver la place de la signature
Application de signature → Application de signature · Préparer le PDF
Entrée
PDF d'origine.
contrat-2026-118.pdf (révision 1)Traitement
- Ajouter une mise à jour incrémentale contenant un champ de signature et un dictionnaire de signature.
- Réserver /Contents : 8 192 octets à zéro, soit 16 384 chiffres hexadécimaux entre chevrons.
- Calculer /ByteRange : tout le fichier sauf la valeur de /Contents.
Sortie
Dictionnaire de signature.
12 0 obj
<< /Type /Sig
/Filter /Adobe.PPKLite
/SubFilter /ETSI.CAdES.detached
/ByteRange [0 840 17226 1530]
/Contents <0000000000…0000> % 16 384 chiffres hex réservés
/M (D:20261003101500+02'00') % heure revendiquée : dans le PDF, pas dans le CMS
/Name (Camille DUPONT)
/Reason (Accord sur le contrat 2026-118)
>>
endobj
% octets 840 à 17225 : '<' + 16 384 hex + '>' (17226 - 840 = 16 386)Suite : Le condensat porte sur les deux plages d'octets : [0, 840[ et [17226, 18756[.
Calculer le condensat du document
Application de signature → Application de signature · messageDigest
Entrée
Les deux plages /ByteRange.
octets [0 .. 839] || octets [17226 .. 18755]Traitement
- SHA-256 sur la concaténation des deux plages.
- C'est ce condensat qui lie la signature au document ; tout octet modifié hors /Contents change la valeur.
Sortie
messageDigest = SHA-256(plages) = <32 octets>Suite : Le condensat est placé dans les attributs signés.
Construire les attributs signés
Application de signature → Application de signature · signedAttrs
Entrée
Condensat et certificat du signataire.
messageDigest
certificat du signataire (DER)Traitement
- contentType = id-data.
- messageDigest = condensat de l'étape précédente.
- signingCertificateV2 = SHA-256 du certificat du signataire : empêche de substituer un autre certificat portant la même clé.
- Pas d'attribut signingTime : en PAdES, l'heure revendiquée est dans /M.
- Encodage DER de l'ensemble avec l'étiquette SET (0x31) : c'est ce bloc qui est signé, pas le document.
Sortie
Attributs signés (notation ASN.1).
SET {
SEQUENCE { -- contentType
OBJECT IDENTIFIER 1.2.840.113549.1.9.3
SET { OBJECT IDENTIFIER 1.2.840.113549.1.7.1 } -- id-data
}
SEQUENCE { -- messageDigest
OBJECT IDENTIFIER 1.2.840.113549.1.9.4
SET { OCTET STRING <SHA-256 des plages ByteRange> }
}
SEQUENCE { -- signingCertificateV2 (RFC 5035)
OBJECT IDENTIFIER 1.2.840.113549.1.9.16.2.47
SET { SEQUENCE { SEQUENCE { SEQUENCE { -- SigningCertificateV2 / certs / ESSCertIDv2
OCTET STRING <SHA-256 du certificat> -- hashAlgorithm omis : SHA-256 par défaut
SEQUENCE { <issuer>, <serialNumber> } -- IssuerSerial
} } } }
}
}Suite : Le condensat SHA-256 de ce bloc DER est envoyé au jeton pour signature.
Activer la clé avec le PIN
Signataire → Jeton ou carte · PIN
Entrée
Interface PKCS#11 côté poste.
C_OpenSession(slot, CKF_SERIAL_SESSION, …, &hSession)
C_Login(hSession, CKU_USER, "<PIN>", len)Traitement
- Le PIN est vérifié par le jeton lui-même ; après un petit nombre d'échecs, le jeton se bloque.
- La clé privée n'est utilisable que dans cette session authentifiée.
Sortie
Session authentifiée : CKR_OKSuite : Le logiciel demande la signature du condensat.
Signer le condensat dans le jeton
Application de signature → Jeton ou carte · C_Sign
Entrée
Appel PKCS#11.
h = SHA-256(DER(signedAttrs)) -- 32 octets, calculés sur le poste
C_SignInit(hSession, { CKM_ECDSA }, hPrivateKey)
C_Sign(hSession, h, 32, sig, &sigLen)Traitement
- Le jeton calcule une signature ECDSA P-256 sur h avec la clé privée qui ne le quitte jamais.
- PKCS#11 renvoie la signature brute r || s (64 octets).
- Le logiciel la réencode en ECDSA-Sig-Value DER pour CMS.
Sortie
r || s (64 octets) => SEQUENCE { INTEGER r, INTEGER s } -- environ 70 à 72 octets en DERSuite : La signature est intégrée à la structure CMS.
Assembler le CMS et l'insérer dans le PDF
Application de signature → Application de signature · CMS → /Contents
Entrée
Signature, attributs signés, certificats.
signedAttrs, signature DER, certificat du signataire, certificat de l'ACTraitement
- Construire le SignedData détaché (le document n'est pas copié dans le CMS).
- Encoder en DER, convertir en hexadécimal et écrire dans la zone /Contents réservée, sans changer la longueur du fichier.
Sortie
Structure CMS (RFC 5652).
ContentInfo {
contentType 1.2.840.113549.1.7.2 -- signedData
content [0] SignedData {
version 1
digestAlgorithms { 2.16.840.1.101.3.4.2.1 } -- sha256
encapContentInfo { eContentType 1.2.840.113549.1.7.1 } -- détaché : pas d'eContent
certificates [0] { <certificat du signataire>, <certificat de l'AC> }
signerInfos {
SignerInfo {
version 1
sid issuerAndSerialNumber { <issuer>, <serialNumber> }
digestAlgorithm 2.16.840.1.101.3.4.2.1
signedAttrs [0] { contentType, messageDigest, signingCertificateV2 }
signatureAlgorithm 1.2.840.10045.4.3.2 -- ecdsa-with-SHA256
signature OCTET STRING <ECDSA-Sig-Value DER>
-- unsignedAttrs : vide au niveau B-B (le niveau B-T y ajoutera l'horodatage)
}
}
}
}Suite : Le fichier est une signature PAdES B-B. Sa qualification dépend du certificat et du dispositif, pas de cette structure.
Sources
- ETSI TS 119 312 V2.1.1 (2026-06), suites cryptographiques
- ETSI EN 319 142-1, PAdES (référencée par TS 119 312)
- RFC 5652, Cryptographic Message Syntax
- RFC 5035, ESS signingCertificateV2
08Signature qualifiée à distance (API Cloud Signature Consortium)
En production
API CSC v2 (2.0.0.2 et 2.1) utilisée par les prestataires qualifiés ; dispositif distant certifié selon EN 419 241-2 (SAM) et EN 419 221-5 (HSM). Le déclenchement depuis le portefeuille européen est spécifié par l'ARF et en cours de déploiement.
La clé du titulaire est dans le HSM du prestataire. Le contrôle exclusif repose sur le module d'activation (SAM), qui ne libère la clé que sur présentation de données d'activation liées au condensat que le titulaire a autorisé.
Prérequis : la clé et le certificat qualifié
Service de signature du QTSP → Service de signature du QTSP · Certificat qualifié
Entrée
Émission préalable, après vérification d'identité (ETSI TS 119 461).
Clé ECDSA P-256 générée dans le HSM, sous contrôle du SAM
Certificat qualifié émis par l'AC qualifiée du prestataireTraitement
- La paire de clés est générée dans le HSM et associée au titulaire par le SAM.
- Le certificat porte les marqueurs qui permettront au validateur de reconnaître une QES.
Sortie
Extensions du certificat (extrait).
Subject: C=FR, GN=Camille, SN=DUPONT, CN=Camille DUPONT, serialNumber=<identifiant>
Subject Public Key Info: id-ecPublicKey, prime256v1 (P-256)
X509v3 Key Usage: critical
Non Repudiation (contentCommitment)
X509v3 Certificate Policies:
Policy: 0.4.0.194112.1.2 -- QCP-n-qscd (EN 319 411-2)
Policy: <OID de la politique du prestataire>
qcStatements (1.3.6.1.5.5.7.1.3):
0.4.0.1862.1.1 -- QcCompliance : certificat qualifié UE
0.4.0.1862.1.4 -- QcSSCD : clé dans un QSCD
0.4.0.1862.1.6 QcType = 0.4.0.1862.1.6.1 -- esign
0.4.0.1862.1.5 QcPDS = https://… (fr)
Authority Information Access: OCSP - URI:http://ocsp.qtsp.example
CRL Distribution Points: URI:http://crl.qtsp.example/ac-qualifiee.crlSuite : L'application de signature découvre le service et ce certificat par l'API CSC.
Découvrir le service et l'identifiant de clé
Application de signature → Service de signature du QTSP · info, list, info
Entrée
Appels CSC v2 (jeton OAuth de portée service).
POST /csc/v2/info
POST /csc/v2/credentials/list Authorization: Bearer <jeton service>
POST /csc/v2/credentials/info { "credentialID": "GX0112348", "certificates": "chain" }Traitement
- info décrit le service et le mode d'autorisation.
- credentials/list renvoie les identifiants de clés du titulaire.
- credentials/info renvoie l'algorithme, la chaîne de certificats, le niveau SCAL et le qualificatif de signature.
Sortie
Réponses (exemple).
{ "specs": "2.0.0.2", "name": "QTSP Exemple", "region": "FR", "lang": "fr",
"authType": ["oauth2code"], "oauth2": "https://auth.qtsp.example",
"methods": ["credentials/list", "credentials/info", "signatures/signHash"] }
{ "credentialIDs": ["GX0112348"] }
{ "signatureQualifier": "eu_eidas_qes",
"key": { "status": "enabled", "algo": ["1.2.840.10045.2.1"], "len": 256,
"curve": "1.2.840.10045.3.1.7" },
"cert": { "status": "valid", "certificates": ["MIIC…", "MIIC…"] },
"auth": { "mode": "oauth2code" },
"SCAL": "2",
"multisign": 1 }Suite : SCAL 2 signifie que l'autorisation devra être liée aux condensats à signer.
Préparer le condensat à signer
Application de signature → Application de signature · Condensat
Entrée
Identique à la section 7, étapes 1 à 3.
PDF avec /Contents réservé, signedAttrs construits avec le certificat qualifiéTraitement
- Calculer h = SHA-256(DER(signedAttrs)) et l'encoder en base64url pour l'autorisation.
Sortie
hashes = "sTOgwOm-474gFj0q0x1iSNspKqbcse4IeiqlDg_HWuI" -- exemple de valeur encodée
hashAlgorithmOID = 2.16.840.1.101.3.4.2.1Suite : Ce condensat est présenté au titulaire pour autorisation.
Autoriser la signature de ce condensat précis
Signataire → Serveur d'autorisation du QTSP · Autorisation SCAL2
Entrée
Redirection OAuth 2.0 de portée credential (CSC v2).
GET /oauth2/authorize?response_type=code
&client_id=<SCA>
&redirect_uri=https%3A%2F%2Fsca.example%2Fcb
&scope=credential
&credentialID=GX0112348
&numSignatures=1
&hashes=sTOgwOm-474gFj0q0x1iSNspKqbcse4IeiqlDg_HWuI
&hashAlgorithmOID=2.16.840.1.101.3.4.2.1
&code_challenge=…&code_challenge_method=S256
&state=12345678 HTTP/1.1
Host: auth.qtsp.exampleTraitement
- Le titulaire s'authentifie auprès du prestataire avec deux facteurs (par exemple code et application mobile, ou PID du portefeuille).
- Le serveur lie l'autorisation à credentialID, au nombre de signatures et aux condensats.
- Le jeton obtenu après échange du code tient lieu de données d'activation (SAD).
Sortie
Réponse du point token (exemple).
{ "access_token": "4/CKN69L8gdSYp5_pwH3XlFQZ3ndFhkXf9P2_TiHRG-bA",
"token_type": "Bearer", "expires_in": 300 }Suite : Ce jeton, inutilisable pour un autre condensat, autorise l'appel signHash.
Faire signer le condensat dans le QSCD distant
Application de signature → Service de signature du QTSP · signHash
Entrée
Requête CSC v2.
POST /csc/v2/signatures/signHash HTTP/1.1
Host: api.qtsp.example
Authorization: Bearer 4/CKN69L8gdSYp5_pwH3XlFQZ3ndFhkXf9P2_TiHRG-bA
Content-Type: application/json
{
"credentialID": "GX0112348",
"hashes": ["sTOgwOm-474gFj0q0x1iSNspKqbcse4IeiqlDg_HWuI"],
"hashAlgorithmOID": "2.16.840.1.101.3.4.2.1",
"signAlgo": "1.2.840.10045.4.3.2"
}Traitement
- Le SAM vérifie, dans son périmètre certifié, que les données d'activation correspondent à cette clé et à ce condensat.
- Il active la clé dans le HSM pour une opération ; le HSM signe en ECDSA P-256.
- Le prestataire journalise l'opération.
Sortie
Réponse.
{ "signatures": ["MEUCIQDqH…AiB3x…"] } -- ECDSA-Sig-Value DER, en base64Suite : L'application insère la signature dans le CMS (section 7, étape 6) avec le certificat qualifié.
Obtenir une signature qualifiée
Application de signature → Application de signature · QES
Entrée
SignerInfo.signature = signature reçue
certificates = [certificat qualifié, AC qualifiée]Traitement
- Même structure que la section 7 ; seuls le certificat et le dispositif changent.
Sortie
PAdES B-B : signature électronique qualifiée, sous réserve de validation (section 10)Suite : Pour durer, la signature doit être horodatée et enrichie de ses preuves de validité (section 9).
09Horodatage et conservation : niveaux B-T, B-LT, B-LTA
En production
RFC 3161, RFC 6960 et EN 319 142-1 ; algorithmes pour la conservation longue selon TS 119 312 V2.1.1, qui recommande désormais des horodatages post-quantiques (SLH-DSA, XMSS, LMS) pour l'archivage de plus de vingt ans.
Une signature B-B ne dit rien de la date à laquelle elle existait ni du statut du certificat à ce moment. Chaque niveau ajoute une preuve que la validation future pourra utiliser, même quand l'AC aura disparu ou que l'algorithme sera affaibli.
B-T : demander un jeton d'horodatage sur la signature
Application de signature → Autorité d'horodatage · TimeStampReq
Entrée
Requête RFC 3161 (HTTP, application/timestamp-query).
TimeStampReq {
version 1,
messageImprint {
hashAlgorithm 2.16.840.1.101.3.4.2.1, -- sha256
hashedMessage <SHA-256(valeur de SignerInfo.signature)>
},
nonce 0x5F2B…,
certReq TRUE
}Traitement
- On horodate la valeur de signature : cela prouve que la signature existait à cette date.
- certReq demande l'inclusion du certificat de l'unité d'horodatage dans la réponse.
Sortie
Réponse (application/timestamp-reply).
TimeStampResp {
status { status granted (0) },
timeStampToken ContentInfo signedData {
eContentType 1.2.840.113549.1.9.16.1.4 -- id-ct-TSTInfo
TSTInfo {
version 1,
policy <OID de la politique d'horodatage qualifiée>,
messageImprint { sha256, <même condensat> },
serialNumber 2318849,
genTime 20261003081507Z,
accuracy { seconds 1 },
nonce 0x5F2B…
}
-- signé par l'unité d'horodatage du prestataire qualifié
}
}Suite : Le jeton est ajouté comme attribut non signé de la signature.
B-LT : collecter la preuve de non-révocation
Application de signature → Répondeur OCSP · OCSP
Entrée
Requête RFC 6960.
OCSPRequest {
tbsRequest {
requestList {
Request {
reqCert CertID {
hashAlgorithm 1.3.14.3.2.26 ou 2.16.840.1.101.3.4.2.1,
issuerNameHash <condensat du nom de l'émetteur>,
issuerKeyHash <condensat de la clé publique de l'émetteur>,
serialNumber <numéro de série du certificat du signataire>
}
}
}
requestExtensions { id-pkix-ocsp-nonce <…> }
}
}Traitement
- Le répondeur de l'AC renvoie le statut du certificat, signé par sa propre clé.
- On collecte aussi les certificats de la chaîne et, si besoin, les CRL.
Sortie
Réponse (extrait).
BasicOCSPResponse {
tbsResponseData {
responderID byKey <…>,
producedAt 20261003081509Z,
responses { SingleResponse {
certID <identique>,
certStatus good,
thisUpdate 20261003080000Z,
nextUpdate 20261004080000Z
} }
}
signatureAlgorithm ecdsa-with-SHA256,
signature <…>,
certs { <certificat du répondeur> }
}Suite : Ces éléments sont rangés dans le PDF, dans le dictionnaire DSS.
B-LT : ranger les preuves dans le PDF
Application de signature → Application de signature · DSS
Entrée
Certificats, réponses OCSP, CRL.
chaîne de certificats du signataire et de l'horodatage, réponse OCSPTraitement
- Nouvelle mise à jour incrémentale : le catalogue du PDF reçoit un dictionnaire /DSS.
- La signature existante n'est pas touchée.
Sortie
Extrait PDF.
1 0 obj
<< /Type /Catalog /Pages 2 0 R /AcroForm 5 0 R /DSS 30 0 R >>
endobj
30 0 obj
<< /Certs [31 0 R 32 0 R 33 0 R] % flux DER des certificats
/OCSPs [34 0 R] % flux DER des réponses OCSP
/CRLs []
>>
endobjSuite : La signature est validable sans contacter l'AC. Reste à la protéger contre l'affaiblissement futur des algorithmes.
B-LTA : horodater l'ensemble du document
Application de signature → Autorité d'horodatage · DocTimeStamp
Entrée
PDF complet avec DSS.
toutes les révisions du fichier, y compris /DSSTraitement
- Nouvelle mise à jour incrémentale avec une signature de type horodatage de document : le condensat couvre tout le fichier.
- L'opération est renouvelée avant que les algorithmes ou les clés utilisés ne deviennent faibles : c'est la maintenance des signatures (TS 119 312, annexe B).
Sortie
Extrait PDF.
40 0 obj
<< /Type /DocTimeStamp
/Filter /Adobe.PPKLite
/SubFilter /ETSI.RFC3161
/ByteRange [0 25110 41496 412]
/Contents <3082…> % TimeStampToken RFC 3161, sans attribut signé PAdES
>>
endobjSuite : Le document peut être revalidé dans des décennies, tant que la chaîne de ré-horodatages n'est pas interrompue.
10Valider une signature et déterminer sa qualification
En production
Le règlement d'exécution (UE) 2025/1945 désigne ETSI TS 119 172-4 V1.1.1 et TS 119 102-2 V1.4.1, avec les adaptations de ses annexes, pour la présomption de conformité des processus de validation. Ses références normatives incluent EN 319 102-1 V1.4.1 et TS 119 612 V2.3.1. L'annexe I concerne les signatures et cachets qualifiés ; l'annexe II, les signatures et cachets avancés reposant sur des certificats qualifiés. Interprétation des listes : TS 119 615. Mise en œuvre de référence : logiciel DSS de la Commission.
La validation ne se contente pas de vérifier une signature mathématique. Elle reconstruit la chaîne jusqu'à une liste de confiance, établit le statut du certificat à la date prouvée, puis détermine si l'ensemble est qualifié. C'est cette dernière étape que l'arrêt Ekofrukt soumet au contrôle du juge.
Vérifier l'intégrité et la signature
Validateur → Validateur · Cryptographie
Entrée
PDF signé.
/ByteRange, /Contents (CMS), signedAttrs, signature, certificat du signataireTraitement
- Recalculer SHA-256 sur les plages /ByteRange et comparer à messageDigest.
- Vérifier la signature ECDSA sur DER(signedAttrs) avec la clé publique du certificat.
- Vérifier que le certificat correspond au condensat de signingCertificateV2.
Sortie
Issues possibles.
OK => étape suivante
TOTAL-FAILED / HASH_FAILURE (document modifié)
TOTAL-FAILED / SIG_CRYPTO_FAILURE (signature invalide)
INDETERMINATE / NO_SIGNING_CERTIFICATE_FOUNDSuite : La signature est cohérente ; reste à savoir si le certificat est digne de confiance.
Trouver l'ancre de confiance
Validateur → LOTL et listes de confiance · LOTL → liste FR
Entrée
Liste des listes de la Commission (XML signé).
GET https://ec.europa.eu/information_society/policy/esignature/trusted-list/tl-mp.xml
<OtherTSLPointer>
<ServiceDigitalIdentities> … certificats autorisés à signer la liste FR … </ServiceDigitalIdentities>
<TSLLocation>https://…/liste-de-confiance-FR.xml</TSLLocation>
<AdditionalInformation>
<OtherInformation><SchemeTerritory>FR</SchemeTerritory></OtherInformation>
<OtherInformation><MimeType>application/vnd.etsi.tsl+xml</MimeType></OtherInformation>
</AdditionalInformation>
</OtherTSLPointer>Traitement
- Vérifier la signature XML de la LOTL avec les certificats publiés par la Commission.
- Télécharger la liste française (organe de contrôle : ANSSI) et vérifier sa signature avec les certificats annoncés dans la LOTL.
- Rechercher le service dont le certificat a émis celui du signataire.
Sortie
Entrée de la liste nationale (TS 119 612, exemple).
<TSPService>
<ServiceInformation>
<ServiceTypeIdentifier>http://uri.etsi.org/TrstSvc/Svctype/CA/QC</ServiceTypeIdentifier>
<ServiceName><Name xml:lang="fr">AC qualifiée personnes physiques (exemple)</Name></ServiceName>
<ServiceDigitalIdentity><DigitalId><X509Certificate>MIIF…</X509Certificate></DigitalId></ServiceDigitalIdentity>
<ServiceStatus>http://uri.etsi.org/TrstSvc/TrustedList/Svcstatus/granted</ServiceStatus>
<StatusStartingTime>2024-07-01T00:00:00Z</StatusStartingTime>
<ServiceInformationExtensions>
<Extension Critical="true">
<AdditionalServiceInformation>
<URI xml:lang="en">http://uri.etsi.org/TrstSvc/TrustedList/SvcInfoExt/ForeSignatures</URI>
</AdditionalServiceInformation>
</Extension>
</ServiceInformationExtensions>
</ServiceInformation>
<ServiceHistory> … statuts antérieurs et dates … </ServiceHistory>
</TSPService>Suite : Le statut granted doit être vérifié à la date de la signature, en remontant l'historique du service si nécessaire.
Établir le statut du certificat à la bonne date
Validateur → Répondeur OCSP · Révocation
Entrée
Preuves embarquées (DSS) ou interrogation en ligne.
Date prouvée de la signature : genTime du jeton d'horodatage (preuve d'existence)
Réponse OCSP embarquée ou nouvelle requêteTraitement
- Utiliser l'heure de l'horodatage, pas /M, qui n'est qu'une heure revendiquée.
- Vérifier que le certificat n'était pas révoqué à cette date et que la réponse OCSP est elle-même valide.
Sortie
Issues possibles.
OK
INDETERMINATE / REVOKED_NO_POE (révoqué, sans preuve d'existence antérieure)
INDETERMINATE / OUT_OF_BOUNDS_NO_POE (signature hors de la période de validité prouvable)
INDETERMINATE / TRY_LATER (information de révocation pas encore disponible)Suite : Dernier contrôle technique : les algorithmes étaient-ils acceptables à la date pertinente ?
Appliquer les contraintes cryptographiques
Validateur → Validateur · Contraintes crypto
Entrée
La spécification ETSI TS 119 312 V2.1.1 (2026-06) distingue les mécanismes cryptographiques recommandés (R) des mécanismes hérités (L). Pour RSA, le § 8.4 (tableau 6) classe les modules d'au moins 1 900 bits et de moins de 3 000 bits comme L[2026] : ils ne doivent plus être utilisés pour émettre de nouveaux certificats après le 31 décembre 2026. Les modules d'au moins 3 000 bits sont recommandés (R). Le § 5.1 (tableau 1) classe SHA-256, SHA-384, SHA-512, SHA3-256, SHA3-384 et SHA3-512 comme recommandés (R), et SHA-224 comme L[2028]. Pour CAdES et PAdES, l'annexe A.2 (tableau A.1) exige que les signataires prennent en charge SHA-256 et que les vérificateurs prennent en charge SHA-256, SHA-384 et SHA-512. Source : ETSI TS 119 312 V2.1.1 (2026-06), § 5.1, § 8.4 et annexe A.2.
ECDSA P-256 + SHA-256 : recommandé (R)
RSA 1 900 à moins de 3 000 bits : hérité L[2026] ; aucun nouveau certificat après 2026-12-31
RSA ≥ 3 000 bits : recommandé (R)
RSA PKCS#1 v1.5 : hérité (L) ; RSA-PSS : recommandé (R)
SHA-256/384/512 : recommandés (R)
SHA3-256/384/512 : recommandés (R)
SHA-224 : hérité L[2028]Traitement
- Ces classements ne sont pas des dates d'invalidation juridique des signatures existantes.
- Comparer chaque algorithme et taille de clé à la date de signature, ou à la date du dernier horodatage d'archive pour une signature maintenue.
Sortie
OK, ou INDETERMINATE / CRYPTO_CONSTRAINTS_FAILURE_NO_POESuite : La signature est techniquement valide : reste à déterminer sa qualification juridique.
Déterminer la qualification (QES ou non)
Validateur → Validateur · Qualification
Entrée
Certificat et informations de la liste de confiance.
qcStatements : QcCompliance, QcSSCD, QcType = esign
Liste de confiance : service CA/QC granted à la date, ForeSignatures, éventuels qualificatifsTraitement
- Le certificat est-il qualifié à la date ? QcCompliance et inscription du service, avec priorité aux qualificatifs de la liste de confiance.
- La clé est-elle dans un QSCD ? QcSSCD, ou qualificatif QCWithSSCD de la liste.
- Est-ce un certificat de signature ou de cachet ? QcType.
Sortie
Rapport de validation (résumé).
Indication : TOTAL-PASSED
Qualification : QESig -- autres valeurs possibles : AdESig-QC, AdESig, QESeal, …
Date prouvée : 2026-10-03T08:15:07Z (jeton RFC 3161)
Signataire : CN=Camille DUPONT
Rapport : format XML normalisé (ETSI TS 119 102-2 V1.4.1)Suite : QESig emporte, en droit, l'effet d'une signature manuscrite et la présomption de fiabilité en France.
11Cachet électronique et registre électronique qualifié
Cadre et définitions
Le cachet est la signature d'une personne morale : même mécanique, autres marqueurs et autre effet juridique. Le registre électronique qualifié est le service créé par eIDAS 2 pour donner un statut probatoire à une séquence d'enregistrements.
Signature et cachet
| Signature électronique qualifiée | Cachet électronique qualifié | |
|---|---|---|
| Titulaire | Personne physique | Personne morale |
| Politique de certificat (EN 319 411-2) | 0.4.0.194112.1.2 QCP-n-qscd | 0.4.0.194112.1.3 QCP-l-qscd |
| QcType (EN 319 412-5) | 0.4.0.1862.1.6.1 esign | 0.4.0.1862.1.6.2 eseal |
| Structure technique | Identique : PAdES, CAdES, XAdES ou JAdES, mêmes algorithmes, même validation | |
| Effet juridique | Équivalent à la signature manuscrite (article 25) | Présomption d'intégrité des données et d'exactitude de leur origine (article 35) |
| Usage typique | Engagement contractuel d'une personne | Factures, attestations, documents émis par une organisation ; cachet final d'une plateforme (section 6) |
Registre électronique qualifié (eIDAS 2)
| Article | Contenu |
|---|---|
| 45k, paragraphe 1 | Un registre électronique ne peut être privé d'effet juridique au seul motif de sa forme électronique ou de ce qu'il n'est pas qualifié. |
| 45k, paragraphe 2 | Les enregistrements d'un registre qualifié bénéficient d'une présomption d'ordre chronologique séquentiel unique et exact, et d'intégrité. |
| 45l, point a | Créé et géré par un ou plusieurs prestataires de services de confiance qualifiés. |
| 45l, point b | Établit l'origine des enregistrements. |
| 45l, point c | Garantit l'ordre chronologique séquentiel unique des enregistrements. |
| 45l, point d | Enregistre les données de sorte que toute modification ultérieure soit immédiatement détectable. |
Sources
Version du 11 octobre 2026 · SHA-256 acf4…6a6f