Vérification de documents et factures
Vérification locale de l’empreinte d’un document afin d’en confirmer le scellement et la provenance déclarée avant une action sensible.
| Version | 2.0 — 15 septembre 2026 |
|---|---|
| Public visé | Équipes techniques, sécurité, intégration et partenaires |
| Statut | Description technique fondée sur les informations publiques; paramètres d’implémentation à confirmer |
Objectif et périmètre
Détecter une facture modifiée, une substitution de coordonnées bancaires ou un document qui ne correspond plus à la version scellée, sans téléverser le contenu complet vers Seal.
Principe de fonctionnement
- L’émetteur vérifié scelle une version déterminée du document.
- Une empreinte et les métadonnées minimales nécessaires sont enregistrées selon la politique du service.
- Le destinataire sélectionne le fichier dans son navigateur.
- Le navigateur calcule localement l’empreinte; le fichier lui-même n’est pas envoyé à Seal.
- Le résultat indique la correspondance avec la version scellée, l’identité du scellant et la date pertinente.
Menaces ciblées
- Modification de coordonnées bancaires
- Fausse facture imitant un fournisseur
- Altération d’un contrat ou d’une instruction
- Interception et substitution de pièce jointe
Composants et responsabilités
| Composant | Rôle |
|---|---|
| Organisation ou éditeur vérifié | Établit son identité, ses canaux ou domaines et gère les personnes autorisées. |
| Utilisateur ou approbateur | Présente une preuve vivante ou participe à l’autorisation selon la politique. |
| Service Seal | Évalue les éléments de vérification nécessaires et retourne un résultat limité au cas d’usage. |
| Système intégrateur | Lie le résultat Seal à l’action exacte, applique les règles métier et conserve l’audit requis. |
| Vérificateur | Contrôle le résultat dans son contexte et ne l’interprète pas comme une garantie de vérité. |
Données et confidentialité
Le principe public annoncé est la minimisation des données : absence de GPS, biométrie et caméra pour les modules d’identité et de présence; calcul local dans le navigateur lorsque le module traite un fichier média ou documentaire; conservation d’empreintes irréversibles et de métadonnées limitées plutôt que du contenu source. La liste exacte des champs, durées de conservation, journaux, sous-traitants et transferts doit être confirmée dans une annexe de traitement des données.
Propriétés de sécurité attendues
- Fraîcheur temporelle des preuves vivantes
- Séparation des rôles et des facteurs
- Liaison du résultat au contexte ou à l’action
- Minimisation et non-divulgation du contenu source
- Traçabilité proportionnée sans transformer Seal en base centrale d’identités
Limites et hypothèses
- Un document non scellé ne peut pas être validé par ce mécanisme; l’absence de sceau ne prouve pas une fraude.
- La correspondance prouve l’intégrité par rapport à la version scellée, pas la vérité du contenu ni la légitimité économique de la transaction.
- Les règles de canonisation, formats pris en charge et comportement après conversion doivent être définis.
Points à confirmer avant intégration
- API, schémas de requête et de réponse, authentification et quotas
- Algorithmes, longueurs de clés, sources d’entropie et rotation applicables
- Tolérances temporelles, synchronisation d’horloge et gestion de l’expiration
- Gestion des erreurs, révocation, récupération et continuité de service
- Journaux, rétention, localisation, suppression et obligations réglementaires
- Tests d’intrusion, revue cryptographique indépendante et procédure de divulgation des vulnérabilités
Références publiques
- https://seal.lifaio.com/go
- https://lifaio.com/seal-lifaio/
Avis : ce document décrit le fonctionnement conceptuel communiqué publiquement. Il ne remplace ni une spécification d’API, ni une analyse cryptographique, ni un audit de sécurité indépendant.
Demandes de brevet britanniques en instance : GB2619490.2 · GB2619948.9 · GB2620153.3 · GB2620211.9 · GB2620220.0 · GB2620253.1 · GB2620315.8 · GB2620629.2 · GB2621074.0 · GB2621382.7 · GB2622122.6 · GB2622135.8
