Document en vigueur Version 1.1 Mis à jour le 21 octobre 2026

SHAREID

NC — Public

Déclaration des pratiques du service de vérification d'identité à distance¶

Identity Proofing Service Practice Statement

ETSI TS 119 461 V2.1.1 — clause 9.2.3.4 et annexe C.3.4 | ETSI EN 319 401 V3.1.1 — REQ-6.1-03X

Référence	SID-ETSI-PS-IPS
Version	1.1
Date	21/10/2026
Statut	Première version publique Approuvé par le ComSec
Classification	NC — Public. Publiée sur compliance.shareid.ai (§2.1)
Propriétaire	CEO / Risk Manager
Approbation	Comité de sécurité (ComSec)
Service couvert	Identity proofing à distance automatisé de personnes physiques — ETSI TS 119 461 V2.1.1, clause 9.2.3.4 ; annexe C.3.4 pour l'émission de certificats qualifiés, au seul Extended LoIP (§3.1)
Niveaux de garantie	Baseline LoIP et Extended LoIP ; niveau visé fixé pour chaque donneur d'ordre, niveau atteint déterminé pour chaque parcours (§8.3)
Documents associés	SID-ETSI-POL-IPS (politique du service) ; SID-TRANSV-POL-PSSI ; SID-ETSI-RAP-ANALYSE-RISQUES (analyse de risques) ; SID-ETSI-RAP-ARCHITECTURE (architecture) ; SID-ETSI-PRO-VERIF-DOCUMENTAIRE (vérification documentaire) ; SID-ETSI-PLN-CESSATION-ACTIVITE (cessation) ; SID-TRANSV-PLN-PCA-PRA (continuité) ; SID-ETSI-CTR-DPA (accord de sous-traitance) ; critères d'acceptation des documents : annexe D

État des versions

1.0	Octobre 2026 — Version initiale.
1.1	21/10/2026 — Corrections issues de l'audit interne ETSI 2026, avant présentation au ComSec : valeurs FAR/FRR et références CLR (§9) ; durées des journaux (§6.10) ; CheckDoc et composants tiers (§6.14, §7.3) ; DG13 et résultat pseudonyme (§7.2.2) ; annexes A, C et D ; classification NC — Public.

Validation¶

Étape	Nom et fonction	Date et visa
Rédaction	CEO / Risk Manager	05/10/2026
Revue technique (§7, §8)	CTO	06/10/2026
Revue sécurité (§5, §6)	CISO	06/10/2026
Revue protection des données (§10)	Cabinet IPsynergies — DPO	23/10/2026
Approbation	ComSec — PV SID-TRANSV-RAP-COMSEC-2026-10-28	28/10/2026

1. Introduction¶

1.1 Objet¶

Le présent document est la déclaration des pratiques (Identity Proofing Service Practice Statement) de ShareID SAS. Il décrit les pratiques et procédures mises en œuvre par ShareID pour fournir son service d'identity proofing à distance et établit, exigence par exigence, leur conformité à l'ETSI TS 119 461 V2.1.1 pour les cas d'usage déclarés en section 3.

Il répond à OVR-6.1-01, qui rend applicable la clause 6.1 de l'ETSI EN 319 401 (notamment REQ-6.1-03X), à OVR-6.1-02 et OVR-6.1-03 relatives à l'identification des cas d'usage, et à COL-8.2.1-06X. La correspondance entre les exigences et les sections figure en annexe A. Sur toute question de conformité normative, la présente déclaration prévaut sur la politique du service SID-ETSI-POL-IPS.

1.2 Référentiels¶

Référentiel	Objet et statut dans le présent document
ETSI TS 119 461 V2.1.1 (2025-02)	Exigences applicables aux composants de services de confiance fournissant l'identity proofing — référentiel de la certification
ETSI EN 319 401 V3.1.1 (2024-06)	Exigences générales applicables aux prestataires de services de confiance, rendues applicables par les clauses 5, 6 et 7 de l'ETSI TS 119 461. Version retenue par l'organisme d'évaluation de la conformité (LSTI) pour l'évaluation du service. Les identifiants cités sont ceux de la V3.1.1 ; l'emplacement de chaque exigence est tenu dans SID-ETSI-REG-MATRICE-EXIGENCES.
Règlement LSTI Q084 V2.0	Règlement de certification de l'organisme d'évaluation
Règlement d'exécution (UE) 2026/798	Normes de référence pour l'enrôlement à distance aux portefeuilles européens d'identité numérique (article 5 bis, paragraphe 24, du règlement (UE) n° 910/2014). Non revendiquées ; les adaptations appliquées volontairement sont identifiées au §1.2.1.
Règlement (UE) n° 910/2014 modifié par le règlement (UE) 2024/1183	Article 24 (vérification de l'identité en vue de la délivrance de certificats qualifiés), auquel renvoie l'annexe C.3 de l'ETSI TS 119 461 : cadre du cas d'usage C.3.4 revendiqué (§3.1).
ISO/IEC 27001:2022	Système de management de la sécurité de l'information, certifié depuis 2024
Règlement (UE) 2016/679 (RGPD)	Protection des données à caractère personnel
ICAO Doc 9303, parties 10 et 11	Structure logique des données (partie 10) et mécanismes de sécurité (partie 11 : PACE, BAC, Chip Authentication, Active Authentication)
ISO/IEC 30107-3, ISO/IEC 19989-3, CEN/TS 18099, ISO/IEC 19795-1	Évaluation de la détection d'attaque de présentation, de la détection d'attaque par injection et des performances biométriques

1.2.1 Adaptations du règlement d'exécution (UE) 2026/798 appliquées volontairement¶

Le règlement d'exécution (UE) 2026/798 adapte certaines exigences de l'ETSI TS 119 461 pour l'enrôlement aux portefeuilles européens d'identité numérique. La présente déclaration n'en revendique pas la conformité ; un donneur d'ordre qui y est soumis en apprécie l'applicabilité à son contexte. ShareID en tient compte comme suit :

Adaptation (règlement 2026/798, annexe, section 2)	Prise en compte
INI-8.1-05 — explications et possibilités de solution en cas d'interruption ou d'échec	Appliquée volontairement (§7.1, §8.4).
USE-9.2.3.4-04 — cibles FAR et FRR établies par analyse de risques selon la méthode de l'ENISA, égales ou inférieures à celles des cas d'usage hybrides lorsqu'ils existent	Appliquée volontairement pour l'établissement des cibles (§9). Aucun cas d'usage hybride n'étant revendiqué, la borne relative à ces cas ne trouve pas à s'appliquer.
VAL-8.3.3-22 — image faciale de référence recueillie par NFC, authentification passive ou active de la puce	Appliquée volontairement ; satisfaite par l'extraction de la photographie de la puce et l'authentification passive systématique (§7.3).
Autres adaptations	Non retenues : elles sont propres au contexte d'enrôlement aux portefeuilles, dans lequel le service n'est pas fourni au titre de la présente déclaration. VAL-8.3.3-21 porte en outre sur la clause 8.3.3, non invoquée par le cas d'usage (§7.3).

1.3 Identification du document¶

Nom	Déclaration des pratiques du service de vérification d'identité à distance (Identity Proofing Service Practice Statement)
Référence et version	SID-ETSI-PS-IPS v1.1 — 21/10/2026 (ancienne référence SID-ETSI-PS-001)
Identifiants d'objet	Baseline LoIP : 0.4.0.19461.1.1 ; Extended LoIP : 0.4.0.19461.1.2 (ETSI TS 119 461, clause 4.6). Ils complètent la référence aux cas d'usage revendiqués (9.2.3.4 et C.3.4, §3.1) sans s'y substituer. Employés à compter de la délivrance du certificat de conformité (SID-ETSI-POL-IPS).
Révision	Annuelle, et lors de toute modification du service, du périmètre, des référentiels ou de l'analyse de risques (§2.2)

1.4 Participants¶

1.4.1 ShareID¶

ShareID SAS (RCS Nanterre 884 932 203 ; siège social : 20 bis rue Louis Philippe, 92200 Neuilly-sur-Seine ; bureaux d'exploitation : 5 rue Cadet, Paris) intervient en qualité d'IPSP (Identity Proofing Service Provider). L'identity proofing n'est pas en lui-même un service de confiance mais un composant de service de confiance (ETSI TS 119 461, annexe D). Conformément aux clauses 5, 6 et 7 de l'ETSI TS 119 461, ShareID applique à son service les exigences correspondantes de l'ETSI EN 319 401.

1.4.2 Donneurs d'ordre et scénarios d'intervention¶

ShareID fournit son service à des donneurs d'ordre : prestataires de services de confiance, établissements financiers, administrations, fournisseurs technologiques intégrant le composant à leur propre service. Le demandeur accède au parcours au travers de l'application du donneur d'ordre intégrant le SDK ShareID.

Scénario	Description	Responsabilité
A — Composant sous la responsabilité d'un prestataire de services de confiance	ShareID fournit le service comme composant intégré au service d'un prestataire client, qui définit la finalité, les attributs requis, les critères de fraîcheur (COL-8.2.1-07), les documents admis et le niveau de garantie requis.	Le prestataire porte la responsabilité du service de confiance et de la décision qu'il fonde sur le résultat ; il peut reprendre la conservation à long terme des preuves (OVR-7.10-01, note 1), la gestion de crise (OVR-7.11-02) et l'assistance aux plans de cessation (OVR-7.12-01, note). ShareID répond de la conformité du service aux pratiques déclarées.
B — Fourniture directe	ShareID fournit directement le service d'identity proofing à son client donneur d’ordre; ce donneur d'ordre n'est pas prestataire de services de confiance ; il définit le contexte, formalisé contractuellement avec ShareID.	ShareID porte l'ensemble des obligations attachées à la fourniture du service, y compris celles que le prestataire assume en scénario A.

L'architecture et les pratiques sont identiques dans les deux scénarios ; seule la répartition contractuelle des responsabilités diffère. Le donneur d'ordre décide de l'acceptation ou du refus final ; le résultat restitué par ShareID est un élément de cette décision. La qualification au regard du RGPD est déterminée indépendamment du scénario (§10.2).

Dans les deux scénarios, ShareID agit comme sous traitant du traitement au sens du RGPD. Il traite les données pour le compte du donneur d'ordre, responsable de traitement, dans le cadre de l'accord de sous-traitance (SID-ETSI-CTR-DPA ; §10.2).

1.4.3 Demandeurs¶

Personnes physiques dont l'identité est vérifiée. Le service ne couvre pas l'identity proofing de personnes morales ni de personnes physiques représentant une personne morale.

1.4.4 Organisme d'évaluation de la conformité¶

LSTI, organisme d'évaluation opérant selon le règlement de certification Q084 V2.0, évalue la conformité du service à l'ETSI TS 119 461 V2.1.1 (USE-9.1-01A). Les tests d'efficacité du composant biométrique sont réalisés par un laboratoire accrédité partenaire de LSTI (Q084, §4.5.3).

1.5 Contacts¶

Responsable du document	CEO / Risk Manager — contact@shareid.ai
Sécurité de l'information	CISO — security@shareid.ai
Protection des données	Cabinet IPsynergies, DPO externalisé — dpo@shareid.ai
Support et signalement d'incidents	https://support.shareid.net — support@shareid.ai

1.6 Définitions et abréviations¶

Terme	Définition
AA / CA	Active Authentication / Chip Authentication — mécanismes de détection du clonage de la puce (ICAO 9303, partie 11), portés par les groupes de données DG15 et DG14
APCER / BPCER	Taux de présentations d'attaque classées comme authentiques / taux de présentations authentiques rejetées (ISO/IEC 30107-3)
CSCA	Country Signing Certification Authority — autorité nationale signant les certificats des émetteurs de documents
DG	Groupe de données (Data Group) de la puce (ICAO 9303)
FAR / FRR	Taux de fausse acceptation / de faux rejet de la comparaison biométrique (ISO/IEC 19795-1)
IAD / PAD	Détection d'attaque par injection (CEN/TS 18099) / détection d'attaque de présentation (ISO/IEC 30107-3)
LoIP	Level of Identity Proofing — niveau de garantie, Baseline ou Extended
PA	Authentification passive — validation de la signature de l'émetteur sur le EF.SOD et les groupes de données
PACE / BAC	Protocoles d'établissement du canal sécurisé avec la puce (ICAO 9303, partie 11)
SDK Renforcé	Version du SDK natif ShareID intégrant la protection applicative (intégrité, détection de root, jailbreak, émulateur, débogage et hooking)
EF.SOD	Document Security Object — structure signée par l'émetteur contenant l'empreinte de chaque groupe de données

2. Publication, révision et maîtrise documentaire¶

2.1 Mise à disposition¶

La présente déclaration est publiée sur le site compliance.shareid.ai, accessible sans demande préalable, avec la politique du service SID-ETSI-POL-IPS ; elle est également communiquée à chaque donneur d'ordre dans le cadre contractuel et transmise aux organismes d'évaluation de la conformité (REQ-6.1-05X, REQ-6.2-03). Les aspects sensibles peuvent être retirés de la version communiquée (REQ-6.1-05X, note 2). L'information des demandeurs relève des écrans présentés à l'initiation du parcours (§7.1).

2.2 Révision et approbation¶

La déclaration est révisée au moins une fois par an lors de la revue de direction du comité de sécurité (ComSec : CEO, CTO et CISO, membres permanents ; DPO observateur, sans voix), et lors de toute modification du processus d'identity proofing, du périmètre de certification, des référentiels applicables ou de l'analyse de risques (REQ-6.1-08). La Risk Manager est responsable de sa tenue à jour et vérifie à chaque révision sa cohérence avec SID-ETSI-POL-IPS, l'analyse de risques, le schéma d'architecture, le SLA et l'accord de sous-traitance.

Toute révision est approuvée par le ComSec, organe de direction disposant de l'autorité finale d'approbation (REQ-6.1-06), selon les règles de quorum et de décision de SID-TRANSV-POL-PSSI, et consignée au procès-verbal. Lorsqu'une modification est susceptible d'affecter l'acceptation du service, les donneurs d'ordre en sont avisés avant son entrée en vigueur, avec le préavis prévu au contrat (REQ-6.1-09X). La version révisée est mise à disposition dès son approbation (REQ-6.1-10).

Notification des changements importants et de la cessation (REQ-6.3-04X). ShareID informe les donneurs d'ordre de toute modification importante de la fourniture du service et de son intention d'y mettre fin, avant leur prise d'effet, avec les préavis prévus par les conditions générales (SID-ETSI-CTR-CGUV, articles 10 et 25.3).

2.3 Maîtrise documentaire¶

La déclaration est versionnée, datée et approuvée conformément à la clause 7.5 de l'ISO/IEC 27001:2022 et à la procédure de maîtrise des informations documentées du SMSI (SID-TRANSV-PRO-MAITRISE-DOCUMENTS). Elle est inscrite au plan documentaire de la PSSI et à la liste maîtresse des documents du SMSI. Les versions remplacées sont archivées.

3. Cas d'usage, preuves et contextes déclarés¶

3.1 Cas d'usage pour lesquels la conformité est revendiquée¶

Conformément à OVR-6.1-02, OVR-6.1-03 et COL-8.2.1-06X, ShareID revendique la conformité pour les cas d'usage suivants :

Clause	Titre officiel	Canaux	Niveaux de garantie	Mode opératoire
9.2.3.4	Use case for automated operation	Android et iOS (SDK natif ShareID en version Renforcée)	Baseline LoIP et Extended LoIP, niveau visé fixé par le contexte, niveau atteint déterminé par parcours (§8.3)	Entièrement automatisé, sans intervention humaine dans la vérification d'identité
Annexe C.3.4	Use case for identity proofing by other identification means	Android et iOS (SDK natif ShareID en version Renforcée)	Extended LoIP uniquement (QTS-C.3.4-03, QTS-C.3.4-04) ; un résultat au Baseline LoIP ne relève pas de ce cas d'usage	Mise en œuvre par le cas d'usage 9.2.3.4, sans parcours ni contrôle supplémentaire, pour la délivrance de certificats qualifiés

Aucun autre cas d'usage de la clause 9 ou de l'annexe C de l'ETSI TS 119 461 n'est revendiqué, notamment ceux de l'annexe C.2 (régime de l'article 24.1 du règlement eIDAS d'origine), et le cas d'usage C.3.4 n'est revendiqué que pour la délivrance de certificats qualifiés. Le canal Web n'est pas couvert, la lecture de la puce nécessitant le contrôleur NFC du terminal.

Cas d'usage C.3.4. L'annexe C.3.4 s'applique lorsque l'identity proofing est réalisé, en vue de la délivrance d'un certificat qualifié, par d'autres moyens d'identification au sens de l'article 24 du règlement (UE) n° 910/2014 modifié auquel elle renvoie. Pour l'identity proofing à distance non accompagné fondé sur un document d'identité, elle rend applicables les exigences de l'Extended LoIP de la clause 9.2.3.1 (QTS-C.3.4-03) et de la clause 9.2.3.3 ou 9.2.3.4 (QTS-C.3.4-04). ShareID y satisfait par le cas d'usage 9.2.3.4, décrit en section 8. Seuls les résultats au niveau Extended LoIP relèvent de ce cas d'usage ; le donneur d'ordre qui délivre des certificats qualifiés retient le niveau visé Extended LoIP (§8.3). QTS-C.3.4-01 et QTS-C.3.4-02 (identity proofing à distance accompagné), QTS-C.3.4-05 et QTS-C.3.4-06 (renforcement d'un identity proofing fondé sur un moyen d'identification électronique) sont sans objet. Le traitement des attributs autres que l'identité unique (QTS-C.3.4-07) est décrit au §7.2.2. Le prestataire de services de confiance qualifié reste soumis à sa propre évaluation de conformité (scénario A, §1.4.2). QTS-C.3.4-08 exige que la conformité de la méthode à l'annexe C.3.4 soit confirmée par un organisme d'évaluation de la conformité : ShareID demande que le périmètre de l'évaluation conduite par LSTI inclue ce cas d'usage.

3.2 Preuves admises¶

Type de preuve	Admission	Fondement
Preuve autoritaire	Document d'identité digital eMRTD conforme à l'ICAO 9303 partie 10 : passeport, carte d'identité ou titre de séjour doté d'une puce sans contact signée et lisible	COL-8.2.3-06X, USE-9.2.3.4-01X
Liste des documents acceptés	Annexe D : types de documents et critères d'acceptation ; liste des modèles dans le catalogue de couverture, à diffusion restreinte	COL-8.2.3-03X, COL-8.2.1-06X
Documents exclus	Documents sans puce ; documents dont la législation restreint l'accès à la puce ; permis de conduire (hors ICAO 9303 partie 10, choix ShareID);	COL-8.2.3-06X, VAL-8.3.1-07, clause 8.3.2 note 1
Preuves complémentaires	Aucune : registres de confiance, preuves d'accès, documents et attestations, autres documents d'identité, moyens d'identification électronique et moyens de signature existants ne sont pas utilisés	USE-9.2.3.1-07 à USE-9.2.3.1-10 (facultés non exercées)

3.3 Contextes d'identity proofing¶

Les contextes d'emploi et leurs conditions d'applicabilité sont décrits dans la politique du service (SID-ETSI-POL-IPS) :

émission de certificats qualifiés, pour laquelle seuls les résultats au niveau Extended LoIP sont utilisables (cas d'usage C.3.4 revendiqué, §3.1 ; QTS-C.3.4-03 et QTS-C.3.4-04) ;
connaissance du client à distance au titre de la lutte contre le blanchiment et le financement du terrorisme ;
accès à des services publics en ligne ;
entrée en relation et ouverture de compte hors obligation réglementaire spécifique.
Lutte contre la fraude à l’identité lors d’opérations en ligne

Le jeu d'attributs restitué est identique pour tous les contextes (COL-8.2.1-01X, §7.2.2) ; pour chaque contexte, les documents admis parmi ceux de l'annexe D (COL-8.2.3-03X) et le niveau de garantie requis, qui détermine le niveau visé (§8.3), sont définis par le responsable du traitement, le donneur d'ordre dans les deux scénarios, qui vérifie que ce jeu d'attributs correspond à son contexte et ne conserve que les attributs nécessaires à sa finalité (COL-8.2.2.1-03). Le moyen de collecte des attributs est, dans tous les contextes, la lecture de la puce du document digital (COL-8.2.2.1-01X). Les contextes exigeant une présence physique, une intervention humaine dans la vérification, une autre preuve autoritaire ou des attributs non portés par la puce ne sont pas couverts (SID-ETSI-POL-IPS).

Les attributs sont extraits de la puce et sont donc couverts par la signature de l'autorité émettrice. Tous les attributs lus dans la puce sont restitués : les attributs obligatoires, toujours présents, et les attributs facultatifs, restitués dès lors qu'ils figurent dans la puce (COL-8.2.1-01X) ; la photographie est restituée sauf si le donneur d'ordre choisit, lors de l'initiation de sa requête de vérification d'identité, de ne pas la recevoir. Leur détail figure au §7.2.2.

Attributs	Statut	Contextes
Nom, prénoms, sexe, date de naissance, nationalité, type et numéro du document, date d’expiration	Obligatoires (identification unique, COL-8.2.1-02)	Tous les contextes
Lieu de naissance	Facultatif : restitué lorsqu'il figure dans la puce ; si le contexte du donneur d'ordre l'exige (annexe B de l'ETSI TS 119 461) et que la puce ne le porte pas, sa collecte relève du donneur d'ordre (§3.2)	Tous les contextes
État émetteur, autorité et date de délivrance, adresse, nom complet	Facultatifs, restitués au responsable du traitement lorsqu’ils sont disponibles	Tous les contextes
Photographie (DG2)	Toujours lue et utilisée pour la liaison ; restituée sauf si le donneur d'ordre choisit, lors de l'initiation de sa requête, de ne pas la recevoir	Tous les contextes

Le paramétrage retenu pour chaque donneur d'ordre (contexte, documents admis, paramétrage du niveau visé) est consigné dans l'Offre ; le niveau visé et la restitution de la photographie sont choisis par le donneur d'ordre lors de l'initiation de chaque requête de vérification d'identité (§8.3).

4. Analyse de risques et veille sur les menaces¶

4.1 Analyse de risques opérationnels¶

ShareID maintient une analyse de risques formalisée, SID-ETSI-RAP-ANALYSE-RISQUES, qui couvre les risques de fraude à l'identité et les risques de sécurité des systèmes d'information (OVR-5-03 a et b ; REQ-5-01). Elle suit les tâches du processus défini à la clause 4.2 de la norme et couvre les menaces de l'annexe B applicables au cas d'usage 9.2.3.4, y compris lorsqu'il est mis en œuvre au titre du cas d'usage C.3.4 . Les mesures de traitement retenues sont décrites dans la présente déclaration et dans la PSSI (REQ-5-02, REQ-5-03).

Exigence	Mise en œuvre
OVR-5-07	Baseline LoIP : attaquants à potentiel d'attaque au moins modéré
OVR-5-08	Extended LoIP : attaquants à potentiel d'attaque au moins élevé — IA générative temps réel, clonage de puce, masques haute fidélité, injection au niveau du système d'exploitation
OVR-5-02, REQ-5-04	Révision annuelle (prochaine révision : septembre 2027)
OVR-5-04, OVR-5-06	Mise à jour à toute modification du processus et selon les constats de la veille
REQ-5-05	Approbation de l'analyse et acceptation formelle des risques résiduels par la direction

4.2 Veille sur les menaces¶

La procédure documentée de veille (OVR-5-05) figure dans le document SID-TRANSV-PRO-VEILLE-MENACES

Toute menace nouvelle déclenche la revue de l'analyse de risques (OVR-5-06) et le cas échéant, la révision des objectifs de performance (BIN-8.4.2-05E, BIN-8.4.3-05B), la mise à jour des moyens de détection d'attaque par injection (BIN-8.4.2-04D, note 8) et l'évaluation du besoin de formation du personnel (OVR-5-09).

5. Politiques et conditions¶

5.1 Déclaration des pratiques (OVR-6.1-01)¶

Le présent document constitue la déclaration des pratiques de ShareID au sens de la clause 6.1 de l'ETSI EN 319 401 (REQ-6.1-03X). Il forme, avec la politique du service SID-ETSI-POL-IPS, la PSSI SID-TRANSV-POL-PSSI, le plan de cessation SID-ETSI-PLN-CESSATION-ACTIVITE, l'accord de sous-traitance SID-ETSI-CTR-DPA et les conditions générales, l'ensemble des politiques et pratiques du service (REQ-6.1-01). La direction met en œuvre les pratiques décrites (REQ-6.1-07). Les obligations des organisations externes sont identifiées au §6.14 (REQ-6.1-04) ; les dispositions de cessation d'activité au §6.12 (REQ-6.1-11).

5.2 Conditions générales (OVR-6.2-01)¶

Les conditions applicables au service sont portées par les documents contractuels conclus avec chaque donneur d'ordre, communiqués avant la contractualisation et à toute partie utilisatrice qui en fait la demande, sur support durable et en langue française. Les documents peuvent être produits en anglais sur demande du client. (REQ-6.2-03 à REQ-6.2-05) :

conditions générales d'utilisation et de vente du service SID-ETSI-CTR-CGUV ;
engagement de niveau de service SID-ETSI-CTR-SLA, annexe 1 de la Commande ;
plan de continuité et de reprise d'activité SID-TRANSV-PLN-PCA-PRA, annexe 2 de la Commande ;
accord de sous-traitance (DPA) SID-ETSI-CTR-DPA au sens de l'article 28 du RGPD, annexe 3 de la Commande.

Correspondance avec les éléments exigés par REQ-6.2-02 :

Élément (REQ-6.2-02)	Document et section
a) politique appliquée ; i) statut d'évaluation de conformité	Conditions générales : identification de l'offre couverte par la certification (clause 9.2.3.4) et du schéma d'évaluation (LSTI, Q084)
b) limitations d'emploi ; f) limitations de responsabilité ; g) droit applicable	Conditions générales ; SID-ETSI-POL-IPS (limitations)
c) obligations du donneur d'ordre ; d) information des parties utilisatrices	Conditions générales ; SID-ETSI-POL-IPS ; présente déclaration (§1.4.2, §7.5.1)
e) durée de conservation des journaux	Présente déclaration (§6.10)
h) réclamations et litiges	Présente déclaration (§10.5)
j) coordonnées ; k) disponibilité	Présente déclaration (§1.5) ; SLA

Les conditions présentées au demandeur, qu'il accepte activement avant le début du parcours, relèvent du contexte d'identity proofing (INI-8.1-01X ; note de la clause 6.2 de l'ETSI TS 119 461). Les documents contractuels identifient explicitement la prestation couverte par la certification et la distinguent des autres prestations.

5.3 Politique de sécurité de l'information (OVR-6.3-01)¶

La politique de sécurité du système d'information SID-TRANSV-POL-PSSI, approuvée par la direction, s'applique au service (REQ-6.3-01). Elle s'appuie sur le système de management de la sécurité de l'information certifié ISO/IEC 27001:2022 et sur les politiques associées : contrôle d'accès, cryptographie, sécurité des opérations (SID-TRANSV-POL-SECURITE-OPERATIONS), développement sécurisé, gestion des risques, gestion des tiers, gestion des données, continuité d'activité. Elle est communiquée au personnel (REQ-6.3-05X) et revue au moins annuellement par le ComSec, avec l'inventaire des actifs (REQ-6.3-06X). Les modifications affectant le niveau de sécurité sont approuvées par le ComSec (REQ-6.3-07X).

La configuration des systèmes est contrôlée par des contrôles d'admission et des politiques, par l'analyse continue des images et des déploiements, ainsi que par des contrôles de conformité du cluster Kubernetes (audits de configuration et conformité CIS via Trivy Operator), afin de détecter les écarts à la politique de sécurité (REQ-6.3-08X ; SID-TRANSV-POL-SECURITE-OPERATIONS). L'intervalle maximal entre deux contrôles est de 24 heures (REQ-6.3-09X).

6. Gestion et exploitation du service¶

La présente section couvre les clauses 7.1 à 7.14 de l'ETSI TS 119 461, qui rendent applicables les clauses correspondantes de l'ETSI EN 319 401, et renvoie aux documents du système de management qui les détaillent.

6.1 Organisation interne (OVR-7.1-01)¶

La gouvernance du service est assurée par la direction : la CEO, également Risk Manager, est propriétaire du dispositif ; le CTO est responsable de la plateforme ; le CISO pilote la sécurité de l'information et rend compte à la direction (REQ-7.2-03X) ; le DPO externalisé conseille sur la protection des données. Le ComSec réunit la CEO, le CTO et le CISO, membres permanents, le DPO y assistant en observateur, et tient une revue de direction au moins annuelle (SID-TRANSV-POL-ROLES-SMSI).

Les pratiques du service sont non discriminatoires (REQ-7.1.1-02) : le service est accessible à tout donneur d'ordre relevant de son champ et acceptant les conditions contractuelles (REQ-7.1.1-03). ShareID dispose des ressources financières nécessaires à l'exploitation du service conformément aux exigences et d'une assurance de responsabilité civile professionnelle couvrant les risques liés à ses activités (REQ-7.1.1-04, REQ-7.1.1-05). Les réclamations et litiges sont traités selon le §10.5 (REQ-7.1.1-06).

Les fonctions conflictuelles sont séparées (REQ-7.1.2-01) : la matrice des habilitations des rôles de confiance attribue les droits sur chaque composant du service ; le rôle d'auditeur système est distinct des rôles d'administration ; les droits d'administration du responsable de la sécurité sont limités à ce qu'exige sa fonction et journalisés.

6.2 Ressources humaines et rôles de confiance (OVR-7.2-01)¶

L'absence d'opérateur humain concerne la vérification d'identité. Les rôles de confiance d'exploitation et de sécurité exigés par REQ-7.2-14X sont définis comme suit :

Rôle de confiance	Responsabilités	Titulaire
Responsable de la sécurité	Administration de la mise en œuvre des pratiques de sécurité, gestion des incidents, revue des droits	Fonction désignée dans SID-ETSI-REG-HABILITATIONS
Administrateur système	Installation, configuration, maintenance et restauration des systèmes du service	Fonction désignée dans SID-ETSI-REG-HABILITATIONS
Opérateur système	Exploitation courante, supervision, sauvegardes	Fonction désignée dans SID-ETSI-REG-HABILITATIONS
Auditeur système	Consultation des archives et des journaux d'audit	Fonction désignée dans SID-ETSI-REG-HABILITATIONS, distincte des administrateurs

Les titulaires des rôles de confiance sont nommés formellement par la direction responsable de la sécurité et acceptent leur rôle par écrit (REQ-7.2-15X, REQ-7.2-16X) ; ils n'accèdent aux fonctions de confiance qu'après les vérifications requises (REQ-7.2-17) et déclarent l'absence de conflit d'intérêts (REQ-7.2-13X). Les titulaires sont désignés par fonction dans SID-ETSI-REG-HABILITATIONS ; les actes de nomination nominatifs, signés, sont conservés par le CEO et tenus à jour.

Le personnel est soumis aux mesures de la PSSI (§5.3) et du plan d'assurance sécurité : extrait de casier judiciaire vierge avant embauche puis tous les deux ans, clause de confidentialité et charte informatique signées, sensibilisation annuelle à la sécurité et à la protection des données (REQ-7.2-02, REQ-7.2-05X), procédures d'arrivée et de départ avec révocation dans les 24 heures des accès au départ. Des sanctions disciplinaires s'appliquent en cas de violation des politiques (REQ-7.2-06X). La formation est adaptée selon les constats de la veille (OVR-5-09).

Le travail à distance est encadré par la charte de télétravail SID-TRANSV-CHA-TELETRAVAIL et par l'accès obligatoire au travers du VPN d'entreprise (REQ-7.2-18X, REQ-7.2-19X).

6.3 Gestion des actifs (OVR-7.3-01)¶

Les actifs des plateformes et des postes de travail sont identifiés et inventoriés. L'information est classifiée selon quatre niveaux (C3 — Confidentiel, C2 — Restricted, C1 — Interne, NC — Public ; SID-TRANSV-POL-CLASSIFICATION-DONNEES), appliqués aux supports et aux données, sous surveillance continue de la plateforme de conformité (SID-TRANSV-POL-PSSI). L'inventaire des actifs du service recense les composants logiciels, bases de données, magasin de certificats CSCA, clés et services tiers (REQ-7.3.2-01X).

6.4 Contrôle d'accès (OVR-7.4-01)¶

Chaque utilisateur est identifié par un identifiant unique et une authentification multifacteur. Les droits suivent le principe du moindre privilège (RBAC) ; ils sont revus trimestriellement pour les comptes privilégiés, d'administration et de production, et au moins une fois par an pour les autres comptes (SID-TRANSV-POL-CONTROLE-ACCES) ; l'accès des personnels non permanents est limité à la durée d'affectation. L'accès à l'infrastructure s'effectue uniquement au travers du VPN Zero Trust de l'entreprise ; les accès d'administration sont journalisés.

6.5 Mesures cryptographiques (OVR-7.5-01)¶

Les flux sont chiffrés en TLS 1.3 (TLS 1.2 au minimum), sur le seul port 443 ; les SDK mettent en œuvre l'épinglage de certificats. Les données au repos sont chiffrées : volumes de blocs chiffrés LUKS (AES), stockage objet chiffré côté fournisseur, clés de service gérées par OVHcloud (SID-TRANSV-POL-PSSI). Les secrets sont centralisés dans OpenBao, avec journalisation de tous les accès ; aucun secret n'est présent dans le code. La rotation des secrets et des clés est définie par la politique cryptographique. Le résultat transmis au donneur d'ordre par rappel serveur est authentifié par HMAC-SHA256.

6.6 Sécurité physique et environnementale (OVR-7.6-01)¶

Le service est hébergé par OVHcloud, dont la sécurité physique est certifiée ISO/IEC 27001 : site principal Paris (région EU-WEST-PAR, trois zones de disponibilité), site de reprise Roubaix (RBX-A). Les locaux de ShareID sont protégés par un contrôle d'accès nominatif et tracé.

6.7 Sécurité des opérations (OVR-7.7-01)¶

Les procédures d'exploitation sont documentées. La supervision de l'infrastructure et des services est continue, avec alertes automatiques et escalade 24 heures sur 24 selon la sévérité (SID-TRANSV-POL-PSSI). Les serveurs et postes sont protégés contre les logiciels malveillants. Les mises à jour sont validées en préproduction, soumises à approbation humaine avant mise en production, puis déployées sans interruption avec procédure de retour arrière. Le développement intègre la sécurité : règles OWASP Top 10, détection de secrets et analyse des dépendances dans la chaîne d'intégration continue, règle de non-régression des modèles d'intelligence artificielle. Les vulnérabilités des images sont analysées en continu.

Un test d'intrusion est réalisé par un prestataire disposant des compétences et de l'indépendance requises, selon la politique de tests de sécurité (SID-TRANSV-POL-DEV-SECURISE) : le premier test externe du service est planifié au plan de traitement des risques, puis renouvelé au moins une fois par an et après tout changement significatif ; les constats font l'objet d'un plan d'action suivi (REQ-7.8-17X à REQ-7.8-19X).

6.8 Sécurité des réseaux (OVR-7.8-01, OVR-7.8-02)¶

L'architecture suit les principes Zero Trust et de moindre privilège ; les flux entre composants sont contrôlés par des règles réseau, et tous les accès transitent par des pare-feux, avec analyse continue des flux. La production est hébergée sur un cluster distinct des environnements non productifs. Le système qui prend la décision d'identity proofing est logiquement séparé des systèmes non critiques (OVR-7.8-02) : cluster et espaces de noms dédiés, contrôle d'accès strict, accès d'administration contrôlés et journalisés.

6.9 Vulnérabilités et incidents (OVR-7.9-01, OVR-7.9-02)¶

La gestion des incidents suit SID-TRANSV-PLN-REPONSE-INCIDENTS : quatre niveaux de sévérité, cellule de crise pour tout incident critique, analyse de cause racine et retour d'expérience. Le personnel, les donneurs d'ordre et les prestataires signalent tout incident au support (support@shareid.ai), procédure communiquée aux donneurs d'ordre (REQ-7.9.3-03X, REQ-7.9.3-04X). Les vulnérabilités sont suivies en continu sur la pile technique.

En qualité de sous-traitant, ShareID notifie au donneur d'ordre toute violation de données à caractère personnel dans les quarante-huit heures suivant sa prise de connaissance, avec les informations nécessaires à ses propres obligations au titre de l'article 33 du RGPD (SID-ETSI-CTR-DPA). Tout incident de sécurité ou perte d'intégrité ayant un impact significatif sur le service est notifié au donneur d'ordre dans les 24 heures suivant son identification. Conformément à OVR-7.9-02, les obligations de signalement de REQ-7.9.2-02X et de la clause 7.9.3 de l'ETSI EN 319 401 sont exercées selon le contexte et les obligations du donneur d'ordre, le cas échéant en coopération avec lui auprès de son autorité de contrôle.

SID-TRANSV-PLN-REPONSE-INCIDENTS, le plan d'assurance sécurité et la PSSI décrivent ces obligations de notification de ShareID en qualité de sous-traitant.

6.10 Collecte et conservation des preuves, journalisation (OVR-7.10-01)¶

Les preuves du processus d'identity proofing sont décrites au §7.5.2 ; la conservation à long terme au-delà de la durée convenue peut relever du donneur d'ordre prestataire de services de confiance (scénario A) après restitution du dossier (OVR-7.10-01, note 1). En scénario B, le donneur d'ordre n'étant pas prestataire de services de confiance, cette note ne s'applique pas : ShareID conserve le dossier de preuve pendant la durée fixée par le contexte et convenue contractuellement, notifiée dans les conditions générales (ISS-8.5.2-04, REQ-7.10-07), et le restitue au donneur d'ordre sur sa demande.

Les journaux techniques et d'accès ne contiennent pas de donnée personnelle. Les journaux d'événements sont conservés cinq ans par défaut, durée portée au plus à dix ans lorsque le contexte l'exige ; les journaux de sécurité sont conservés treize mois et les journaux d'exploitation courants au moins trente jours (SID-TRANSV-POL-JOURNALISATION), et portée à la connaissance des donneurs d'ordre dans les conditions générales (REQ-6.2-02 e, REQ-7.10-07). Aucune donnée à caractère personnel du demandeur n'est conservée dans les journaux au-delà de la durée de conservation du dossier de preuve (ISS-8.5.2-08).

Les journaux sont horodatés sur une heure synchronisée avec UTC au moins quotidiennement (REQ-7.10-06) et protégés contre la suppression et la modification pendant leur durée de conservation (REQ-7.10-08).

6.11 Continuité d'activité (OVR-7.11-01, OVR-7.11-02)¶

Le plan de continuité et de reprise d'activité SID-TRANSV-PLN-PCA-PRA repose sur une redondance active sur trois zones OVHcloud à Paris et un site de reprise à Roubaix, avec réplication des données en temps réel, sauvegardes horaires des bases de données, un objectif de perte de données maximale (RPO) de 90 minutes et un délai de reprise (RTO) de 3 heures. Il est testé au moins annuellement. La gestion de crise est adaptée au contexte et aux obligations du donneur d'ordre (OVR-7.11-02).

Les données de preuve sont sauvegardées dans la limite de la durée de conservation paramétrée, de sorte que la re-vérification reste possible pendant toute cette durée (ISS-8.5.2-07). Les données ayant servi à l'analyse suivent les mêmes durées de conservation, qu'elles aient été restituées au donneur d'ordre ou non. Les données supprimées des bases de données à l'échéance de leur conservation subsistent au plus quatorze jours dans les sauvegardes chiffrées, puis en disparaissent.

6.12 Cessation d'activité (OVR-7.12-01, REQ-7.12-10)¶

Les exigences de la clause 7.12 de l'ETSI EN 319 401 s'appliquent, à l'exception de REQ-7.12-11. En cas de cessation du service :

les donneurs d'ordre, les parties avec lesquelles ShareID a des accords et, le cas échéant, les autorités concernées sont informés préalablement, avec le préavis prévu au contrat (REQ-7.12-03, REQ-7.12-10 a) ;
les dossiers de preuve encore en conservation sont restitués aux donneurs d'ordre, qui reprennent l'obligation de conservation (REQ-7.12-06, REQ-7.12-10 b ; OVR-7.10-01, note 1) ;
les autorisations des sous-traitants prennent fin (REQ-7.12-05) ;
les données des demandeurs sont détruites de manière sécurisée dans un délai de trente jours ouvrés (SID-ETSI-CTR-DPA) et les clés sont retirées d'usage (REQ-7.12-07).

L'assistance mutuelle avec les donneurs d'ordre prestataires de services de confiance peut être convenue contractuellement (note de OVR-7.12-01). Ces dispositions sont détaillées dans le plan de cessation d'activité SID-ETSI-PLN-CESSATION-ACTIVITE, qui couvre également la couverture des coûts de cessation (REQ-7.12-09) et sa tenue à jour (REQ-7.12-02).

6.13 Conformité (OVR-7.13-01)¶

Référentiel	Statut
ISO/IEC 27001:2022	Certifié depuis 2024 ; audits annuels de surveillance
ISO/IEC 30107-3 et ISO/IEC 19989-3 (PAD)	Certifié niveau High par CLR Cert — valide jusqu'au 16/08/2028
CEN/TS 18099 (IAD) — iOS	Certifié niveau High par CLR Cert — valide jusqu'au 18/08/2028
CEN/TS 18099 (IAD) — Android	Certifié niveau High par CLR Cert — valide jusqu'au 25/10/2028
ETSI TS 119 461 V2.1.1	Évaluation de conformité en cours par LSTI
SOC 2	Démarche en cours ; aucune attestation obtenue
RGPD	DPO externalisé, registre des traitements tenu en qualité de sous-traitant pour le service, analyses d'impact

Les exigences légales, réglementaires et contractuelles applicables sont identifiées et tenues à jour dans le registre du SMSI (SID-TRANSV-REG-EXIGENCES-LEGALES). Tant que la certification ETSI n'est pas délivrée, ShareID ne revendique pas la conformité certifiée.

6.14 Chaîne d'approvisionnement et organisations externes (OVR-7.14-01, REQ-6.1-04)¶

Les fournisseurs sont sélectionnés et suivis selon la politique de gestion des tiers du SMSI : évaluation de sécurité avant contractualisation, engagements de niveau de service, suivi et réévaluation périodiques.

Organisation	Rôle dans le service	Obligations et garanties
OVHcloud	Hébergement et infrastructure (Paris, Roubaix) ; sous-traitant ultérieur au sens du RGPD	ISO/IEC 27001 ; disponibilité de 99,99 % des serveurs et clusters (SLA)
CLR Labs / CLR Cert	Évaluation et certification de la PAD et de l'IAD	Laboratoire accrédité ; réévaluation au moins tous les deux ans (BIN-8.4.2-04D, BIN-8.4.2-07A)
Promon	Composant de protection applicative intégré au SDK Renforcé	Mise à jour du composant ; détection des environnements compromis (§7.3)
Sources de certificats CSCA	Alimentation du magasin de certificats de l'authentification passive	Listes maîtresses publiées par des États, mises à jour mensuellement (SID-ETSI-RAP-ANALYSE-RISQUES)
Google Cloud Platform (Cloud DNS)	Résolution DNS publique des noms de domaine du service ; aucune donnée du service n'y est hébergée ni traitée	Engagements de disponibilité du service DNS ; certifications ISO/IEC 27001 du fournisseur
CheckDoc	Service de statut en ligne des documents belges : demande d'accès en cours	Garanties contractuelles et localisation des données inscrites au registre des fournisseurs (SID-TRANSV-REG-FOURNISSEURS) à la conclusion de l'accès
DocVerif	Service de statut en ligne des documents français : demande initiale refusée.	L'accès ne peut être demandé que par le responsable du traitement ; ShareID peut ensuite intervenir pour son compte en qualité de sous-traitant (SID-ETSI-POL-IPS)
Vanta	Plateforme de conformité du SMSI (suivi des contrôles, preuves, documents) ; aucune donnée des demandeurs	Certifications du fournisseur suivies dans SID-TRANSV-REG-FOURNISSEURS

La liste des sous-traitants ultérieurs du service est annexée à l'accord de sous-traitance ; tout ajout ou remplacement est notifié préalablement au client, qui peut s'y opposer (SID-ETSI-CTR-DPA). ShareID n'intègre aucun composant de service de confiance fourni par un tiers (ETSI EN 319 401, REQ-7.14.3-05X, REQ-7.14.3-06X sans objet).

7. Service d'identity proofing¶

La présente section décrit la mise en œuvre des exigences de la clause 8 de l'ETSI TS 119 461 applicables au cas d'usage 9.2.3.4 : initiation, collecte, validation, liaison au demandeur et émission du résultat.

7.1 Initiation (clause 8.1)¶

Exigence	Mise en œuvre
INI-8.1-01X	Avant le début du parcours, le demandeur est informé de la finalité et des conditions applicables, définies par le responsable du contexte, et les accepte activement.
INI-8.1-02X (recommandation)	Sans objet : le service ne comporte qu'un parcours.
INI-8.1-03X	Le demandeur est guidé sur le déroulement du parcours, les données collectées, les données conservées et leur durée, le document à présenter et l'outil requis (application intégrant le SDK, terminal doté du NFC, §8.2).
INI-8.1-04	Évaluation de l'accessibilité du SDK et du parcours au regard de l'EN 301 549 (niveau AA des WCAG 2.1). Les écarts relevés font l'objet d'un plan d'action daté, suivi dans le plan de traitement des risques (SID-ETSI-PLN-TRAITEMENT-RISQUES). La grille d'évaluation (annexe C) et la déclaration d'accessibilité sont tenues à la disposition des donneurs d'ordre et de l'organisme d'évaluation de la conformité (SID-ETSI-POL-IPS).
INI-8.1-05 (règlement 2026/798, appliquée volontairement)	En cas d'échec ou d'abandon, le demandeur reçoit des explications et des possibilités de solution, selon le niveau de détail défini au §8.4, et l'indication des voies de recours auprès du responsable de traitement.

Chaque parcours est ouvert par le serveur du donneur d'ordre, qui obtient par l'API un jeton à usage unique transmis au SDK ; la session reçoit un identifiant unique non réutilisable.

7.2 Collecte des attributs et des preuves (clause 8.2)¶

7.2.1 Exigences générales¶

Exigence	Mise en œuvre
COL-8.2.1-01X, 01A	Un jeu unique d'attributs, identique pour tous les contextes, est défini (§7.2.2) : attributs obligatoires et attributs facultatifs restitués dès lors qu'ils figurent dans la puce ; tous les attributs obligatoires sont collectés.
COL-8.2.1-02	Les attributs collectés assurent l'identification unique du demandeur dans le contexte (§7.2.2).
COL-8.2.1-03X	Les attributs sont validés par une preuve autoritaire : le document d'identité numérique.
COL-8.2.1-04, 05	Seuls les documents de l'annexe D admis par le contexte, émis par des autorités dont le certificat CSCA figure au magasin de ShareID, sont acceptés.
COL-8.2.1-06X	Cas d'usage, preuves et contextes identifiés en section 3.
COL-8.2.1-07	La date d'émission, la période de validité et le numéro du document sont restitués ; la fraîcheur est appréciée par le responsable du traitement au regard de ses propres critères ; ShareID applique au minimum le rejet des documents expirés (VAL-8.3.1-07).

7.2.2 Attributs collectés (clause 8.2.2.1)¶

Lorsque le document ne fait pas partie des documents restreints, les attributs sont extraits de la puce du document digital (COL-8.2.2.1-01X), à partir des groupes de données définis par l'ICAO 9303, et sont donc couverts par la signature de l'autorité émettrice :

toujours disponibles (DG1) : type et numéro du document, État émetteur, nom, prénoms, nationalité, date de naissance, sexe, date d'expiration ;
selon le document (DG11, DG12 et DG13) : lieu de naissance, nom complet, adresse, autorité et date de délivrance, détails nationaux optionnels, lorsqu'ils figurent sur la puce ;
Toujours disponible photographie (DG2) : utilisée pour la comparaison faciale, restituée au donneur d'ordre, sauf s'il choisit, lors de l’initiation de sa requête de vérification d’identité, de ne pas la recevoir.

Les nom et prénoms sont toujours collectés (COL-8.2.2.1-02) ; le service ne délivre pas de résultat pseudonyme (COL-8.2.2.1-02A). L'identification unique repose sur le nom, les prénoms, la date de naissance, la nationalité et le numéro du document ; le lieu de naissance, lorsqu'il figure dans la puce, complète ces attributs (annexe B de la norme, T_DOC_IMPRECISE). Tous les attributs lus dans la puce sont restitués ; la photographie, toujours lue pour la liaison au demandeur, n'est pas restituée lorsque le donneur d'ordre le demande, ce qu'autorise COL-8.2.2.1-04. Le SDK ne lit pas l'image de la signature (DG7) ; la zone optionnelle du DG1, lorsqu'elle est renseignée, est restituée comme les autres attributs.

Attributs autres que l'identité unique (QTS-C.3.4-07). Lorsque le service est mis en œuvre au titre du cas d'usage C.3.4, les attributs restitués au-delà de l'identité unique du demandeur sont extraits de la puce et validés au cours du même processus ; ils relèvent donc du cas d'usage C.3.4. Tout autre attribut requis pour le certificat qualifié relève du prestataire de services de confiance qualifié, par l'un des moyens prévus par QTS-C.3.4-07, et n'est pas couvert par le service (§3.2).

7.2.3 Collecte du document digital (clause 8.2.3)¶

Le document est présenté physiquement par le demandeur ; sa puce est lue par le terminal. Seuls les documents eMRTD conformes à l'ICAO 9303 partie 10 sont admis (COL-8.2.3-06X) ; ils comportent une photographie permettant la liaison au demandeur (COL-8.2.3-02X). La liste des documents acceptés figure en annexe D (COL-8.2.3-03X). Le document est d'abord identifié comme doté d'une puce lisible ; la zone de lecture automatique est lue optiquement une première fois en temps réel, sur le flux de la caméra, pour dériver la clé d'accès ; en cas d'échec de cette lecture, le demandeur peut saisir les données nécessaires ou le CAN, qui ne servent qu'à l'accès à la puce ; une seconde lecture optique, sur les photographies du recto et du verso du document, qui servent aussi à sa classification, lit la zone de lecture automatique et la zone d'inspection visuelle pour le contrôle de cohérence avec la puce (§7.3) ; ces photographies sont restituées au donneur d'ordre s'il le demande lors de l'initiation de la demande de vérification ; puis un canal sécurisé est établi avec la puce (PACE, ou BAC pour les documents qui ne supportent pas PACE) avant l'extraction des groupes de données.

7.3 Validation des preuves (clauses 8.3.1 et 8.3.2)¶

Exigence	Mise en œuvre
VAL-8.3.1-01X	Les attributs sont validés par la signature de l'émetteur du document, source autoritaire.
VAL-8.3.1-02	Les éléments de preuve sont collectés et protégés conformément au §7.5.2.
VAL-8.3.1-03X, 04X	Traitement des différences d'encodage et des écarts de noms : voir ci-dessous.
VAL-8.3.1-05, 06X	Le type de document et son émetteur sont vérifiés au regard de l'annexe D et du contexte.
VAL-8.3.1-07	Le document doit être valide à la date du parcours ; un document expiré est rejeté.
VAL-8.3.1-08X	Authenticité et intégrité établies par l'authentification passive et, lorsque le document les implémente, par la Chip Authentication ou l'Active Authentication.
VAL-8.3.1-10X	Les éléments de sécurité vérifiés pour chaque document accepté (mécanismes cryptographiques de la puce) sont documentés dans la procédure de vérification documentaire SID-ETSI-PRO-VERIF-DOCUMENTAIRE (section 10 et annexe A), documentation interne non publiée (note 3).
VAL-8.3.1-11X	Vérification de la validité courante lorsque c'est pratiquement possible : voir VAL-8.3.2-03.
VAL-8.3.1-12	La validation est effectuée dans l'environnement contrôlé par ShareID (infrastructure OVHcloud).
VAL-8.3.2-00	La validation réussie du document valide le document et les attributs qu'il porte.
VAL-8.3.2-01	Les données de la puce sont transférées vers l'environnement de ShareID par un canal garantissant authenticité, intégrité et confidentialité (canal sécurisé avec la puce, TLS 1.3, épinglage de certificats, SDK Renforcé, §8.2).
VAL-8.3.2-02	Authentification passive systématique, côté serveur : validation de la signature de l'émetteur sur le EF.SOD et les groupes de données, sur une chaîne remontant à un certificat CSCA du magasin de ShareID, mis à jour mensuellement. À défaut de validation réussie, notamment si aucun certificat CSCA de confiance n'est disponible, le document est rejeté et le parcours arrêté, aux deux niveaux ; la trace de l'échec est conservée (certificat présenté, résultat de construction de chaîne, état du magasin CSCA, horodatage).
VAL-8.3.2-03	Voir ci-dessous.
VAL-8.3.2-04X	Protection contre l'injection d'une copie de document digital : voir ci-dessous.
VAL-8.3.2-04A	Chaque nouvelle tentative relit la puce ; un parcours interrompu puis repris relit le document depuis la puce.
VAL-8.3.2-05	Sont enregistrés les attributs, l'émetteur, la période de validité et le numéro unique du document.
VAL-8.3.2-06	La photographie contenue dans la puce est extraite pour la liaison au demandeur.

Service de statut (VAL-8.3.2-03). L'exigence s'applique lorsqu'un service de statut en ligne existe et est pratiquement disponible ; la norme relève que l'accès à ces services est parfois restreint (note 4). À ce jour, aucun service de statut ne présente une couverture suffisamment étendue pour permettre à ShareID de réaliser systématiquement ces vérifications pour l’ensemble des documents acceptés. ShareID consulte donc les services disponibles lorsqu’ils sont accessibles pour les documents concernés et conserve une trace des démarches effectuées. À la date de la présente version, une demande d'accès au service belge CheckDoc est en cours pour les documents couverts par ce service. Les demandes DocVerif doivent être initiées par le responsable du traitement. ShareID poursuit par ailleurs l’exploration d’autres sources, publiques ou commerciales, afin d’étendre progressivement la couverture des vérifications de statut. En complément, ShareID restitue les éléments d’identification du document conformément à l’exigence VAL-8.3.2-05. Ces éléments permettent au donneur d’ordre de procéder lui-même à une consultation auprès d’un service de statut auquel il aurait accès. Cette consultation par le donneur d’ordre demeure hors du périmètre certifié de ShareID.

Protection contre l'injection d'une copie (VAL-8.3.2-04X). L'exigence s'applique aux deux niveaux de garantie et est satisfaite par les mesures suivantes :

lorsque le document implémente la Chip Authentication ou l'Active Authentication, preuve cryptographique de l'originalité de la puce, le défi et les secrets étant générés et vérifiés côté serveur, ce qui empêche le rejeu (SID-ETSI-RAP-ARCHITECTURE, annexe A) ;
dans tous les cas, lecture de la puce par le seul SDK natif ShareID en version Renforcée, logiciel approuvé pour le parcours qui protège l'intégrité de l'application et arrête le parcours si nos protections ont détecté que l'environnement est compromis (note 7) ; session à usage unique non rejouable ; relecture obligatoire de la puce en cas de reprise (VAL-8.3.2-04A).

Conformément à la note 6, la protection est plus difficile à garantir lorsque la puce ne supporte aucun protocole de détection du clonage ; ce cas conduit au niveau Baseline LoIP (§8.3). Les moyens de détection d'attaque par injection certifiés CEN/TS 18099 portent sur la capture du visage (§7.4.1) et ne sont pas invoqués pour la protection des données de la puce.

Encodage et écarts de noms (VAL-8.3.1-03X, VAL-8.3.1-04X). Les noms faisant foi sont ceux de la puce. Deux sources peuvent y coexister : le DG1 (zone de lecture automatique), en caractères latins translittérés selon l'ICAO 9303, sans diacritiques et tronqués lorsque la longueur du champ est atteinte ; le DG11, lorsqu'il est présent, avec le nom complet, non tronqué, le cas échéant en caractères nationaux. Règles appliquées :

lorsque le DG11 contient le nom complet, celui-ci est restitué, accompagné de la version en caractères latins du DG1 et de l'indication de la source ; à défaut, le nom du DG1 est restitué, avec l'indication d'une troncature lorsque le champ est saturé ;
en cas de changement de nom postérieur à l'émission du document, le nom du document fait foi (COL-8.2.2.1-02, note 3) ;
le contrôle de cohérence entre la puce et les données lues optiquement sur les photographies du document (zone de lecture automatique et zone d'inspection visuelle), y compris lorsque la clé d'accès a été saisie manuellement, porte sur des données de même nature ;

Clause 8.3.3. USE-9.2.3.4-02 renvoie à la seule clause 8.3.2 ; les exigences propres à la validation d'un document physique ne sont pas invoquées. Le contrôle de cohérence entre la puce et les données lues optiquement est une mesure additionnelle ; les attributs faisant foi sont ceux de la puce. La photographie de référence est collectée par NFC et l'authentification passive est systématique (VAL-8.3.3-22 du règlement 2026/798, appliquée volontairement). VAL-8.3.3-21 du même règlement, qui porte sur des exigences de la clause 8.3.3, est sans objet. Le processus de vérification des éléments de sécurité de la puce est documenté dans SID-ETSI-PRO-VERIF-DOCUMENTAIRE, qui couvre l'objectif de VAL-8.3.3-07C.

7.4 Liaison au demandeur (clauses 8.4.2 et 8.4.3)¶

7.4.1 Capture du visage (clause 8.4.2)¶

Exigence	Mise en œuvre
BIN-8.4.2-01, 01A	Un flux vidéo du visage du demandeur est capturé au moment du parcours, à 25 images par seconde et en 720×1280 pixels en portrait (SID-ETSI-RAP-ANALYSE-RISQUES).
BIN-8.4.2-02X, 02A	Détection d'attaque de présentation en configuration « Élevé » : défis actifs aléatoires générés côté serveur et analyse passive ; aucun flux préenregistré n'est accepté.
BIN-8.4.2-03X	Détection des apparences faciales générées ou manipulées, dans le périmètre de l'évaluation CEN/TS 18099 niveau High.
BIN-8.4.2-04	Le flux capturé est transmis à l'environnement de ShareID par un canal garantissant authenticité, intégrité et confidentialité.
BIN-8.4.2-04A à 04D	Moyens de prévention et de détection des attaques par injection, évalués par un laboratoire accrédité selon CEN/TS 18099 au niveau High ; réévaluation au moins tous les deux ans ; mise à jour continue selon la veille.
BIN-8.4.2-05X, 05A, 05B	Au moins une image de résolution suffisante est extraite du flux ; les conditions de capture (luminosité, reflets, netteté) sont évaluées et la capture est refusée si elle est inadaptée, avec une consigne de nouvelle tentative.
BIN-8.4.2-05C	La capture du visage est limitée à quatre tentatives par parcours, contrôlées par le backend.
BIN-8.4.2-05D, 05E	Objectifs APCER et BPCER déclarés en section 9 et révisés selon la veille.
BIN-8.4.2-06X, 07X, 07A	Tests systématiques selon ISO/IEC 30107-3 ; évaluation par laboratoire accrédité selon ISO/IEC 19989-3, certifiée niveau High ; réévaluation au plus tard le 16/08/2028.
BIN-8.4.2-08X, 09X	Les résultats de test atteignent l'objectif APCER et visent l'objectif BPCER de la section 9.

7.4.2 Comparaison faciale automatisée (clause 8.4.3)¶

Exigence	Mise en œuvre
BIN-8.4.3-01X	Comparaison automatisée entre la photographie extraite de la puce (DG2), authentifiée par la signature de l'émetteur, et l'image capturée selon la clause 8.4.2.
BIN-8.4.3-02X, 03	Seules la capture et l'évaluation préliminaire de qualité sont effectuées sur le terminal ; traitement du signal, comparaison, stockage et décision sont effectués dans l'environnement contrôlé par ShareID.
BIN-8.4.3-05A, 05B	Objectifs FAR et FRR déclarés en section 9, au niveau des bonnes pratiques de l'industrie, et révisés selon la veille.
BIN-8.4.3-06X	Tests systématiques des algorithmes selon ISO/IEC 19795-1, en comparaison un-à-un, sur des jeux de données tenus à jour ; règle de non-régression à chaque nouvelle version.
BIN-8.4.3-07X, 08X	Les résultats de test atteignent l'objectif FAR et visent l'objectif FRR de la section 9.
BIN-8.4.3-09X (recommandation)	Voir ci-dessous.

Photographies morphées (BIN-8.4.3-09X). Cette disposition est une recommandation. ShareID met en œuvre un algorithme de détection des photographies morphées.

Le risque est en plus réduit par la comparaison de la photographie de référence à une capture fiable, protégée par la détection d'attaque de présentation et d'injection (note 8), par l'extraction authentifiée de la photographie depuis la puce et par un seuil de décision calibré sur l'objectif FAR ;

la veille suit les méthodes d'évaluation (ISO/IEC 20059). Le risque résiduel est accepté par la direction (§4.1) et porté à la connaissance des donneurs d'ordre (SID-ETSI-POL-IPS).

7.5 Émission du résultat et preuves (clause 8.5)¶

7.5.1 Résultat (clause 8.5.1)¶

Le résultat est transmis au serveur du donneur d'ordre par rappel serveur à serveur authentifié par HMAC-SHA256, ou mis à disposition par interrogation de l'API, sur des canaux TLS 1.3 (ISS-8.5.1-01). Il n'est jamais exposé au SDK du terminal. Il comprend le verdict, les attributs validés, la photographie lue dans la puce sauf choix contraire du donneur d'ordre, les photographies du document et une photographie du visage extraite de la vidéo de détection du vivant, s'il les a demandées lors de l'initiation de la demande de vérification, et le niveau de garantie atteint (ISS-8.5.1-02), ainsi que le niveau visé appliqué (§8.3) ; en cas d'échec, un code de rejet normalisé. À compter de la délivrance du certificat de conformité, il peut porter l'identifiant d'objet correspondant au niveau atteint (§1.3).

Tous les attributs restitués proviennent de groupes de données couverts par la signature de l'émetteur ; leur niveau de garantie est identique à celui du résultat, et aucune assurance différenciée n'est à signaler (ISS-8.5.1-03X).

7.5.2 Données du parcours et dossier de preuve (clause 8.5.2)¶

Catégorie	Durée	Modalités
Données du parcours : données extraites de la puce, images et vidéos	Fixée par le responsable de traitement, de 1 jour à 120 jours ; 3 jours par défaut	Chiffrement au repos (§6.5) ; suppression automatique à l'échéance
Dossier de preuve	Durée nécessaire fixée par le contexte et convenue contractuellement (ISS-8.5.2-04) ; à défaut, 3 jours en scénario A ; en scénario B, 1 an à compter de la fin du parcours, sauf durée différente convenue ; dans tous les cas, de 0 à 10 ans	Voir le tableau ci-dessous
Journaux d'événements	Voir §6.10	Aucune donnée personnelle du demandeur au-delà de la durée du dossier de preuve

Exigence	Mise en œuvre
ISS-8.5.2-01	Les preuves sont collectées et conservées conformément au contexte.
ISS-8.5.2-02X, 03	Le dossier documente la preuve utilisée (type, modèle, pays et numéro du document) et son émetteur (autorité de délivrance et autorité de certification du pays). Selon ce que le contexte autorise, il documente aussi le déroulement complet du parcours.
ISS-8.5.2-05, 05A	Le dossier contient un manifeste listant l’empreinte de chaque pièce et une signature ; l’heure de fin du parcours fait partie des pièces référencées.
ISS-8.5.2-06	Chiffrement au repos ; accès restreint selon le moindre privilège.
ISS-8.5.2-07	Le dossier est recherchable et restituable au donneur d'ordre par l'API pendant sa durée de conservation ; il permet de re-vérifier le résultat, les données de preuve étant sauvegardées (§6.11).
ISS-8.5.2-08	À l'échéance, le dossier et toutes les données personnelles du demandeur sont supprimés automatiquement.

Contenu du dossier de preuve. Le dossier contient :

Le parcours : les identifiants du parcours, du demandeur et du donneur d’ordre, l’heure de début et l’heure de fin, l’entité responsable de la conservation et la durée de conservation.
La décision : le verdict, le code de rejet le cas échéant, le niveau de garantie atteint et la politique de décision appliquée (contrôles requis, seuils, règles et version).
Le document : son type, son modèle, son pays et son numéro, ses dates de délivrance et d’expiration, son autorité émettrice, et les attributs lus par lecture optique et par la puce.
La puce : les données lues sur la puce et le portrait, le certificat de l’autorité du pays, la référence du certificat du signataire, et les éléments de l’authentification active et de l’authentification de la puce.
Les images : le recto du document et le selfie.
La chronologie horodatée : les étapes, les défis, les contrôles lancés et leurs verdicts, et la version du SDK.
Les modèles : l’empreinte des modèles utilisés.
Le scellement : le manifeste des empreintes et la signature.

La spécification détaillée, dont le format de restitution, figure dans la procédure de constitution et de conservation du dossier de preuve (SID-ETSI-PRO-DOSSIER-PREUVE).

Les gabarits biométriques calculés pour la comparaison sont traités en mémoire et ne sont pas conservés ; les images et vidéos du visage sont des données du parcours, conservées selon le tableau ci-dessus puis supprimées.

8. Cas d'usage 9.2.3.4 — Use case for automated operation¶

8.1 Conformité (clause 9.1)¶

Le processus est conforme au cas d'usage 9.2.3.4 pour le Baseline LoIP et l'Extended LoIP (USE-9.1-01X). Au seul niveau Extended LoIP, le même processus constitue la mise en œuvre du cas d'usage C.3.4 revendiqué (§3.1 ; QTS-C.3.4-03, QTS-C.3.4-04) ; aucun parcours ni contrôle propre à ce cas d'usage n'est ajouté. Les clauses 5 à 8 de la norme s'appliquent conformément à USE-9.1-02X (sections 4 à 7). Aucun cas d'usage composé au titre d'USE-9.1-03X n'est revendiqué. La conformité est évaluée par un organisme d'évaluation indépendant et accrédité (USE-9.1-01A).

8.2 Déroulement du parcours¶

Étape	Description	Exigences
1. Contrôle du terminal	Le SDK vérifie au lancement l'intégrité de l'environnement et la présence du NFC ; il informe le demandeur si le NFC n'est pas pris en charge ou si son accès est bloqué.	USE-9.2.3.1-01 ; VAL-8.3.2-04X note 7
2. Initiation	Information, acceptation des conditions, ouverture d'une session à identifiant unique.	INI-8.1-01X à 04
3. Identification du document	Le document sélectionné est identifié comme doté d'une puce lisible ; à défaut, invitation à présenter un autre document.	USE-9.2.3.1-02, 05
4. Lecture de la puce	Lecture optique de la zone de lecture automatique, canal sécurisé, extraction des groupes de données.	USE-9.2.3.1-04, 05
5. Validation	Authentification passive, Chip Authentication ou Active Authentication lorsque présentes, validité, cohérence.	USE-9.2.3.4-02
6. Capture du visage	Flux vidéo, détection d'attaque de présentation et d'injection.	USE-9.2.3.1-06
7. Comparaison faciale	Comparaison automatisée avec la photographie de la puce.	USE-9.2.3.4-03
8. Résultat	Verdict, attributs, niveau de garantie atteint, dossier de preuve.	ISS-8.5.1, ISS-8.5.2

Le demandeur reçoit un guidage automatisé tout au long du parcours (USE-9.2.3.1-01), dans les langues listées dans la documentation des SDK (doc.shareid.ai, rubrique « Localisation », pour Android et pour iOS). Les attributs sont collectés selon la clause 8.2.2.1 (USE-9.2.3.1-03), le document digital est l'unique preuve autoritaire (USE-9.2.3.1-04, USE-9.2.3.4-01X) et aucune preuve complémentaire n'est utilisée (USE-9.2.3.1-07 à USE-9.2.3.1-10).

Le nombre de tentatives est limité : lecture de la puce (§8.4) et capture du visage (BIN-8.4.2-05C, §7.4.1) ; au-delà, le demandeur est invité à présenter un autre document pour la lecture de la puce (§8.4), et le parcours s'arrête également en cas d’échecs au moment de la capture du visage.

Terminaux compatibles. La politique du service renvoie à la présente section pour la liste des terminaux compatibles (SID-ETSI-POL-IPS).

SDK	SDK natif ShareID en version Renforcée, exclusivement
Systèmes	iOS 15.0 ou supérieur ; Android 7.0 ou supérieur
Matériel	Caméra frontale et contrôleur NFC compatible avec la lecture des puces ISO/IEC 14443 ; sur iOS, iPhone 7 et modèles ultérieurs.
Connexion	Débit minimal de 2 Mbps (SLA)
Versions du SDK	Mise à jour automatique par l'intégrateur ; seules les deux dernières versions majeures sont maintenues (SLA)
Options désactivées	Les options « Essayer sans NFC » et de choix d'un portefeuille, présentes dans le SDK pour d'autres offres, sont désactivées dans la configuration du service dans le backend ; elles ne peuvent pas être activées par le donneur d'ordre ni par le demandeur lorsqu’il est dans le parcours certifié.

8.3 Détermination du niveau de garantie atteint¶

Le niveau de garantie est déterminé pour chaque parcours, selon les contrôles effectivement réalisés. L'Extended LoIP est atteint lorsque l'ensemble des contrôles requis est réalisé avec succès, y compris la preuve de l'originalité de la puce par Chip Authentication ou Active Authentication. Lorsque le document n'implémente aucun de ces deux mécanismes, le parcours atteint le Baseline LoIP. Ce critère est un choix de ShareID fondé sur son analyse de risques : à l'égard d'attaquants à potentiel d'attaque élevé (OVR-5-08), seule la preuve cryptographique de présence de la puce écarte le clonage de façon fiable (note 6 de VAL-8.3.2-04X). Il n'abaisse aucune exigence applicable aux deux niveaux. Le niveau atteint figure systématiquement dans le résultat. Il s'agit du niveau établi par le parcours unique, non d'un parcours de repli.

Matrice de détermination. Seule l'absence des deux mécanismes conduit au Baseline LoIP ; tout échec d'un contrôle conduit au rejet.

Contrôle	Résultat	Fondement
Authentification passive en échec, ou chaîne de certification jusqu'à un certificat CSCA de confiance non établie	Rejet	VAL-8.3.2-02
Chip Authentication ou Active Authentication déclarée dans le EF.COM (DG14 ou DG15) mais en échec ou non exécutée	Rejet	VAL-8.3.2-04X
Chip Authentication ou Active Authentication réussie, et tous les autres contrôles réussis	Extended LoIP	OVR-5-08 — choix ShareID
Ni DG14 ni DG15 présents, et tous les autres contrôles réussis	Baseline LoIP	OVR-5-07 — choix ShareID
Document expiré	Rejet	VAL-8.3.1-07
Données de la puce incohérentes avec les données lues optiquement (zone de lecture automatique, zone d'inspection visuelle)	Rejet	Mesure additionnelle
Attaque de présentation, visage artificiellement généré ou attaque par injection détectés	Rejet	BIN-8.4.2-02X, 03X, 04A
Comparaison faciale sous le seuil de décision	Rejet	BIN-8.4.3-01X
Environnement du terminal compromis (root, jailbreak, émulateur, mode débogage)	Rejet	Note 7 de VAL-8.3.2-04X
Nombre maximal de tentatives atteint	Rejet	BIN-8.4.2-05C

Lorsque le contexte exige l'Extended LoIP, un résultat au Baseline LoIP ne le satisfait pas ; c'est notamment le cas de l'émission de certificats qualifiés (cas d'usage C.3.4, §3.1 ; QTS-C.3.4-03 et QTS-C.3.4-04), pour laquelle le donneur d'ordre retient le niveau visé Extended LoIP.

Niveau visé. Le niveau de garantie requis relève du contexte d'identity proofing (clause 4.3 de l'ETSI TS 119 461) et est fixé pour chaque donneur d'ordre sous la forme d'un niveau visé (§3.3). Les deux niveaux visés s'appliquent au même parcours, avec les mêmes contrôles et les mêmes conditions de rejet :

niveau visé Extended LoIP : le résultat est l'Extended LoIP, le Baseline LoIP ou le rejet, selon la matrice ci-dessus ;
niveau visé Baseline LoIP : le résultat est le Baseline LoIP ou le rejet ; la ligne de la matrice qui conduit à l'Extended LoIP conduit au Baseline LoIP.

Le niveau visé Baseline LoIP ne dispense d'aucun contrôle : un mécanisme de Chip Authentication ou d'Active Authentication listé dans l'EF.COM est exécuté et son échec entraîne le rejet (VAL-8.3.2-04X). Un contexte qui exige l'Extended LoIP retient le niveau visé Extended LoIP. Le niveau visé est choisi par le donneur d'ordre pour chaque requête de vérification, au moment de l'initier ; ce choix ne lui permet pas de modifier le paramétrage du niveau visé de son compte, qui relève de ShareID et suit la gestion des changements (§6.7). Il n'est pas modifiable par le demandeur. Le niveau visé appliqué figure dans le résultat et dans le dossier de preuve (§7.5 ; SID-ETSI-PRO-DOSSIER-PREUVE).

8.4 Anomalies, abandon et information du demandeur (USE-9.2.3.1-02)¶

Situation	Traitement
Terminal sans NFC ou accès NFC bloqué	Message au demandeur ; le parcours ne peut aboutir.
Document sans puce lisible	Invitation à présenter un autre document ; aucun parcours alternatif.
Échec de lecture de la puce (délai dépassé, puce non détectée, erreur d'accès, connexion perdue, puce illisible, document erroné)	Nouvelle tentative, avec relecture de la puce, jusqu'à cinq tentatives ; au-delà, le demandeur est invité à présenter un autre document. Le parcours n'est arrêté, sans proposition d'un autre document, que si la lecture de la puce a été entamée.
Capture du visage inadaptée	Consigne de nouvelle tentative dans la limite de quatre tentatives (BIN-8.4.2-05C, §7.4.1).
Échec d'un contrôle de validation ou de liaison	Rejet selon la matrice du §8.3. Pour un échec cryptographique ou une attaque détectée, le message au demandeur reste générique, afin de ne pas guider un attaquant (exemple de USE-9.2.3.1-02).
Abandon par le demandeur	Résultat en échec avec un code d'abandon normalisé restitué au donneur d'ordre.

Aucune intervention humaine n'est prévue dans le parcours, y compris en cas d'échec. L'information du demandeur précise le motif de l'échec dans les limites ci-dessus et les voies de recours auprès du responsable de traitement (INI-8.1-05). Lorsque le rejet constitue une décision fondée exclusivement sur un traitement automatisé au sens de l'article 22 du RGPD, le demandeur peut obtenir une intervention humaine, exprimer son point de vue et contester la décision auprès du responsable de traitement : le donneur d'ordre (§10.2). Ce réexamen intervient après la décision et n'introduit aucune intervention humaine dans le parcours certifié.

L'écran de rejet affiche un message paramétrable comportant les coordonnées du responsable de traitement et de son délégué à la protection des données. Le responsable de traitement dispose des codes de rejet et du dossier de preuve, par l'API, pour procéder au réexamen ; ShareID l'assiste et lui transmet dans un délai de dix jours toute demande d'exercice des droits reçue directement (SID-ETSI-CTR-DPA) dans le délai de rétention. Le réexamen ne modifie pas le résultat émis ; un nouveau parcours peut être proposé.

9. Objectifs de qualité et de performance¶

Conformément à OVR-5-10, BIN-8.4.2-05D et BIN-8.4.3-05A, ShareID déclare les objectifs suivants, au moins au niveau des bonnes pratiques de l'industrie, et teste régulièrement ses performances au regard de ces objectifs. La même configuration de détection du vivant (« Élevé », PAD et IAD) est utilisée pour les deux niveaux de garantie (SID-ETSI-RAP-ANALYSE-RISQUES).

Métrique	Niveau	Objectif	Valeur mesurée	Point de fonctionnement	Conditions de mesure
PAD APCER	Baseline et Extended	0 % CLR Labs Liveness Detection Security Target CLR.FE.004.2025CLR-0731_2	0 %	—	ISO/IEC 30107-3 ; rapport CLR Labs CERT-PAD-SHAREID.2025CLR-0731_2
PAD BPCER	Baseline et Extended	15 % CLR Labs Liveness Detection Security Target CLR.FE.004.2025CLR-0731_2	8%	—	Idem
IAD iOS APCER	Baseline et Extended	0% CEN TS 18099	0%	—	CEN TS 18099 Rapport CLR CLR.FE.002.REA.2025CLR-0731_10
IAD iOS BPCER	Baseline et Extended	15% CEN TS 18099	3.4%	—	CEN TS 18099 Rapport CLR CLR.FE.002.REA.2025CLR-0731_10
IAD Android APCER	Baseline et Extended	0% CEN TS 18099	0%	—	CEN TS 18099 Rapport CLR CLR.FE.002.REA.I 2025CLR-0731_8
IAD Android BPCER	Baseline et Extended	15% CEN TS 18099	8.66%	—	CEN TS 18099 Rapport CLR CLR.FE.002.REA.I 2025CLR-0731_8
Face matching FAR	Baseline et Extended	0.001% CLR.FE.005.REP.2026CLR-0806_3 1.0	<0.0009% (0% avec une incertitude de 0.0009%)	0.41 Plage conforme 0,391043 à 0,492819	ISO/IEC 19795-1; rapport CLR Labs CLR.FE.005.REP.2026CLR-0806_3 1.0
Face matching FRR	Baseline et Extended	1% CLR.FE.005.REP.2026CLR-0806_3 1.0	<0.39% (0% avec une incertitude de 0.39%)	Même seuil que le FAR	Idem

Les objectifs FAR et FRR sont fixés au moins au niveau des bonnes pratiques de l'industrie, par référence aux résultats de comparaison un-à-un du NIST Face Recognition Technology Evaluation (BIN-8.4.3-05A, note 3), et mesurés selon l'ISO/IEC 19795-1 (BIN-8.4.3-06X). Ils sont établis à partir de l'analyse de risques et de la procédure de veille, selon la méthode du rapport ENISA « Methodology for sectoral cybersecurity assessments », conformément à USE-9.2.3.4-04 du règlement 2026/798 appliqué volontairement (§1.2.1) ; aucun cas d'usage hybride n'étant revendiqué, la borne relative à ces cas ne s'applique pas. Les objectifs sont révisés annuellement, après chaque résultat d'évaluation par laboratoire et selon les constats de la veille (BIN-8.4.2-05E, BIN-8.4.3-05B). Toute nouvelle version d'un modèle est soumise à une règle de non-régression sur ces métriques avant sa mise en production. Les performances sont mesurées à chaque nouvelle version d'un modèle et au moins une fois par an ; chaque campagne fait l'objet d'un rapport (protocole, jeux de données, résultats, décision) conservé par le CTO et présenté au ComSec.

Objectif opérationnel	Valeur	Source
Disponibilité des services ShareID	99,9 % mensuel	SLA
Délais de traitement	Délai moyen : 35 secondes (lecture et vérification du document) et 25 secondes (visage, PAD et IAD) ; délai maximal : 30 minutes	SLA

10. Aspects juridiques et protection des données¶

10.1 Responsabilité¶

Les engagements et les limitations de responsabilité de ShareID résultent des documents contractuels conclus avec chaque donneur d'ordre (§5.2) et des limitations énoncées dans SID-ETSI-POL-IPS. ShareID répond de la conformité du service aux pratiques déclarées dans le présent document. Le donneur d'ordre reste maître de la décision qu'il fonde sur le résultat.

10.2 Protection des données à caractère personnel¶

Pour le service, ShareID agit toujours en qualité de sous-traitant au sens de l'article 28 du RGPD, dans les deux scénarios : le donneur d'ordre est responsable de traitement, et ShareID est sous-traitant ultérieur lorsque le donneur d'ordre agit lui-même pour le compte d'un tiers. ShareID traite les données sur instruction documentée, dans le cadre de l'accord de sous-traitance SID-ETSI-CTR-DPA.

La base légale du traitement de données biométriques au sens de l'article 9 du RGPD relève du responsable de traitement ; ShareID met à sa disposition, sur demande, ses analyses d'impact relatives à la vérification documentaire et à la détection du vivant. La collecte est limitée aux données nécessaires (COL-8.2.2.1-04) et les mesures de protection des données dès la conception sont appliquées (article 25 du RGPD). Les données sont hébergées et traitées en France, sur l'infrastructure OVHcloud (§6.14), et conservées selon le §7.5.2.

Les demandeurs exercent leurs droits auprès du responsable de traitement ; une demande reçue directement par ShareID en qualité de sous-traitant lui est transmise dans un délai de dix jours (SID-ETSI-CTR-DPA). ShareID ne réutilise pas les données des demandeurs pour ses propres finalités.

10.3 Confidentialité¶

Les données traitées dans le cadre du service sont confidentielles. Le personnel est lié par une clause de confidentialité ; l'accès aux données est restreint selon le moindre privilège (§6.4).

10.4 Propriété intellectuelle¶

Les logiciels, algorithmes et modèles du service sont la propriété de ShareID. Les jeux de données d'entraînement et de test ne contiennent pas de données des demandeurs traitées au titre du service.

10.5 Réclamations et litiges (REQ-7.1.1-06)¶

Les donneurs d'ordre adressent leurs réclamations par le portail de support ou par courriel ; elles sont enregistrées, traitées et documentées selon la procédure de traitement des réclamations et des litiges (SID-ETSI-PRO-RECLAMATIONS). Les réclamations des demandeurs, y compris la contestation d'un rejet au titre de l'article 22 du RGPD, sont reçues par le responsable de traitement (§8.4), que ShareID assiste. Toute plainte relative à la conformité du service est enregistrée et prise en compte conformément au règlement de certification Q084 (§4.19).

Annexe A — Correspondance des exigences¶

Les identifiants de l'ETSI EN 319 401 cités ci-dessous sont ceux de la V3.1.1 ; l'emplacement de chaque exigence est tenu dans SID-ETSI-REG-MATRICE-EXIGENCES. Nature : E exigence (shall) ; R recommandation (should) ; C choix ShareID ; V adaptation du règlement d'exécution (UE) 2026/798 appliquée volontairement.

Exigence	Objet	Section	Nature
OVR-5-01 à 5-10 ; REQ-5-01 à 5-05	Analyse de risques, veille, potentiel d'attaque, objectifs	§4, §9	E
OVR-6.1-01 ; REQ-6.1-01 à 6.1-11	Déclaration des pratiques, approbation, révision, mise à disposition, cessation	§1.1, §2, §5.1, §6.12, §6.14	E
OVR-6.1-02, 6.1-03 ; COL-8.2.1-06X	Identification des cas d'usage	§3.1	E
OVR-6.2-01 ; REQ-6.2-01 à 6.2-05	Conditions générales	§5.2	E
OVR-6.3-01 ; REQ-6.3-01 à 6.3-09X	Politique de sécurité, contrôles de configuration	§5.3	E
OVR-7.1-01 ; REQ-7.1.1-01 à 06, REQ-7.1.2-01	Organisation, ressources, réclamations, séparation des fonctions	§6.1, §10.5	E (7.1.1-03 : R)
OVR-7.2-01 ; REQ-7.2-01X à 7.2-19X	Ressources humaines, rôles de confiance, télétravail	§6.2	E
OVR-7.3-01 à 7.8-02	Actifs, accès, cryptographie, sécurité physique, opérations, réseaux	§6.3 à §6.8	E
OVR-7.9-01, 7.9-02 ; REQ-7.9.2-02X, REQ-7.9.3-01X à 04X	Incidents et notifications	§6.9	E
OVR-7.10-01 ; REQ-7.10-01 à 08	Preuves et journalisation	§6.10, §7.5.2	E
OVR-7.11-01, 7.11-02	Continuité, gestion de crise	§6.11	E
OVR-7.12-01 ; REQ-7.12-01 à 10 (hors 7.12-11)	Cessation d'activité	§6.12	E
OVR-7.13-01, 7.14-01	Conformité, chaîne d'approvisionnement	§6.13, §6.14	E
EN 319 401 — REQ-7.8-17X à 19X	Tests d'intrusion (REQ-7.8-18X : recommandation)	§6.7 ; SID-TRANSV-POL-DEV-SECURISE	E
EN 319 401 — clauses 7.14.1 à 7.14.3	Sécurité de la chaîne d'approvisionnement	§6.14 ; SID-TRANSV-POL-FOURNISSEURS	E
EN 319 401 — REQ-6.3-04X	Notification des changements importants et de la cessation	§2.2	E
INI-8.1-01X, 03X, 04	Information, guidage, accessibilité	§7.1	E
INI-8.1-02X	Choix entre processus alternatifs	§7.1	R — sans objet (parcours unique)
INI-8.1-05	Information et solutions en cas d'échec	§7.1, §8.4	V
COL-8.2.1-01X à 07 ; COL-8.2.2.1-01X à 04	Collecte, attributs d'une personne physique	§7.2.1, §7.2.2	E
COL-8.2.3-01X, 02X, 03X, 06X	Document digital comme preuve, liste des documents	§3.2, §7.2.3, annexe D	E
COL-8.2.3-04X, 05X, 07	Document physique ; autres sources	—	Sans objet : document digital uniquement
VAL-8.3.1-01X à 12	Validation : exigences générales, noms et encodage	§7.3	E
VAL-8.3.2-00 à 06	Validation du document digital, dont injection d'une copie	§7.3	E
Choix Extended / Baseline selon CA / AA	Détermination du niveau atteint	§8.3	C
Clause 4.3 ; niveau visé Extended ou Baseline	Niveau requis par le contexte ; même parcours et mêmes contrôles	§3.3, §7.5.1, §8.3	C
Clause 8.3.3 ; VAL-8.3.3-21	Validation du document physique	§7.3	Sans objet : non invoquée par USE-9.2.3.4-02
VAL-8.3.3-07C	Documentation du processus de vérification des éléments de sécurité	§7.3 ; SID-ETSI-PRO-VERIF-DOCUMENTAIRE	Clause 8.3.3 non invoquée ; objectif couvert
VAL-8.3.3-22	Image de référence recueillie par NFC	§7.3	V
BIN-8.4.1-01X, 02X ; BIN-8.4.2-01 à 09X	Titulaire légitime et possession de la preuve ; capture du visage, PAD, IAD, objectifs APCER / BPCER	§7.4.1, §9	E (09X : R)
BIN-8.4.3-01X à 08X	Comparaison faciale, objectifs FAR / FRR	§7.4.2, §9	E (08X : R)
BIN-8.4.3-09X	Détection du morphing	§7.4.2	R — appliquée (algorithme de détection) ; risque résiduel accepté
BIN-8.4.3-04, 05	Présence physique	—	Sans objet : parcours à distance
ISS-8.5.1-01 à 03X ; ISS-8.5.2-01 à 08	Résultat, dossier de preuve, conservation	§7.5	E (8.5.1-03X, 8.5.2-03 : R)
USE-9.1-01X, 01A, 02X, 03X	Conformité au cas d'usage	§8.1	E (01A : R)
USE-9.2.3.1-01 à 10	Distanciel non accompagné : exigences générales	§3.2, §8.2, §8.4	E (07 à 10 : facultés non exercées)
USE-9.2.3.4-01X à 03	Cas d'usage automatisé	§3.1, §8	E
USE-9.2.3.4-04	Cibles FAR / FRR des processus automatisés	§9	V
QTS-C.3.4-03, QTS-C.3.4-04	Certificats qualifiés : exigences de l'Extended LoIP des clauses 9.2.3.1 et 9.2.3.4	§3.1, §3.3, §8.1, §8.3	E
QTS-C.3.4-07	Attributs autres que l'identité unique	§7.2.2	E
QTS-C.3.4-08	Confirmation de la conformité au cas d'usage C.3.4 par un organisme d'évaluation de la conformité	§3.1	E
QTS-C.3.4-01, 02, 05, 06	Distanciel accompagné ; renforcement par moyen d'identification électronique	§3.1	Sans objet
Clauses 8.2.4 à 8.2.9, 8.3.4 à 8.3.8, 8.4.4, 8.4.5	Autres preuves, liaison manuelle, personnes morales	—	Sans objet : non utilisées
Article 22 du RGPD	Décision automatisée : intervention humaine a posteriori	§8.4, §10.5	Obligation légale

Annexe C — Grille d'auto-évaluation d'accessibilité (INI-8.1-04)¶

Critères de niveau AA des WCAG 2.1, transposés aux logiciels par la clause 11 de l'EN 301 549, retenus pour un parcours mobile de lecture NFC et de capture du visage, complétés de critères propres à l'identity proofing. Résultats possibles : conforme, partiel, non conforme, sans objet ; les écarts donnent lieu à un plan d'action daté (responsable, échéance), inscrit au plan de traitement des risques (SID-ETSI-PLN-TRAITEMENT-RISQUES) et repris dans la déclaration d'accessibilité.

Référence	Critère	Question d'évaluation	Résultat iOS / Android	Commentaire ou action
WCAG 1.1.1	Contenu non textuel	Les pictogrammes, animations et boutons ont-ils une alternative textuelle lue par VoiceOver et TalkBack ?	iOS: Non Android: Non	Constat : Aucun libellé d'accessibilité sur iOS. Sur Android, une quinzaine de contentDescription figées en anglais, les autres à null. Les animations (Lottie, SVG) sont ignorées par les lecteurs d'écran. Action : Ajouter des libellés traduits à tous les visuels informatifs et masquer les décoratifs. Charge : iOS 2 j · Android 2 j Impact : +++
WCAG 1.3.4	Orientation	Le parcours fonctionne-t-il en portrait et en paysage, sauf lorsque la capture l'impose ?	iOS: Non Android: Non	Constat : Le parcours est verrouillé en portrait sur iOS et Android. Pour les écrans de capture (selfie, détection du vivant, document), ce verrouillage relève de l'exception « orientation essentielle » : cadrage du visage et du document, modèles d'analyse conçus pour le portrait, cohérence anti-fraude. Les écrans de consentement, de choix du document, de saisie, de lecture NFC et d'erreur n'en relèvent pas. Action 1 (court terme) : Documenter l'exception pour les écrans de capture dans la documentation de conformité Impact 1 : +++ Action 2 (cible) : Autoriser le paysage sur tous les écrans hors capture, en conservant le portrait sur la capture. Impact 2 : + Charge 1 : 0,5 j (documentation, commune aux deux plateformes) Charge 2 : iOS 3 j · Android 3 j
WCAG 1.4.1	Utilisation de la couleur	Les états (succès, erreur, cadrage correct) sont-ils signalés autrement que par la couleur ?	iOS: Partiel Android: Partiel	Constat : Les erreurs sont signalées par du texte, parfois des vibrations et icônes ou animations. En revanche, l'état « challenge en cours / validé » repose surtout sur le changement de couleur du cadre, et la progression NFC est affichée par des pastilles de couleur. Action : Ajouter un libellé textuel et une annonce à chaque changement d'état ; remplacer les pastilles par un texte de progression. Charge : Inclus dans 4.1.3 Impact : +++
WCAG 1.4.3	Contraste minimum	Les textes ont-ils un contraste d'au moins 4,5:1, y compris sur l'aperçu de la caméra ?	iOS: Non Android: Non	Constat : Ratios mesurés : bleu sur blanc 6,4:1 (conforme) ; bleu sur le voile noir de la caméra 3,3:1 ou moins ; rouge d'erreur sur blanc 3,5:1 ; vert de succès sur blanc 2,2:1 ; gris sur blanc 2,0:1. La couleur principale fournie par l'intégrateur n'est pas contrôlée. (cf. personnalisation) Action : Assombrir les couleurs succès, erreur et gris ; vérifier le contraste de la couleur intégrateur, avec repli automatique. Charge : iOS 1,5 j · Android 1,5 j · design 1 j Impact : ++
WCAG 1.4.4	Agrandissement du texte	Les textes restent-ils lisibles avec la taille de police agrandie du système ?	iOS: Partiel Android: Partiel	Constat : Les polices suivent la taille système (Dynamic Type sur iOS, unités sp sur Android), et iOS bascule en défilement dans les tailles d'accessibilité. Mais plusieurs boutons et cadres ont une hauteur ou une largeur fixe, donc le texte est tronqué ; sur Android, seuls 2 écrans défilent. Action : Supprimer les dimensions fixes, rendre tous les écrans défilables, puis tester à la taille maximale (AX5 sur iOS, 200 % sur Android). Charge : iOS 3 j · Android 3 j Impact : +++
WCAG 2.2.1	Délais réglables	Les délais (lecture NFC, défis de détection du vivant) peuvent-ils être prolongés, ou sont-ils suffisants et signalés ?	iOS: Partiel Android: Partiel	Constat : La session dure 10 minutes par défaut ; le client peut la configurer jusqu'à 1 heure. Les délais et seuils de capture (distance du visage ou du document, défis de détection du vivant) sont fixes, pour des raisons de sécurité et de protection contre l'injection. Ils relèvent de l'exception « délai essentiel » du critère 2.2.1 : les allonger affaiblirait la vérification. Le délai de lecture NFC est lui aussi fixe et identique sur iOS et Android. Il est compensé par plusieurs tentatives. En revanche, l'utilisateur n'est pas prévenu avant l'expiration de la session. Action : Documenter l'exception de sécurité pour les délais de capture et de NFC. Prévenir l'utilisateur avant l'expiration de la session (message visuel annoncé au lecteur d'écran, environ 2 minutes avant). Rappeler aux clients qu'ils peuvent allonger la durée de session jusqu'à 1 heure pour les publics concernés. Charge : iOS 1 j · Android 1 j · documentation 0,5 j Impact : +
WCAG 2.4.3	Ordre de focus	L'ordre de lecture et de focus suit-il la logique du parcours ?	iOS: Partiel Android: Partiel	Constat : L'ordre natif est globalement cohérent, sens droite-à-gauche compris sur iOS. En revanche, le focus n'est pas replacé sur le titre au changement d'écran, l'ordre est indéfini sur les écrans caméra, et sur Android un bouton Retour masqué reste atteignable par TalkBack. Action : Placer le focus sur le titre à chaque écran ; regrouper les calques caméra ; corriger le bouton Retour masqué. Charge : iOS 1 j · Android 1 j Impact : ++
WCAG 2.5.1	Gestes	Aucune action ne repose-t-elle uniquement sur un geste complexe ?	iOS: Oui Android: Oui	Constat : Toutes les actions se font par simple appui ; aucun balayage, pincement ni geste à plusieurs doigts n'est requis. Les mouvements de tête des défis relèvent du critère 2.5.4 (voir la ligne « Défis de détection du vivant »). Action : Aucune. Charge : –
WCAG 3.1.1	Langue	La langue de l'interface est-elle déclarée pour les lecteurs d'écran, y compris le sens de lecture de droite à gauche ?	iOS: Partiel Android: Partiel	Constat : 11 langues disponibles, et le sens droite-à-gauche est appliqué à l'arabe. Mais la langue du SDK n'est pas déclarée au lecteur d'écran : s'il est réglé sur une autre langue que le système, la voix de lecture est incorrecte. Le grec utilise le code « gr » au lieu du code ISO « el ». Action : Déclarer la langue au lecteur d'écran, corriger le code « gr » en « el » Charge : iOS 1 j · Android 1 j Impact : +++
WCAG 3.3.1, 3.3.3	Erreurs et suggestions	Chaque erreur (NFC, capture, document) est-elle annoncée en texte avec une consigne de correction ?	iOS: Partiel Android: Partiel	Constat : Les erreurs de capture (document, visage, MRZ) et de lecture NFC affichent un message accompagné d'une consigne de correction, dans 11 langues. L'écran d'erreur technique générique, distinct de l'écran de rejet décrit au §8.4, n'affiche qu'« Une erreur est survenue» avec un code, sans consigne. Aucune erreur n'est annoncée au lecteur d'écran. Action : Associer une consigne à chaque code d'erreur ; annoncer les erreurs (voir 4.1.3). Charge : iOS 1 j · Android 1 j · traductions 1 j Impact : +++
WCAG 4.1.2	Nom, rôle, valeur	Les composants interactifs exposent-ils nom, rôle et état aux technologies d'assistance ?	iOS: Partiel Android: Partiel	Constat : Les boutons natifs exposent leur rôle et leur état. En revanche, les lignes cliquables (choix du pays, du document) n'ont pas le rôle « bouton », les sections dépliables n'exposent pas leur état, et la progression de l'envoi n'est pas exposée. Action : Ajouter les rôles, les états et la valeur de progression aux composants concernés. Charge : Inclus dans 1.1.1
WCAG 4.1.3	Messages d'état	Les changements d'état sont-ils annoncés sans déplacer le focus ?	iOS: Non Android: Non	Constat : Aucune annonce n'est envoyée au lecteur d'écran : ni messages de cadrage, ni validation d'un challenge, ni progression NFC, ni envoi des fichiers. Les pastilles de progression NFC sont lues sous la forme « cercle blanc, cercle blanc… ». Action : Annoncer les changements d'état sans déplacer le focus, en évitant les annonces en rafale ; remplacer les pastilles par un pourcentage lu. Charge : iOS 3 j · Android 3 j Impact : +++
Spécifique	Positionnement NFC	Un guidage sonore ou haptique aide-t-il à positionner le document sur l'antenne ?	iOS: Partiel Android: Partiel	Constat : Une vibration signale la détection de la puce sur Android ; sur iOS, la fenêtre NFC du système est lue par VoiceOver. Avant la détection, aucun guidage sonore ou haptique n'indique où se trouve l'antenne : seule une animation la montre. Action : Ajouter un guidage vocal vers l'antenne (« placez le document au dos, en haut ») et annoncer la progression de la lecture. Charge : iOS 2 j · Android 2 j Impact : +++
Spécifique	Cadrage du visage	Le cadrage est-il guidé par des consignes sonores ou haptiques ?	iOS: Partiel Android: Partiel	Constat : Des vibrations signalent le succès, l'avertissement et l'erreur. Il n'y a ni guidage vocal ni guidage directionnel (« approchez-vous », « décalez-vous à gauche »), et les messages de cadrage ne sont pas lus. Action : Ajouter un guidage vocal directionnel, actif quand un lecteur d'écran est utilisé. Charge : iOS 3 j · Android 3 j · design 2 j Impact : à évaluer
Spécifique	Défis de détection du vivant	Les défis sont-ils réalisables par une personne malvoyante ou à mobilité réduite ?	iOS: Non Android: Non	Constat : Les challenges actifs (tourner la tête, sourire, cligner des yeux, placer votre document) n'ont pas d'alternative. Pour une personne malvoyante, la consigne n'est que visuelle; une personne à mobilité réduite ou atteinte de paralysie ne peut pas les réaliser. Action : Mode accessible : le SDK signale au serveur qu'un lecteur d'écran est actif ; le serveur choisit alors des défis adaptés (passifs ou neutres, délais allongés). Une décision produit et sécurité est nécessaire. Charge : à estimer après la décision produit et sécurité
Spécifique	Orientation	Le demandeur qui ne peut pas réaliser le parcours est-il orienté vers le responsable du contexte ?	iOS: Partiel Android: Partiel	Constat : En cas de rejet, l'écran de rejet affiche un message paramétrable comportant les coordonnées du responsable de traitement et de son DPO (§8.4). En cas d'échec technique ou d'abandon avant le verdict, seuls les choix Réessayer, Retour ou Fermer sont proposés. Seuls les retours techniques transmis à l'application intégratrice (onError, onExit) permettent une Redirection. Action : Ajouter un écran d'assistance configurable (texte, lien ou téléphone du responsable), présenté après plusieurs échecs, et un nouveau retour « besoin d'assistance » vers l'application. Charge : iOS 2 j · Android 2 j · backend 1 j Impact : +++

Annexe D — Documents d'identité acceptés¶

Conformément à COL-8.2.3-03X et COL-8.2.1-06X, sont acceptés, pour tous les contextes d'identity proofing sauf restriction convenue dans l'Offre, les passeports, cartes nationales d'identité et titres de séjour électroniques conformes à l'ICAO Doc 9303, dotés d'une puce sans contact lisible par NFC, lorsque : a) un certificat CSCA valide de l'État émetteur figure dans le magasin de certificats de ShareID ; b) la puce contient la photographie du visage (DG2) ; c) le document n'est pas expiré à la date du parcours. La liste des modèles qui remplissent ces critères est tenue dans le catalogue de couverture SID-ETSI-REG-CATALOGUE-COUVERTURE, document à diffusion restreinte, daté et mis à jour à chaque évolution de la couverture ; il est communiqué aux donneurs d'ordre avant la Commande et à chaque mise à jour, et à l'organisme d'évaluation de la conformité (REQ-6.1-05X, note 2). Le niveau atteint est déterminé, pour chaque parcours, à la lecture de la puce (§8.3). Les éléments de sécurité vérifiés par titre (VAL-8.3.1-10X) sont documentés dans SID-ETSI-PRO-VERIF-DOCUMENTAIRE, annexe A, documentation interne non publiée (note 3 de VAL-8.3.1-10X) ; la liste des modèles et cette annexe A sont établies à partir du même catalogue.