eIDAS 2, échange par échange

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.

Documentation intégrale

Référentiel technique complet

Version textuelle directement présente dans le HTML. Chaque section peut être consultée sans exécuter JavaScript.

00

Acteurs 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.

Commission européenneLOTL et listes des fournisseurs EUDIListe nationale FR (ANSSI)prestataires qualifiésListes des fournisseurs EUDIPID, portefeuilles, accèsCSCA Francetitres d'identité, ICAOAC qualifiées, TSA, OCSPFournisseurs de PID et de portefeuilleDocument Signer de la CNIeValidateur de signatureService utilisateur, portefeuilleApplication France Identitéinscritinscritsigné parvérifievérifievérifie

Les acteurs, ce qu'ils détiennent et ce qu'ils croient

Personne

Utilisateur
Détient
Code personnel ou PIN, caractéristiques biométriques, consentement.
Fait confiance à
Ce que l'interface lui affiche.

Puce CNIe

Composant sécurisé (eMRTD)
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é

Application mobile
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

Instance de portefeuille EUDI
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

Élément sécurisé du téléphone
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

Serveur
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

Serveur d'autorisation et émetteur
Détient
Clé de signature des PID (certificat X.509), listes de statut.
Fait confiance à
Attestation de portefeuille, moyen d'identification national.

Service utilisateur

Partie utilisatrice (serveur)
Détient
Certificat d'accès, clé de chiffrement éphémère, nonce.
Fait confiance à
Listes de confiance des émetteurs de PID.

FranceConnect+

Fédération d'identité (DINUM)
Détient
Clés de signature ES256, sessions.
Fait confiance à
Fournisseurs d'identité substantiel et élevé.

Application de signature

Logiciel ou service SCA
Détient
Document, structure PAdES en construction.
Fait confiance à
Certificat du signataire.

Service de signature du QTSP

SAM + HSM (QSCD distant)
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

Service qualifié (QTSP)
Détient
Clé de l'unité d'horodatage, horloge UTC.
Fait confiance à
Source de temps traçable.

Validateur

Service ou logiciel EN 319 102-1
Détient
Politique de validation, contraintes cryptographiques.
Fait confiance à
LOTL de la Commission et listes nationales.

LOTL et listes de confiance

Commission et États membres
Détient
Statut des prestataires qualifiés et leurs certificats.
Fait confiance à
Signature de la Commission (LOTL) et des organes de contrôle.
01

Enrô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.

1.1

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.

TEXTE
CNIe (format ID-1, émise depuis août 2021)
CAN (Card Access Number) : 6 chiffres imprimés au recto
Exemple : 123456

Traitement

  1. L'application demande le CAN : sans lui, la puce refuse tout accès sans contact.
  2. Le CAN devient le mot de passe π du protocole PACE ; il n'est jamais transmis tel quel à la puce.
  3. 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.

TEXTE
π  = "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.

1.2

É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.

APDU · ISO/IEC 7816-4
→ 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 00

Traitement

  1. La puce tire un nonce s et l'envoie chiffré sous Kπ ; seule une partie connaissant le CAN peut le déchiffrer.
  2. 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.
  3. Un second échange Diffie-Hellman sur G' donne le secret K, dont on dérive KS_Enc et KS_MAC.
  4. 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).

TEXTE
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é.

1.3

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).

APDU · ISO/IEC 7816-4
→ 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

  1. DG1 contient la zone de lecture automatique (MRZ, format TD1 : trois lignes de 30 caractères).
  2. EF.SOD contient l'objet de sécurité du document : la liste des condensats de chaque groupe de données, signée.
  3. La puce ne délivre ces fichiers qu'à travers le canal PACE.

Sortie

Structures lues (forme abrégée).

CMS · RFC 5652
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.

1.4

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.

CMS · RFC 5652
DG1, DG14, ...           (octets lus)
EF.SOD                   (CMS SignedData)
CSCA FR                  (ancre de confiance, publiée par l'État et via l'ICAO PKD)

Traitement

  1. Recalculer SHA-256 de chaque groupe de données lu et le comparer à la valeur inscrite dans LDSSecurityObject.
  2. Vérifier la signature CMS de EF.SOD avec la clé publique du certificat Document Signer.
  3. 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.

TEXTE
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.

1.5

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é.

TEXTE
Chip Authentication : clé publique Diffie-Hellman de la puce dans DG14
Active Authentication : clé publique de signature de la puce dans DG15

Traitement

  1. 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.
  2. Active Authentication : l'application envoie un défi aléatoire, la puce le signe avec sa clé privée de DG15.
  3. 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.

TEXTE
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.

1.6

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.

TEXTE
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 personnel

Traitement

  1. L'application transmet aux serveurs de l'État les éléments nécessaires à la création de l'identité numérique.
  2. Une vérification complémentaire est faite par FranceConnect ou par courrier recommandé.
  3. Le format des messages et la nature exacte des données envoyées ne sont pas publiés.

Sortie

État de l'identité.

TEXTE
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.

1.7

Certifier l'identité en mairie

Personne → Agent en mairie · QR code, face-à-face

Entrée

Parcours public de certification.

TEXTE
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 agent

Traitement

  1. L'agent compare la personne présente au titre présenté : c'est le face-à-face, qui n'a pas d'équivalent cryptographique.
  2. Le QR code relie ce contrôle à l'identité numérique créée sur le téléphone.
  3. 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é.

TEXTE
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

02

Activation 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.

2.1

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é.

TEXTE
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'utilisateur

Traitement

  1. Le WSCD (élément sécurisé ou équivalent certifié) génère les paires de clés en interne.
  2. Les clés privées ne sortent jamais du composant ; seules les clés publiques sont exportées au format JWK.
  3. 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).

JSON
[
  { "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).

2.2

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.

TEXTE
Attestation de la plateforme (intégrité de l'application et de l'appareil)
Clés publiques générées à l'étape 1

Traitement

  1. Le fournisseur vérifie l'intégrité de l'instance et la certification du WSCD.
  2. Il signe une attestation d'instance (Wallet Attestation, OpenID4VCI annexe E) qui servira d'authentification client OAuth.
  3. Il signe une attestation de clés (OpenID4VCI annexe D) listant les clés publiques et leur niveau de protection.
  4. 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).

JSON
// 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).

2.3

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).

HTTP
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

  1. Le portefeuille récupère les métadonnées de l'émetteur (/.well-known/openid-credential-issuer) et du serveur d'autorisation.
  2. HAIP rend obligatoire la prise en charge du flux authorization_code par le portefeuille et l'émetteur.
  3. 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.

TEXTE
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.

2.4

Pousser la demande d'autorisation

Portefeuille → Fournisseur de PID · PAR + PKCE

Entrée

Requête HTTP (RFC 9126), authentification client par attestation.

HTTP
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=af0ifjsldkj

Traitement

  1. Le serveur vérifie l'attestation d'instance (signature, chaîne x5c jusqu'à la liste des fournisseurs de portefeuille) et sa preuve de possession.
  2. Il conserve le code_challenge PKCE, condensat d'un secret que seul le portefeuille connaît.
  3. Il enregistre les paramètres et renvoie une référence opaque.

Sortie

Réponse.

JSON
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.

2.5

Authentifier la personne auprès du fournisseur de PID

Personne → Fournisseur de PID · Authentification nationale

Entrée

Redirection vers l'autorisation.

HTTP
GET /authorize?client_id=eudi-wallet-fr-v1
  &request_uri=urn%3Aietf%3Aparams%3Aoauth%3Arequest_uri%3A6esc_11ACC5bwc014ltc14eY22c

Traitement

  1. Le fournisseur de PID authentifie la personne avec un moyen d'identification électronique de niveau élevé (en France, la CNIe par exemple).
  2. Il affiche ce qui va être émis et recueille le consentement.
  3. Il émet un code d'autorisation à usage unique, lié au code_challenge.

Sortie

Retour vers le portefeuille.

HTTP
HTTP/1.1 302 Found
Location: https://wallet.example.eu/cb?code=SplxlOBeZQQYbYS6WxSbIA
  &state=af0ifjsldkj
  &iss=https%3A%2F%2Fpid.example.fr

Suite : Le portefeuille vérifie state et iss (RFC 9207), puis échange le code contre un jeton lié à sa clé DPoP.

2.6

Obtenir un jeton d'accès lié à une clé

Portefeuille → Fournisseur de PID · Token + DPoP

Entrée

Requête au point de terminaison token.

HTTP
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

  1. Le serveur vérifie que BASE64URL(SHA-256(code_verifier)) est égal au code_challenge reçu en PAR.
  2. Il vérifie la preuve DPoP : signature par la clé jwk, méthode et URL, fraîcheur.
  3. Il émet un jeton d'accès lié à l'empreinte de cette clé : un jeton volé est inutilisable sans elle.

Sortie

Réponse.

JSON
{
  "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.

2.7

Obtenir un nonce pour la preuve de possession

Portefeuille → Fournisseur de PID · Nonce

Entrée

Requête.

HTTP
POST /nonce HTTP/1.1
Host: pid.example.fr

Traitement

  1. 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.

JSON
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.

2.8

Demander le PID avec preuve de possession

Portefeuille → Fournisseur de PID · Requête credential

Entrée

Requête et preuve décodée.

HTTP
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

  1. L'utilisateur déverrouille la clé dans le WSCD (PIN ou biométrie) pour signer la preuve.
  2. 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.
  3. 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.

TEXTE
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é.

2.9

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).

JSON
family_name   : "DUPONT"
given_name    : "Camille"
birthdate     : "1990-04-12"
nationalities : ["FR"]
+ métadonnées : issuing_authority, issuing_country, date d'expiration, statut

Traitement

  1. Chaque attribut divulgable devient une divulgation : un tableau JSON [sel, nom, valeur], encodé en base64url.
  2. 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.
  3. 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).

JSON
// 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"]]
  WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgIm5hdGlvbmFsaXRpZXMiLCBbIkZSIl1d

Suite : Le portefeuille stocke le JWT et toutes les divulgations ; il n'en révélera qu'une partie à chaque présentation.

2.10

Recevoir le lot de PID

Fournisseur de PID → Portefeuille · Réponse credential

Entrée

Réponse du point de terminaison credential.

JSON
HTTP/1.1 200 OK
Content-Type: application/json
{
  "credentials": [
    { "credential": "eyJhbGciOiJFUzI1NiIsInR5cCI6ImRjK3NkLWp3dCIs…~WyIyR0xD…~WyJlbHVW…~WyI2SWo3…~WyJlSTha…~" },
    { "credential": "eyJhbGciOiJFUzI1NiIsInR5cCI6ImRjK3NkLWp3dCIs…~…~" }
  ],
  "notification_id": "3fwe98js"
}

Traitement

  1. Le portefeuille vérifie la signature de chaque exemplaire et que cnf correspond bien à l'une de ses clés.
  2. 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.
  3. Le portefeuille inscrit l'émission dans son journal de transactions.

Sortie

État du portefeuille.

TEXTE
n exemplaires de PID SD-JWT VC, chacun lié à une clé distincte du WSCD
+ exemplaires mdoc

Suite : 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.

03

Identification 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.

3.1

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.

TEXTE
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'enregistrement

Traitement

  1. Le service génère un nonce aléatoire, un state et une clé éphémère P-256 pour chiffrer la réponse.
  2. Il exprime sa demande en DCQL : la nationalité n'étant pas demandée, elle ne sera pas divulguée.
  3. 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é.

JSON
{ "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.

3.2

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.

HTTP
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=qPmxiNFCR3QTm19POc8u

Traitement

  1. Le navigateur ouvre le portefeuille (schéma haip-vp://, lien https revendiqué, ou API Digital Credentials du navigateur).
  2. 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
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.

3.3

Vérifier l'identité du service

Portefeuille → Portefeuille · Contrôle du service

Entrée

Objet de requête signé.

TEXTE
En-tête x5c : [certificat d'accès, AC d'accès]
client_id    : x509_hash:Uvo3HtuIxuhC92rShpgqcT3YXwrqRxWEviRiA0OZszk

Traitement

  1. Vérifier typ = oauth-authz-req+jwt, sinon rejet.
  2. Calculer BASE64URL(SHA-256(DER du certificat feuille)) et le comparer au client_id après le préfixe.
  3. 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.
  4. 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).

TEXTE
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.

3.4

Construire la présentation et la lier à la transaction

Portefeuille → WSCD · KB-JWT

Entrée

Divulgations retenues et paramètres de la requête.

TEXTE
JWT émetteur : eyJhbGciOiJFUzI1NiIsInR5cCI6ImRjK3NkLWp3dCIs…
Divulgations retenues : family_name, given_name, birthdate   (nationalities exclue)
aud = x509_hash:Uvo3HtuIxuhC92rShpgqcT3YXwrqRxWEviRiA0OZszk
nonce = n-0S6_WzA2Mj

Traitement

  1. Assembler le SD-JWT présenté : JWT émetteur, puis les trois divulgations retenues, séparés par ~.
  2. Calculer sd_hash = BASE64URL(SHA-256) de cette chaîne, tilde final compris.
  3. 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.

JSON
{ "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.

3.5

Envoyer la réponse chiffrée

Portefeuille → Service utilisateur · direct_post.jwt

Entrée

Contenu à chiffrer.

JSON
{ "vp_token": { "pid": ["eyJhbGci…~…~eyJ0eXAiOiJrYitqd3Qi…"] }, "state": "eyJhb…6-sVA" }

Traitement

  1. Accord ECDH-ES entre une clé éphémère du portefeuille et la clé ac-1 du service, sur P-256.
  2. Chiffrement A256GCM ; le résultat est un JWE compact, non signé (la signature est déjà dans le KB-JWT).
  3. Envoi en POST au response_uri, paramètre response.

Sortie

Requête et réponse.

HTTP
// 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.

3.6

Valider la présentation

Service utilisateur → Service utilisateur · Validation

Entrée

JWE reçu.

TEXTE
response = eyJhbGciOiJFQ0RILUVTIi…

Traitement

  1. Déchiffrer avec la clé éphémère ac-1, puis vérifier state.
  2. 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.
  3. Divulgations : recalculer SHA-256 de chacune et vérifier sa présence dans _sd.
  4. 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.
  5. 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.

JSON
{ "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ée

Suite : Le service ne libère le résultat qu'à la session qui présente le response_code reçu par redirection.

3.7

Rattacher le résultat à la bonne session

Portefeuille → Navigateur du service · Redirection

Entrée

Redirection suivie par le portefeuille.

HTTP
GET /cb#response_code=091535f699ea575c7937fa5f0f454aee HTTP/1.1
Host: verifier.example.fr

Traitement

  1. Le navigateur de l'utilisateur transmet le response_code à l'interface du service.
  2. 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.

TEXTE
Session authentifiée avec les trois attributs vérifiés

Suite : Le portefeuille journalise la transaction : date, service, données demandées et partagées (considérant 13 du règlement 2024/1183).

04

Identification 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.

4.1

Demander une authentification de niveau substantiel

Fournisseur de service → FranceConnect+ · authorize

Entrée

Requête d'autorisation (flux code, seul flux implémenté).

HTTP
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.fr

Traitement

  1. acr_values = eidas2 (substantiel) ou eidas3 (élevé) ; eidas1 renvoie une erreur sur FranceConnect+.
  2. state protège contre le CSRF, nonce contre le rejeu : tous deux aléatoires, d'au moins 32 caractères.

Sortie

Réponse.

HTTP
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é.

4.2

S'authentifier avec France Identité

Personne → Fournisseur d'identité · Authentification

Entrée

Parcours public.

TEXTE
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

  1. L'application déverrouille l'identité certifiée et, si demandé, relit la puce de la carte (section 1).
  2. Le fournisseur d'identité renvoie à FranceConnect+ le niveau réellement atteint.

Sortie

Résultat transmis à la fédération.

TEXTE
Identité de niveau substantiel, avec la méthode d'authentification utilisée

Suite : FranceConnect+ redirige l'usager vers le fournisseur de service avec un code.

4.3

Recevoir le code d'autorisation

FranceConnect+ → Fournisseur de service · code

Entrée

Redirection.

HTTP
GET /oidc-callback?code=EIkPNC7db4tziWvGJvKQFaYFAjCEV0YBqbl9Im9xhpD
  &state=6f9986e85da4f2855defbbbae9eb6ef53dc0e9d06f95426c014edfde2787e31d HTTP/1.1
Host: fs.example.fr

Traitement

  1. Le fournisseur de service vérifie que state est celui de sa session.

Sortie

TEXTE
code à usage unique, à échanger côté serveur

Suite : Échange du code contre l'id_token, de serveur à serveur.

4.4

Échanger le code contre l'id_token

Fournisseur de service → FranceConnect+ · token

Entrée

Requête.

HTTP
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=EIkPNC7db4tziWvGJvKQFaYFAjCEV0YBqbl9Im9xhpD

Traitement

  1. FranceConnect+ récupère la clé publique de chiffrement du fournisseur de service (URL JWKS déclarée).
  2. 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é).

JSON
{
  "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.

4.5

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).

TEXTE
GET https://auth.franceconnect.gouv.fr/api/v2/jwks

Traitement

  1. Déchiffrer le JWE avec la clé privée du fournisseur de service.
  2. Vérifier la signature ES256 avec la clé désignée par kid dans les JWKS.
  3. Vérifier iss, aud = client_id, nonce = celui envoyé, exp.
  4. 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+).

JSON
{ "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é.

4.6

Récupérer l'identité pivot

Fournisseur de service → FranceConnect+ · userinfo

Entrée

Requête.

HTTP
GET /api/v2/userinfo HTTP/1.1
Host: auth.franceconnect.gouv.fr
Authorization: Bearer goSq0H6mF__-FqxLyD0z13SAtq9-D-LNJ489Znua2Qa

Traitement

  1. 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).

JSON
{
  "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.

05

Identification, 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érationCe qui est établiMatériel utiliséCe qui est signéPreuve transférable à un tiersExemple sur cette page
IdentificationQui est la personne : attributs liés à une personne réelleAttestation signée par un émetteur (PID) ou assertion d'une fédérationLes attributs, par l'émetteurOui, la signature de l'émetteurSection 3 (PID), section 4 (userinfo)
AuthentificationQue le détenteur légitime est présent maintenantClé privée de l'utilisateur ou de son dispositif, débloquée par PIN ou biométrieUn défi frais (nonce), lié au destinataireSelon le protocole : oui avec une signature de défi (KB-JWT), non avec Chip Authentication ou un MACSection 3 (KB-JWT), section 1 (anti-clonage)
SignatureQue la personne s'engage sur un contenuClé de signature avec certificat d'usage contentCommitmentLe condensat d'un documentOui, c'est son objetSections 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 eIDASValeur acr FranceConnectPlateformeExemple de moyen
Faibleeidas1FranceConnectComptes des fournisseurs d'identité historiques
Substantieleidas2FranceConnect+France Identité avec identité certifiée
Élevéeidas3FranceConnect+Moyens proposés pour le niveau élevé ; seuls ceux-ci sont présentés quand eidas3 est demandé
HAIP 1.0 précise qu'il remplit certaines exigences du niveau élevé mais pas toutes : le niveau dépend aussi de l'enrôlement, de la certification du WSCD et de l'organisation du fournisseur, hors du protocole.

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é.

06

Signature é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.

6.1

Figer le document à signer

Plateforme de signature → Plateforme de signature · Empreinte

Entrée

Document déposé par l'émetteur.

TEXTE
contrat-2026-118.pdf

Traitement

  1. La plateforme calcule l'empreinte SHA-256 du document et l'enregistre.

Sortie

TEXTE
SHA-256(contrat-2026-118.pdf) = <32 octets>

Suite : Cette empreinte permettra de démontrer que le document signé est celui présenté.

6.2

Identifier faiblement le signataire

Plateforme de signature → Signataire · Invitation, OTP

Entrée

Canaux utilisés.

TEXTE
Lien unique envoyé par e-mail
Code à usage unique envoyé par SMS au numéro fourni par l'émetteur

Traitement

  1. Le lien prouve l'accès à la boîte de messagerie, le code l'accès au téléphone.
  2. Aucune vérification d'identité officielle n'est faite à ce niveau.

Sortie

TEXTE
Événements journalisés : envoi, ouverture, saisie correcte du code

Suite : Le signataire consulte le document et clique pour signer.

6.3

Recueillir l'acte de signature

Signataire → Plateforme de signature · Consentement

Entrée

Action de l'utilisateur.

TEXTE
Case « J'ai lu et j'accepte » + clic « Signer »

Traitement

  1. 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).

JSON
{
  "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.

6.4

Sceller le document final

Plateforme de signature → Autorité d'horodatage · Cachet + horodatage

Entrée

Document avec l'apparence visuelle de signature.

TEXTE
PDF final + certificat de cachet électronique de la plateforme (personne morale)

Traitement

  1. La plateforme appose un cachet PAdES avec son propre certificat (QcType eseal si qualifié), mécaniquement identique à la signature de la section 7.
  2. Elle obtient un jeton d'horodatage RFC 3161 (section 9).

Sortie

Résultat.

TEXTE
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 preuve

Suite : En cas de contestation, c'est ce dossier que le juge examine.

07

Signature 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.

7.1

Réserver la place de la signature

Application de signature → Application de signature · Préparer le PDF

Entrée

PDF d'origine.

TEXTE
contrat-2026-118.pdf (révision 1)

Traitement

  1. Ajouter une mise à jour incrémentale contenant un champ de signature et un dictionnaire de signature.
  2. Réserver /Contents : 8 192 octets à zéro, soit 16 384 chiffres hexadécimaux entre chevrons.
  3. Calculer /ByteRange : tout le fichier sauf la valeur de /Contents.

Sortie

Dictionnaire de signature.

PDF · PAdES
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[.

7.2

Calculer le condensat du document

Application de signature → Application de signature · messageDigest

Entrée

Les deux plages /ByteRange.

TEXTE
octets [0 .. 839]  ||  octets [17226 .. 18755]

Traitement

  1. SHA-256 sur la concaténation des deux plages.
  2. C'est ce condensat qui lie la signature au document ; tout octet modifié hors /Contents change la valeur.

Sortie

TEXTE
messageDigest = SHA-256(plages) = <32 octets>

Suite : Le condensat est placé dans les attributs signés.

7.3

Construire les attributs signés

Application de signature → Application de signature · signedAttrs

Entrée

Condensat et certificat du signataire.

TEXTE
messageDigest
certificat du signataire (DER)

Traitement

  1. contentType = id-data.
  2. messageDigest = condensat de l'étape précédente.
  3. signingCertificateV2 = SHA-256 du certificat du signataire : empêche de substituer un autre certificat portant la même clé.
  4. Pas d'attribut signingTime : en PAdES, l'heure revendiquée est dans /M.
  5. 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).

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.

7.4

Activer la clé avec le PIN

Signataire → Jeton ou carte · PIN

Entrée

Interface PKCS#11 côté poste.

TEXTE
C_OpenSession(slot, CKF_SERIAL_SESSION, …, &hSession)
C_Login(hSession, CKU_USER, "<PIN>", len)

Traitement

  1. Le PIN est vérifié par le jeton lui-même ; après un petit nombre d'échecs, le jeton se bloque.
  2. La clé privée n'est utilisable que dans cette session authentifiée.

Sortie

TEXTE
Session authentifiée : CKR_OK

Suite : Le logiciel demande la signature du condensat.

7.5

Signer le condensat dans le jeton

Application de signature → Jeton ou carte · C_Sign

Entrée

Appel PKCS#11.

TEXTE
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

  1. Le jeton calcule une signature ECDSA P-256 sur h avec la clé privée qui ne le quitte jamais.
  2. PKCS#11 renvoie la signature brute r || s (64 octets).
  3. Le logiciel la réencode en ECDSA-Sig-Value DER pour CMS.

Sortie

ASN.1
r || s  (64 octets)  =>  SEQUENCE { INTEGER r, INTEGER s }   -- environ 70 à 72 octets en DER

Suite : La signature est intégrée à la structure CMS.

7.6

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.

TEXTE
signedAttrs, signature DER, certificat du signataire, certificat de l'AC

Traitement

  1. Construire le SignedData détaché (le document n'est pas copié dans le CMS).
  2. 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).

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.

08

Signature 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é.

8.1

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).

TEXTE
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 prestataire

Traitement

  1. La paire de clés est générée dans le HSM et associée au titulaire par le SAM.
  2. Le certificat porte les marqueurs qui permettront au validateur de reconnaître une QES.

Sortie

Extensions du certificat (extrait).

TEXTE
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.crl

Suite : L'application de signature découvre le service et ce certificat par l'API CSC.

8.2

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).

HTTP
POST /csc/v2/info
POST /csc/v2/credentials/list         Authorization: Bearer <jeton service>
POST /csc/v2/credentials/info         { "credentialID": "GX0112348", "certificates": "chain" }

Traitement

  1. info décrit le service et le mode d'autorisation.
  2. credentials/list renvoie les identifiants de clés du titulaire.
  3. credentials/info renvoie l'algorithme, la chaîne de certificats, le niveau SCAL et le qualificatif de signature.

Sortie

Réponses (exemple).

JSON
{ "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.

8.3

Préparer le condensat à signer

Application de signature → Application de signature · Condensat

Entrée

Identique à la section 7, étapes 1 à 3.

TEXTE
PDF avec /Contents réservé, signedAttrs construits avec le certificat qualifié

Traitement

  1. Calculer h = SHA-256(DER(signedAttrs)) et l'encoder en base64url pour l'autorisation.

Sortie

TEXTE
hashes = "sTOgwOm-474gFj0q0x1iSNspKqbcse4IeiqlDg_HWuI"   -- exemple de valeur encodée
hashAlgorithmOID = 2.16.840.1.101.3.4.2.1

Suite : Ce condensat est présenté au titulaire pour autorisation.

8.4

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).

HTTP
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.example

Traitement

  1. Le titulaire s'authentifie auprès du prestataire avec deux facteurs (par exemple code et application mobile, ou PID du portefeuille).
  2. Le serveur lie l'autorisation à credentialID, au nombre de signatures et aux condensats.
  3. Le jeton obtenu après échange du code tient lieu de données d'activation (SAD).

Sortie

Réponse du point token (exemple).

JSON
{ "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.

8.5

Faire signer le condensat dans le QSCD distant

Application de signature → Service de signature du QTSP · signHash

Entrée

Requête CSC v2.

HTTP
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

  1. Le SAM vérifie, dans son périmètre certifié, que les données d'activation correspondent à cette clé et à ce condensat.
  2. Il active la clé dans le HSM pour une opération ; le HSM signe en ECDSA P-256.
  3. Le prestataire journalise l'opération.

Sortie

Réponse.

JSON
{ "signatures": ["MEUCIQDqH…AiB3x…"] }    -- ECDSA-Sig-Value DER, en base64

Suite : L'application insère la signature dans le CMS (section 7, étape 6) avec le certificat qualifié.

8.6

Obtenir une signature qualifiée

Application de signature → Application de signature · QES

Entrée

CMS · RFC 5652
SignerInfo.signature = signature reçue
certificates = [certificat qualifié, AC qualifiée]

Traitement

  1. Même structure que la section 7 ; seuls le certificat et le dispositif changent.

Sortie

TEXTE
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).

09

Horodatage 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.

9.1

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).

ASN.1 · RFC 3161
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

  1. On horodate la valeur de signature : cela prouve que la signature existait à cette date.
  2. certReq demande l'inclusion du certificat de l'unité d'horodatage dans la réponse.

Sortie

Réponse (application/timestamp-reply).

ASN.1 · RFC 3161
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.

9.2

B-LT : collecter la preuve de non-révocation

Application de signature → Répondeur OCSP · OCSP

Entrée

Requête RFC 6960.

OCSP · 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

  1. Le répondeur de l'AC renvoie le statut du certificat, signé par sa propre clé.
  2. On collecte aussi les certificats de la chaîne et, si besoin, les CRL.

Sortie

Réponse (extrait).

OCSP · RFC 6960
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.

9.3

B-LT : ranger les preuves dans le PDF

Application de signature → Application de signature · DSS

Entrée

Certificats, réponses OCSP, CRL.

TEXTE
chaîne de certificats du signataire et de l'horodatage, réponse OCSP

Traitement

  1. Nouvelle mise à jour incrémentale : le catalogue du PDF reçoit un dictionnaire /DSS.
  2. La signature existante n'est pas touchée.

Sortie

Extrait PDF.

PDF · PAdES
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   []
>>
endobj

Suite : La signature est validable sans contacter l'AC. Reste à la protéger contre l'affaiblissement futur des algorithmes.

9.4

B-LTA : horodater l'ensemble du document

Application de signature → Autorité d'horodatage · DocTimeStamp

Entrée

PDF complet avec DSS.

TEXTE
toutes les révisions du fichier, y compris /DSS

Traitement

  1. Nouvelle mise à jour incrémentale avec une signature de type horodatage de document : le condensat couvre tout le fichier.
  2. 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.

PDF · PAdES
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
>>
endobj

Suite : Le document peut être revalidé dans des décennies, tant que la chaîne de ré-horodatages n'est pas interrompue.

10

Valider 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.

10.1

Vérifier l'intégrité et la signature

Validateur → Validateur · Cryptographie

Entrée

PDF signé.

TEXTE
/ByteRange, /Contents (CMS), signedAttrs, signature, certificat du signataire

Traitement

  1. Recalculer SHA-256 sur les plages /ByteRange et comparer à messageDigest.
  2. Vérifier la signature ECDSA sur DER(signedAttrs) avec la clé publique du certificat.
  3. Vérifier que le certificat correspond au condensat de signingCertificateV2.

Sortie

Issues possibles.

TEXTE
OK                                   => étape suivante
TOTAL-FAILED / HASH_FAILURE          (document modifié)
TOTAL-FAILED / SIG_CRYPTO_FAILURE    (signature invalide)
INDETERMINATE / NO_SIGNING_CERTIFICATE_FOUND

Suite : La signature est cohérente ; reste à savoir si le certificat est digne de confiance.

10.2

Trouver l'ancre de confiance

Validateur → LOTL et listes de confiance · LOTL → liste FR

Entrée

Liste des listes de la Commission (XML signé).

XML
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

  1. Vérifier la signature XML de la LOTL avec les certificats publiés par la Commission.
  2. 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.
  3. Rechercher le service dont le certificat a émis celui du signataire.

Sortie

Entrée de la liste nationale (TS 119 612, exemple).

XML
<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.

10.3

Établir le statut du certificat à la bonne date

Validateur → Répondeur OCSP · Révocation

Entrée

Preuves embarquées (DSS) ou interrogation en ligne.

TEXTE
Date prouvée de la signature : genTime du jeton d'horodatage (preuve d'existence)
Réponse OCSP embarquée ou nouvelle requête

Traitement

  1. Utiliser l'heure de l'horodatage, pas /M, qui n'est qu'une heure revendiquée.
  2. 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.

TEXTE
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 ?

10.4

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.

TEXTE
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

  1. Ces classements ne sont pas des dates d'invalidation juridique des signatures existantes.
  2. Comparer chaque algorithme et taille de clé à la date de signature, ou à la date du dernier horodatage d'archive pour une signature maintenue.

Sortie

TEXTE
OK, ou INDETERMINATE / CRYPTO_CONSTRAINTS_FAILURE_NO_POE

Suite : La signature est techniquement valide : reste à déterminer sa qualification juridique.

10.5

Déterminer la qualification (QES ou non)

Validateur → Validateur · Qualification

Entrée

Certificat et informations de la liste de confiance.

TEXTE
qcStatements : QcCompliance, QcSSCD, QcType = esign
Liste de confiance : service CA/QC granted à la date, ForeSignatures, éventuels qualificatifs

Traitement

  1. Le certificat est-il qualifié à la date ? QcCompliance et inscription du service, avec priorité aux qualificatifs de la liste de confiance.
  2. La clé est-elle dans un QSCD ? QcSSCD, ou qualificatif QCWithSSCD de la liste.
  3. Est-ce un certificat de signature ou de cachet ? QcType.

Sortie

Rapport de validation (résumé).

TEXTE
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.

11

Cachet é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éeCachet électronique qualifié
TitulairePersonne physiquePersonne morale
Politique de certificat (EN 319 411-2)0.4.0.194112.1.2 QCP-n-qscd0.4.0.194112.1.3 QCP-l-qscd
QcType (EN 319 412-5)0.4.0.1862.1.6.1 esign0.4.0.1862.1.6.2 eseal
Structure techniqueIdentique : 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 typiqueEngagement contractuel d'une personneFactures, attestations, documents émis par une organisation ; cachet final d'une plateforme (section 6)

Registre électronique qualifié (eIDAS 2)

ArticleContenu
45k, paragraphe 1Un 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 2Les 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 aCréé et géré par un ou plusieurs prestataires de services de confiance qualifiés.
45l, point bÉtablit l'origine des enregistrements.
45l, point cGarantit l'ordre chronologique séquentiel unique des enregistrements.
45l, point dEnregistre les données de sorte que toute modification ultérieure soit immédiatement détectable.
Les normes qui donneront présomption de conformité aux exigences de l'article 45l ne sont pas encore publiées ; TS 119 312 V2.1.1 inclut déjà les registres électroniques dans son champ et annonce une mise à jour pour les besoins non couverts.
Vous travaillez dans la signature, l'identité numérique ou la conformité ? Une correction ou un cas à ajouter est le bienvenu.thomas@codethelaw.eu

Mis à jour le 11 octobre 2026. Les exemples sont illustratifs : valeurs fictives, messages parfois tronqués, et formats non publiés signalés comme tels. Un projet Code The Law.

Version du 11 octobre 2026 · SHA-256 acf4…6a6f