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
Depuis la v4.3.0 : l’émetteur reçoit un CODE (D-XXXXXXXX) à inscrire sur la facture ou dans le courriel, jamais un lien ; le destinataire tape lui-même seal.lifaio.com/doc, entre le code et choisit le fichier. Le verdict distingue : authentique, ne correspond pas (modifié, ou réenregistré, converti, numérisé), révoqué (avec le code qui le remplace), expiré, inconnu. L’émetteur peut fixer une validité en jours, révoquer un document en un clic, et sceller jusqu’à 1 000 empreintes par appel d’API. La vérification est plafonnée par adresse IP.
- 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
