<!-- Generated from prerendered index.html. HTML SHA-256: 05f90a8345dcd71aeb6525c36f71f515de66e6ba7a6bfbd6ffe3fdb07a1509be -->

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

1.  [00 · Acteurs et chaîne de confiance](https://signature.codethelaw.eu/#reference-acteurs)
2.  [01 · Enrôlement : lire la CNIe et créer l'identité numérique](https://signature.codethelaw.eu/#reference-enrolement)
3.  [02 · Activation du portefeuille et émission du PID](https://signature.codethelaw.eu/#reference-pid)
4.  [03 · Identification auprès d'un service avec le portefeuille](https://signature.codethelaw.eu/#reference-presentation)
5.  [04 · Identification en production aujourd'hui : FranceConnect+](https://signature.codethelaw.eu/#reference-franceconnect)
6.  [05 · Identification, authentification, signature : ce que chacune produit](https://signature.codethelaw.eu/#reference-niveaux)
7.  [06 · Signature électronique simple, telle que pratiquée par le marché](https://signature.codethelaw.eu/#reference-simple)
8.  [07 · Signature avancée : construire une signature PAdES B-B](https://signature.codethelaw.eu/#reference-avancee)
9.  [08 · Signature qualifiée à distance (API Cloud Signature Consortium)](https://signature.codethelaw.eu/#reference-qes)
10.  [09 · Horodatage et conservation : niveaux B-T, B-LT, B-LTA](https://signature.codethelaw.eu/#reference-horodatage)
11.  [10 · Valider une signature et déterminer sa qualification](https://signature.codethelaw.eu/#reference-validation)
12.  [11 · Cachet électronique et registre électronique qualifié](https://signature.codethelaw.eu/#reference-cachet)

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

Carte des ancres de confiance

-   Commission européenne — LOTL et listes des fournisseurs EUDI
-   Liste nationale FR (ANSSI) — prestataires qualifiés
-   Listes des fournisseurs EUDI — PID, portefeuilles, accès
-   CSCA France — titres d'identité, ICAO
-   AC qualifiées, TSA, OCSP
-   Fournisseurs de PID et de portefeuille
-   Document Signer de la CNIe
-   Validateur de signature
-   Service utilisateur, portefeuille
-   Application France Identité
-   Liste nationale FR (ANSSI) → Commission européenne
-   Listes des fournisseurs EUDI → Commission européenne
-   AC qualifiées, TSA, OCSP → Liste nationale FR (ANSSI) · inscrit
-   Fournisseurs de PID et de portefeuille → Listes des fournisseurs EUDI · inscrit
-   Document Signer de la CNIe → CSCA France · signé par
-   Validateur de signature → AC qualifiées, TSA, OCSP · vérifie
-   Service utilisateur, portefeuille → Fournisseurs de PID et de portefeuille · vérifie
-   Application France Identité → Document Signer de la CNIe · vé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.

### Sources

-   [Règlement (UE) n° 910/2014, texte consolidé au 18 octobre 2024](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX%3A02014R0910-20241018)
-   [Règlement (UE) 2024/1183 (eIDAS 2)](https://eur-lex.europa.eu/eli/reg/2024/1183/oj/fra)
-   [Règlement d'exécution (UE) 2025/1943 (certificats qualifiés, annexes I et II)](https://eur-lex.europa.eu/eli/reg_impl/2025/1943/oj/fra)
-   [Règlement d'exécution (UE) 2025/1945 (validation, annexes I et II)](https://eur-lex.europa.eu/eli/reg_impl/2025/1945/oj/fra)
-   [Commission européenne, listes de confiance (article 22)](https://digital-strategy.ec.europa.eu/en/policies/eu-trusted-lists)
-   [ETSI, prestataires de services de confiance et LOTL](https://portal.etsi.org/TB-SiteMap/ESI/Trust-Service-Providers)

## 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**

```text
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**

```text
π  = "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**

```text
→ 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**

```text
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**

```text
→ 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**

```text
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**

```text
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**

```text
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.
```

**NOTE.** L'authentification passive ne fait intervenir aucune clé de la carte : elle vérifie une signature de l'État sur des données. Elle prouve l'intégrité et l'origine, pas la présence d'une puce authentique.

**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**

```text
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**

```text
Puce authentique : OK
La clé privée de la puce n'a jamais quitté le composant.
```

**NON PUBLIÉ.** Le profil exact de la CNIe (Chip Authentication, Active Authentication ou les deux) n'est pas détaillé publiquement. Les deux mécanismes sont ceux définis par ICAO 9303 partie 11.

**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**

```text
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**

```text
Identité numérique créée (non certifiée)
Utilisable sur FranceConnect, pas sur FranceConnect+
```

**NON PUBLIÉ.** Étape interne non publiée : la page ne montre volontairement aucun format de message inventé.

**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**

```text
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**

```text
Identité numérique certifiée
=> accès à FranceConnect+ (niveaux eidas2 et eidas3 côté fédération)
```

**BASE LÉGALE.** Juridiquement, c'est cette étape d'enrôlement qui fonde le niveau de garantie (règlement d'exécution (UE) 2015/1502 : preuve et vérification d'identité). La cryptographie des étapes suivantes ne fait que rejouer ce lien.

**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](https://france-identite.gouv.fr/identite-numerique-certifiee/)
-   [FranceConnect, compte France Identité (création, certification)](https://www.franceconnect.gouv.fr/comptes-disponibles/france-identite/)
-   [France Identité, authentification sans lecture de carte](https://france-identite.gouv.fr/actualite/utiliser_app_sans_lecture_CNI.html)
-   ICAO Doc 9303 partie 11 (PACE, Chip et Active Authentication) et BSI TR-03110 partie 3, normes de référence

## 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**

```text
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**

```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**

```text
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**

```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"
}
```

**NOTE 1.** Divergence connue : la spécification européenne TS3 v1.5 type l'attestation de clés keyattestation+jwt (sans tiret) et retire iss, alors qu'OpenID4VCI 1.0 enregistre key-attestation+jwt. Un émetteur qui compare typ strictement rejettera l'autre forme.

**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**

```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**

```text
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**

```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**

```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**

```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
HTTP/1.1 302 Found
Location: https://wallet.example.eu/cb?code=SplxlOBeZQQYbYS6WxSbIA
  &state=af0ifjsldkj
  &iss=https%3A%2F%2Fpid.example.fr
```

**NON PUBLIÉ.** Le moyen d'authentification utilisé par chaque fournisseur de PID relève du schéma national : HAIP le laisse hors de son périmètre.

**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**

```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**

```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**

```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**

```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**

```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**

```text
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**

```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**

```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
```

**NOTE 2.** Le même PID est aussi émis en mdoc (ISO/IEC 18013-5) : type de document eu.europa.ec.eudi.pid.1, attributs en CBOR, condensats dans un Mobile Security Object signé en COSE\_Sign1 avec la chaîne x5chain (étiquette 33) et la clé de l'appareil dans deviceKeyInfo. Dans le PID SD-JWT, la date de naissance s'appelle birthdate ; en mdoc, birth\_date.

**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**

```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**

```text
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.

### Sources

-   [OpenID for Verifiable Credential Issuance 1.0](https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html)
-   [OpenID4VC High Assurance Interoperability Profile 1.0](https://openid.net/specs/openid4vc-high-assurance-interoperability-profile-1_0.html)
-   [RFC 9901, Selective Disclosure for JWTs](https://www.rfc-editor.org/info/rfc9901)
-   [ARF, annexe 3.01, règle PID (urn:eudi:pid:1, eu.europa.ec.eudi.pid.1)](https://eu-digital-identity-wallet.github.io/eudi-doc-architecture-and-reference-framework/2.4.0/annexes/annex-3/annex-3.01-pid-rulebook/)
-   [Règlement d'exécution (UE) 2024/2977 (PID et attestations)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202402977)
-   [Règlement d'exécution (UE) 2024/2982 (protocoles et interfaces)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ%3AL_202402982)
-   [Règlement d'exécution (UE) 2026/1731 du 15 juillet 2026 (JO du 22 juillet ; mise à jour des normes du portefeuille)](https://eur-lex.europa.eu/eli/reg_impl/2026/1731/oj/fra)
-   [iGrant.io, comparaison OpenID4VCI 1.0 et TS3 v1.5](https://eudi-wallet-wua-playground.igrant.io/openid4vci-vs-ts03)

## 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**

```text
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**

```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"] } }
  }
}
```

**NOTE.** wallet\_nonce n'est présent que parce que le portefeuille l'a fourni à l'étape 2 : l'objet signé est construit à la réception de cette requête POST.

**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**

```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
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**

```text
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**

```text
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**

```text
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**

```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**

```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**

```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**

```text
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**

```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**

```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**

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

### Sources

-   [OpenID for Verifiable Presentations 1.0](https://openid.net/specs/openid-4-verifiable-presentations-1_0.html)
-   [OpenID4VC High Assurance Interoperability Profile 1.0](https://openid.net/specs/openid4vc-high-assurance-interoperability-profile-1_0.html)
-   [Règlement d'exécution (UE) 2024/2982 (protocoles et interfaces)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ%3AL_202402982)
-   [Règlement d'exécution (UE) 2026/1731, article 4 (certificats d'enregistrement : application au 11 août 2028)](https://eur-lex.europa.eu/eli/reg_impl/2026/1731/oj/fra)
-   [iGrant.io, synthèse du règlement 2026/1731](https://docs.igrant.io/regulations/implementing-acts-wallet-standards-update/)
-   [lawandtechnology.eu, calendrier des actes d'exécution](https://lawandtechnology.eu/en/european-digital-identity-wallet-december-2026-deadline-en/)

## 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**

```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
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**

```text
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**

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

**NON PUBLIÉ.** Le protocole entre FranceConnect+ et ses fournisseurs d'identité n'est pas reproduit ici.

**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**

```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**

```text
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**

```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**

```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**

```text
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**

```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"
}
```

**NOTE.** sub est un identifiant par secteur (pairwise) : deux services de secteurs différents reçoivent des sub différents pour la même personne.

**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**

```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**

```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
}
```

**BASE LÉGALE.** Comparaison avec la section 3 : ici la preuve transférable est la signature de FranceConnect+, pas celle de l'usager. La passerelle eIDAS de FranceConnect, en production, permet aussi d'accepter les moyens d'identification notifiés d'autres États membres.

**Suite :** Ces champs forment l'identité pivot, que le service ne doit pas laisser modifier.

### Sources

-   [FranceConnect, endpoints disponibles](https://docs.partenaires.franceconnect.gouv.fr/fs/fs-technique/fs-technique-endpoints/)
-   [FranceConnect, implémentation d'OpenID Connect (signature et chiffrement)](https://docs.partenaires.franceconnect.gouv.fr/fs/fs-technique/fs-technique-oidc-fc-plus/)
-   [FranceConnect, niveaux de garantie eIDAS et ACR](https://docs.partenaires.franceconnect.gouv.fr/fs/fs-technique/fs-technique-eidas-acr/)
-   [FranceConnect, compte France Identité](https://www.franceconnect.gouv.fr/comptes-disponibles/france-identite/)

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

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

### Sources

-   [Règlement d'exécution (UE) 2015/1502 (niveaux de garantie)](https://eur-lex.europa.eu/eli/reg_impl/2015/1502/oj)
-   [FranceConnect, niveaux de garantie eIDAS et ACR](https://docs.partenaires.franceconnect.gouv.fr/fs/fs-technique/fs-technique-eidas-acr/)
-   [OpenID4VC HAIP 1.0, note sur le niveau élevé](https://openid.net/specs/openid4vc-high-assurance-interoperability-profile-1_0.html)

## 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**

```text
contrat-2026-118.pdf
```

#### Traitement

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

#### Sortie

**TEXTE**

```text
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**

```text
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**

```text
É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**

```text
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**

```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": "…" }
  ]
}
```

**NON PUBLIÉ.** Format interne à chaque prestataire : aucun standard n'impose cette structure. Le nommage ci-dessus est illustratif.

**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**

```text
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**

```text
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
```

**BASE LÉGALE.** Article 25, paragraphe 1, du règlement eIDAS : effet juridique non refusé au seul motif de la forme électronique. En droit français, la fiabilité n'est présumée que pour la signature qualifiée (décret n° 2017-1416) ; ici, la charge de la preuve pèse sur celui qui invoque la signature (article 1367 du Code civil).

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

### Sources

-   [Règlement (UE) n° 910/2014, article 25](https://eur-lex.europa.eu/legal-content/FR/TXT/PDF/?uri=CELEX%3A32014R0910)
-   [AGIL'IT, CJUE Ekofrukt C-362/21 et décret 2017-1416](https://www.agilit.law/en/it-personal-data/signature-electronique-qualifiee-cjue/)

## 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**

```text
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**

```text
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**

```text
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**

```text
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**

```text
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**

```text
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**

```text
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**

```text
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**

```text
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**

```text
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**

```text
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**

```text
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)
      }
    }
  }
}
```

**BASE LÉGALE.** Avancée au sens de l'article 26 si le certificat identifie le signataire et si la clé est sous son contrôle exclusif. Qualifiée si, en plus, le certificat est qualifié et le jeton est un QSCD notifié (sections 8 et 10).

**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](https://www.etsi.org/deliver/etsi_ts/119300_119399/119312/02.01.01_60/ts_119312v020101p.pdf)
-   ETSI EN 319 142-1, PAdES (référencée par TS 119 312)
-   [RFC 5652, Cryptographic Message Syntax](https://www.rfc-editor.org/info/rfc5652)
-   [RFC 5035, ESS signingCertificateV2](https://www.rfc-editor.org/info/rfc5035)

## 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**

```text
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**

```text
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
```

**BASE LÉGALE.** Le règlement d'exécution (UE) 2025/1943, annexe I, désigne ETSI EN 319 411-2 V2.6.1 et EN 319 412-1 V1.6.1, -2 V2.4.1 et -5 V2.5.1, avec les adaptations de cette annexe, pour la présomption de conformité des certificats qualifiés de signature. L'annexe II concerne les certificats de cachet. Le respect de ces références ne dispense pas du statut qualifié du service ; d'autres pratiques peuvent aussi démontrer la conformité (considérant 3).

**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**

```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**

```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**

```text
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**

```text
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**

```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**

```json
{ "access_token": "4/CKN69L8gdSYp5_pwH3XlFQZ3ndFhkXf9P2_TiHRG-bA",
  "token_type": "Bearer", "expires_in": 300 }
```

**NOTE.** Variante explicite de l'API : POST /csc/v2/credentials/authorize avec authData, qui renvoie { "SAD": "…" } à passer ensuite à signHash.

**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**

```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**

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

**BASE LÉGALE.** C'est ici que se joue le contrôle exclusif de l'article 26 et du considérant 51 : il est garanti par l'évaluation du SAM (EN 419 241-2) et du HSM (EN 419 221-5), et non par une preuve cryptographique que le destinataire pourrait vérifier.

**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**

```text
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**

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

### Sources

-   [Règlement d'exécution (UE) 2025/1943 (certificats qualifiés, annexe I)](https://eur-lex.europa.eu/eli/reg_impl/2025/1943/oj/fra)
-   [Cloud Signature Consortium, API v2.0.0.2](https://cloudsignatureconsortium.org/wp-content/uploads/2023/04/csc-api-v2.0.0.2.pdf)
-   [Buypass, exemples réels de l'API CSC v2](https://buypassdev.atlassian.net/wiki/spaces/DEVSPACE/pages/3400237057/BCSS+-+person+signing+Role+of+Signature+Creation+Application+Service+Provider+SCASP)
-   [EN 419 241-2:2019, profil de protection du QSCD serveur](https://standards.iteh.ai/catalog/standards/cen/6161a882-7bd0-4450-a2ca-bf20251d6382/en-419241-2-2019)
-   [Cryptomathic, SAM et HSM dans un QSCD distant](https://www.cryptomathic.com/news-events/blog/eidas-qualified-remote-signing-exploring-en-419-241-2-certified-qualified-signature-creation-devices)
-   [Commission, liste des QSCD notifiés](https://eidas.ec.europa.eu/efda/browse/notification/qscd-sscd)

## 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**

```text
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**

```text
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é
  }
}
```

**NOTE 1.** Emplacement : SignerInfo.unsignedAttrs, attribut signature-time-stamp (1.2.840.113549.1.9.16.2.14). La signature ne change pas : l'horodatage s'y attache après coup.

**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**

```text
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**

```text
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**

```text
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**

```text
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**

```text
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**

```text
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
```

**NOTE 2.** TS 119 312 V2.1.1 : SHA-256 jugé insuffisant pour l'archivage de plus de vingt ans (marge classique de 128 bits) ; recommandation de SHA-384 ou plus et d'algorithmes post-quantiques pour les unités d'horodatage.

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

### Sources

-   [RFC 3161, Time-Stamp Protocol](https://www.rfc-editor.org/info/rfc3161)
-   [RFC 6960, OCSP](https://www.rfc-editor.org/info/rfc6960)
-   [ETSI TS 119 312 V2.1.1, annexe B et clause 5.2.2](https://www.etsi.org/deliver/etsi_ts/119300_119399/119312/02.01.01_60/ts_119312v020101p.pdf)

## 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**

```text
/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**

```text
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**

```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**

```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**

```text
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**

```text
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**

```text
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**

```text
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**

```text
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**

```text
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)
```

**BASE LÉGALE.** CJUE, 20 octobre 2022, Ekofrukt (C-362/21) : la mention « qualifiée » portée par le certificat ne suffit pas ; le juge vérifie les trois conditions (signature avancée, certificat qualifié, dispositif qualifié). C'est exactement ce que cette étape automatise, et ce qu'un expert peut être amené à refaire.

**Suite :** QESig emporte, en droit, l'effet d'une signature manuscrite et la présomption de fiabilité en France.

### Sources

-   [Règlement d'exécution (UE) 2025/1945 (validation, annexes I et II)](https://eur-lex.europa.eu/eli/reg_impl/2025/1945/oj/fra)
-   [Règlement d'exécution (UE) 2025/1943 (certificats qualifiés)](https://eur-lex.europa.eu/eli/reg_impl/2025/1943/oj/fra)
-   [ETSI TS 119 312 V2.1.1 (2026-06), § 5.1, § 8.4 et annexe A.2](https://www.etsi.org/deliver/etsi_ts/119300_119399/119312/02.01.01_60/ts_119312v020101p.pdf)
-   [ETSI, LOTL et listes nationales](https://portal.etsi.org/TB-SiteMap/ESI/Trust-Service-Providers)
-   [Commission européenne, listes de confiance](https://digital-strategy.ec.europa.eu/en/policies/eu-trusted-lists)
-   [AGIL'IT, arrêt Ekofrukt](https://www.agilit.law/en/it-personal-data/signature-electronique-qualifiee-cjue/)

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

**NOTE.** 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.

### Sources

-   [Règlement (UE) n° 910/2014 consolidé (articles 35, 36, 45k, 45l)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX%3A02014R0910-20241018)
-   [ETSI TS 119 312 V2.1.1 (périmètre incluant les registres électroniques)](https://www.etsi.org/deliver/etsi_ts/119300_119399/119312/02.01.01_60/ts_119312v020101p.pdf)

### Sources

-   [Règlement (UE) 2024/1183 (eIDAS 2)](https://eur-lex.europa.eu/legal-content/FR/TXT/PDF/?uri=OJ:L_202401183)
-   [OpenID for Verifiable Presentations 1.0](https://openid.net/specs/openid-4-verifiable-presentations-1_0.html)
-   [OpenID4VC High Assurance Interoperability Profile 1.0](https://openid.net/specs/openid4vc-high-assurance-interoperability-profile-1_0.html)
-   [ETSI TS 119 312 V2.1.1 (2026-06)](https://www.etsi.org/deliver/etsi_ts/119300_119399/119312/02.01.01_60/ts_119312v020101p.pdf)
-   [FranceConnect, documentation partenaires](https://docs.partenaires.franceconnect.gouv.fr/fs/fs-technique/fs-technique-endpoints/)

Vous travaillez dans la signature, l'identité numérique ou la conformité ? Une correction ou un cas à ajouter est le bienvenu.[thomas@codethelaw.eu](mailto: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](https://codethelaw.eu/).

Version du 11 octobre 2026 · [SHA-256 acf4…6a6f](https://signature.codethelaw.eu/index.html.sha256 "HTML normalisé (emplacement de l’empreinte neutralisé) : acf4081895885b96c8399893641e2c2544f764a29b860b55452b4fa8aa746a6f. Cette empreinte identifie la version exacte de la page ; elle ne prouve pas à elle seule son authenticité.")