# Politique de certification — Mowibo ID

**Version 1.2 — 25 août 2026**
Autorité : Mowibo · Émetteur : `did:web:id.mowibo.com`
URL de publication : `https://id.mowibo.com/politique-de-certification`

> Ce document définit ce qu'un cachet Mowibo atteste, ce qu'il n'atteste pas, et comment
> un tiers le vérifie sans nous. Il est la référence opposable en cas de contestation.
> Une propriété qui n'est pas écrite ici ne doit pas être invoquée.

---

## 1. Objet

Mowibo ID appose un **cachet électronique** sur l'empreinte d'un document et, lorsque
le signataire dispose d'une clé d'appareil, contresigne la **signature de la personne**.

Le cachet répond à quatre questions, et à quatre seulement :

| Question | Réponse portée par le cachet |
|---|---|
| **Quoi** | L'empreinte SHA-256 du document (`documentHash`) |
| **Qui** | Le DID du signataire et sa signature Ed25519 (`signerDid`, `signerSignature`) |
| **Pour le compte de qui** | Le mandat d'organisation résolu à l'instant du scellement (`mandatId`, `orgRccm`) |
| **Dans quel état de vérification** | Le niveau KYC constaté **au moment de signer** (`kycNiveau`) |

Toute autre affirmation — véracité du contenu, capacité juridique, consentement éclairé,
validité de l'acte au fond — **est hors du périmètre de ce document**.

---

## 2. Identité de l'autorité et matériel cryptographique

| Élément | Valeur |
|---|---|
| DID de l'émetteur | `did:web:id.mowibo.com` |
| Document DID | `https://id.mowibo.com/.well-known/did.json` |
| Clés publiques (JWKS) | `https://id.mowibo.com/.well-known/jwks.json` |
| Algorithme | Ed25519 (RFC 8032), signatures 64 octets |
| Identifiant de clé (`kid`) | Empreinte RFC 7638 de la JWK |
| Encodage canonique | JCS (RFC 8785) |

L'URL des clés est **dérivée** du DID de l'émetteur : elles ne peuvent pas désigner
des hôtes différents. Si l'identité de l'émetteur n'est pas configurée, le service
**refuse de sceller** (HTTP 503) — il n'existe aucun mode dégradé.

---

## 3. Ce que le cachet atteste

### 3.1 Intégrité
Toute modification d'un octet du document rend la vérification négative. Le cachet
porte l'empreinte, jamais le document : **Mowibo ne conserve pas le document scellé**.

Cette phrase vaut pour l'acte scellé. Elle ne vaut **pas** pour la pièce d'identité
soumise à la vérification d'identité, qui obéit à un régime distinct — §11.

### 3.2 Origine
La signature Ed25519 est vérifiable avec la seule clé publique. Nous ne pouvons pas
produire un cachet valide après coup sans la clé privée, et un tiers n'a pas besoin
de nous faire confiance pour le constater.

### 3.3 Contrôle exclusif du signataire (co-signature)
Lorsque `sealType = cosigned` ou `corporate`, la personne a signé avec une clé
Ed25519 dont **la partie privée ne quitte pas son appareil** (passkey). Mowibo ne
détient pas cette clé et ne peut pas signer à sa place.

Un cachet `organisational` **ne porte pas** la signature de la personne. Il vaut
accusé de dépôt et horodatage — rien de plus. Cette distinction est lisible dans
l'enveloppe et ne doit jamais être présentée autrement.

### 3.4 Le mandat, à l'instant de l'acte
Pour un cachet d'entreprise, le mandat (`representant_legal` ou `mandataire`), sa
portée et sa validité sont **résolus au scellement** et inscrits dans l'enveloppe
signée. Un mandat révoqué la veille ne peut pas produire un cachet valide le
lendemain.

C'est la différence de fond avec un certificat de personne morale, qui atteste un
mandat au jour de son émission — parfois trois ans avant l'usage.

### 3.5 Le niveau de vérification, à l'instant de l'acte
`kycNiveau` est constaté au scellement, non hérité d'une vérification ancienne.

---

## 4. Ce que le cachet N'atteste PAS

Cette section est normative. Elle est aussi contraignante que la précédente.

1. **Ni la véracité, ni la licéité du contenu.** Nous scellons une empreinte.
2. **Ni la capacité juridique** du signataire (majorité, tutelle, interdiction de gérer).
3. **Ni le consentement éclairé** : le cachet prouve l'apposition, pas la compréhension.
4. **Ni une date certaine opposable**, sauf ancrage confirmé (§7).
5. **Ni la qualité de signature qualifiée** au sens de l'article 25.2 du règlement
   eIDAS (UE) 910/2014 — voir §5.
6. **Ni l'exactitude des données d'état civil** au-delà des contrôles du niveau KYC
   atteint (§6).
7. **Ni la solvabilité, ni la réputation, ni l'absence de fraude** du signataire. Le
   score FITS est un indicateur interne, il ne fait l'objet d'aucune attestation.

---

## 5. Positionnement juridique — déclaration honnête

| | Mowibo ID | Signature qualifiée (PSCe accrédité) |
|---|---|---|
| Recevabilité | Oui — eIDAS art. 25.1 | Oui |
| Équivalence à la signature manuscrite | **Non** | Oui — art. 25.2 |
| Charge de la preuve de fiabilité | **Sur celui qui s'en prévaut** | Sur celui qui conteste |
| Exigences art. 26 (signature avancée) | **Tenues sur un acte co-signé uniquement** — voir ci-dessous | Incluses |

**Mowibo n'est pas prestataire de service de confiance qualifié** et ne figure sur
aucune liste de confiance au titre du règlement eIDAS. Aucune communication
commerciale ne doit laisser entendre le contraire.

Le niveau `qualified` est **refusé par le service** (HTTP 400) : émettre un cachet
portant cette mention sans accréditation serait une affirmation fausse.

### « Avancé » : ce qui est revendiqué, et sur quoi

Confronté au texte des articles 26 et 36 le 16/08/2026, après lecture de la source :

| | Ce que l'article exige | État |
|---|---|---|
| **Signature avancée** (art. 26) | Liée au signataire de manière univoque, permettant de l'identifier, créée sous son **contrôle exclusif**, et liant les données de sorte que toute modification soit détectable | **Tenu — pour un acte CO-SIGNÉ.** La clé est générée sur l'appareil, non exportable, jamais transmise ; l'identité prouvée au niveau `standard` est exigée ; l'empreinte du document est dans ce qui est signé |
| **Cachet avancé** (art. 36) | Mêmes exigences, mais un **contrôle** simple suffit — l'article ne dit pas « exclusif » | **Tenu**, pour tout cachet Mowibo. C'est une propriété de la clé de scellement, pas du dossier scellé |

**Le défaut corrigé.** Jusqu'au 16/08/2026, le niveau `advanced` était le **défaut**
du service et n'était filtré que sur le niveau KYC : un cachet d'organisation où
**personne n'avait signé** partait avec ce mot inscrit dans l'enveloppe
cryptographiquement signée. Le niveau est désormais **déduit de l'acte** — présence
d'une co-signature, ou rien — et le demander sans signataire est refusé (HTTP 400),
au même titre que `qualified`. Un cachet d'organisation seul porte `simple`.

> **Ce que « avancé » ne donne pas.** Ni équivalence à la signature manuscrite (elle
> exige le qualifié, art. 25.2), ni présomption : la charge de prouver la fiabilité
> reste sur celui qui s'en prévaut. « Avancé » qualifie un procédé, pas un effet.

### Espace OHADA
Dans l'espace OHADA, il n'existe à ce jour aucune liste de confiance équivalente ni
aucun prestataire accrédité : **aucun acteur ne bénéficie de la présomption**. La
force probante y relève de l'appréciation du juge, à qui ce document est destiné.

---

## 6. Niveaux de vérification — preuves exigées

Un niveau ne peut être porté par un cachet que si les preuves correspondantes
existent, sont conservées et sont auditables. **Un niveau sans preuve enregistrée
est une non-conformité et interdit le scellement.**

| Niveau | Preuves exigées | Cachet autorisé |
|---|---|---|
| `inscription` | Aucune | Aucun |
| `basique` | Numéro vérifié par OTP + déclaratif | `simple` |
| `standard` | Pièce d'identité (OCR + contrôles) **et** selfie avec détection du vivant **et** absence de doublon biométrique **et** criblage AML/PEP | `simple`, `advanced` |
| `premium` | `standard` **et** justificatif de domicile **et** origine des fonds | `simple`, `advanced` |

Chaque élévation de niveau produit une ligne dans `kyc_verifications` et un
événement chaîné dans `identity_events`. **Une élévation sans ces deux traces est
nulle** et doit être ramenée à `inscription`.

Les preuves des niveaux `standard` et `premium` supposent la réception d'une pièce :
elles relèvent donc du régime décrit en §11.2, et non de celui de l'acte scellé.

---

## 7. Horodatage et ancrage

`signedAt` est déclaré par nos serveurs : **il ne constitue pas une date certaine**.

Une date certaine est obtenue par ancrage OpenTimestamps sur Bitcoin. L'ancrage est
asynchrone et non bloquant : un cachet reste valide sans ancrage, mais sa date n'est
alors pas opposable. L'état d'ancrage est consultable et doit être vérifié avant
d'invoquer une antériorité.

---

## 8. Cycle de vie des clés

| Étape | Règle |
|---|---|
| Génération | Ed25519, hors ligne. La clé privée n'est jamais transmise. |
| Protection | Variable d'environnement dédiée, jamais partagée avec les secrets de session. Migration HSM/KMS planifiée. |
| Rotation | Nouvelle clé active ; les clés retirées **restent publiées** dans la JWKS pour que les cachets antérieurs demeurent vérifiables. |
| Compromission | Retrait immédiat de la JWKS, publication d'un avis daté, et **les cachets postérieurs à la date de compromission cessent d'être opposables**. Les antérieurs ancrés le restent. |
| Absence de clé | Refus de sceller (503). Jamais de repli sur un secret partagé. |

Les cachets HMAC antérieurs à la migration Ed25519 sont **déclarés invérifiables**
par construction (`enveloppe_absente`) et ne sont revendiqués comme preuve dans
aucune circonstance.

---

## 9. Révocation

Un cachet **ne se révoque pas** : il constate un fait passé. Ce qui se révoque :

- un **mandat** — les cachets déjà émis sous ce mandat restent valides, ils
  attestent l'état du droit à leur date ;
- une **attestation vérifiable** (VC) — statut consultable, la vérification renvoie
  révoquée ;
- une **clé** — voir §8.

---

## 10. Vérification par un tiers — procédure

Aucun compte, aucune clé, aucun appel à Mowibo n'est nécessaire. La vérification est
**publique et gratuite** : l'émetteur paie le scellement, jamais le vérificateur.

1. Récupérer la JWKS : `GET https://id.mowibo.com/.well-known/jwks.json`
2. Sélectionner la clé dont le `kid` est celui de l'enveloppe.
3. Recalculer la forme canonique JCS de l'enveloppe (champs absents omis).
4. Vérifier `Ed25519(canonique, signature)` avec la clé publique.
5. Comparer `documentHash` à l'empreinte SHA-256 du document détenu.
6. Si `signerDid` est présent : vérifier la signature de la personne contre la clé
   contenue dans son `did:key`.

Une route de commodité existe (`POST /verifier/cachet`) : elle applique exactement
les étapes ci-dessus, sans consulter la base. **Son verdict n'a pas plus de valeur
que le calcul refait par le tiers lui-même** — c'est délibéré.

Aucune donnée personnelle n'est exposée par la surface publique.

---

## 11. Deux régimes de données, conservation et effacement

Mowibo ID traite deux natures de données qui n'obéissent pas à la même règle. Les
confondre serait la faute la plus grave que ce document puisse commettre : elle
ferait mentir le produit sur ce qu'il fait de ce qu'on lui confie.

### 11.1 Régime de l'acte — l'empreinte seule

Le document scellé n'est **jamais reçu**. Son empreinte SHA-256 est calculée par le
navigateur, revalidée par le serveur, et c'est tout ce qui transite. Rien du contenu
n'est conservé, ni pendant, ni après.

La phrase affichée à l'écran de scellement — « le fichier ne quitte pas votre
navigateur, seule son empreinte est transmise » — est **exacte**, et elle ne vaut
que pour cet écran et ceux qui en dérivent : scellement, recommandé, signature.

### 11.2 Régime de la pièce — le document est reçu

Vérifier un document exige de le recevoir : il n'existe aucun procédé qui contrôle
une carte d'identité, un bail ou un registre du commerce sans les lire. Trois
parcours reçoivent donc un document, et **eux seuls** :

| Parcours | Ce qui est reçu | Pourquoi |
|---|---|---|
| Vérification d'identité (§6) | recto, verso, portrait avec détection du vivant | établir un niveau de vérification |
| Preuve de résidence | bail, facture, attestation | un agent doit voir la pièce avant de la retenir au faisceau |
| Vérification de société (KYB) | RCCM, statuts, NIF, PV d'assemblée | confronter le registre déclaré au document |

Dans ces trois cas, **et pour cela seulement**, Mowibo :

- reçoit le document ;
- le **conserve** ;
- l'analyse — lecture des zones, contrôles de cohérence, comparaison faciale,
  confrontation aux mentions déclarées ;
- l'**efface** à l'échéance fixée en §11.3.

Le régime de la pièce est cantonné à ces trois parcours. Aucun écran de scellement,
de recommandé ou de signature ne reçoit d'image. L'écran qui
demande une pièce **annonce ce régime en toutes lettres** et ne reprend jamais la
formule du §11.1.

### 11.3 Durées de conservation

| Donnée | Conservée jusqu'à |
|---|---|
| Image de la pièce d'identité, verso, portrait | **fin de la relation + 5 ans** |
| Document de résidence (bail, facture, attestation) | **fin de la relation + 5 ans** — même horloge, même personne |
| Document d'une société (RCCM, statuts, NIF, PV) | **fin d'utilité de la vérification + 5 ans** (§11.4 *bis*) |
| Empreinte SHA-256 de chaque image effacée | même échéance que l'analyse |
| Analyse, scores, décision, agent ayant statué | **le plus tardif** de : décision + 10 ans, ou fin de la relation + 5 ans |
| Enveloppes et signatures | 10 ans |
| Journal d'événements chaîné | 10 ans |
| Documents scellés | **jamais conservés** |

L'analyse ne peut jamais être effacée avant l'image qu'elle décrit : une décision
dont la trace aurait disparu tandis que la pièce subsiste serait ininterprétable.

### 11.4 Ce qu'est « la fin de la relation »

Il s'agit de la relation **avec Mowibo ID**, et non de l'état d'un compte dans un
service qui le consomme : la conservation est notre engagement, l'horloge est donc
la nôtre, et elle se mesure sur nos propres signaux.

Une durée comptée depuis un événement exige que l'événement soit **daté**. Trois
faits la constituent, le premier survenu faisant foi :

1. la clôture du compte demandée par la personne ;
2. la clôture prononcée par Mowibo ;
3. à défaut de l'un ou l'autre, **vingt-quatre mois d'inactivité continue** — sans
   cette clause, un compte dormant conserverait ses pièces indéfiniment et la durée
   annoncée serait fictive.

Tant qu'aucun de ces faits n'est survenu, l'échéance d'effacement est **indéterminée**
et l'enregistrement le dit ainsi. Il ne porte pas de date supposée.

### 11.4 *bis* L'horloge d'une société

Une société n'a pas de relation avec Mowibo ID : elle n'a ni compte, ni appareil,
ni signal de vie. La « fin de la relation » du §11.4 n'a donc pas de sens pour
elle, et transposer cette règle telle quelle produirait une durée **fictive** — ou
une conservation sans terme, qui est pire.

Ce qui rattache les documents d'une société, c'est la **vérification** qu'ils
appuient. L'horloge part donc de la fin d'utilité de celle-ci :

| État de la vérification | Départ de l'horloge |
|---|---|
| Approuvée | son **terme** (`expire_le`) |
| Rejetée ou révoquée | la **date de décision** — plus rien ne s'appuie dessus |
| En cours d'examen | **indéterminée** : un agent doit encore regarder la pièce |

Le délai reste de **cinq ans** : une vérification peut être contestée après son
terme, et l'empreinte seule ne permet pas de rejouer un contrôle.

Cette horloge est posée par la base elle-même, au moment où la vérification est
statuée — et non par le code qui statue. La règle est une fonction de l'état du
dossier ; la confier à chaque chemin d'écriture, c'est attendre que le prochain
l'oublie.

### 11.5 Ce qu'« effacer » veut dire

À l'échéance :

- les octets de l'image sont **supprimés de la base** ;
- l'enregistrement demeure, portant l'**empreinte SHA-256** de ce qui a été effacé
  et la **date** de l'effacement ;
- l'effacement est inscrit au journal d'événements chaîné.

Conserver l'empreinte après l'image n'est pas une réserve : c'est ce qui permet, des
années plus tard, de confronter la pièce que le porteur produit à celle que nous
avons vue — **sans que nous la détenions**. Passé l'échéance, le régime de la pièce
rejoint celui de l'acte.

L'effacement est exécuté par un travail périodique dont le résultat est **comptable**.
L'invariant vérifié en permanence :

> **Aucun enregistrement dont l'échéance est passée ne porte encore d'octets.**

Un effacement qui ne se compte pas n'est pas un effacement.

### 11.6 Ce que ces durées sont — et ce qu'elles ne sont pas

Elles sont un **engagement de Mowibo, opposable à Mowibo**.

Elles ne sont **pas** la transcription d'un texte. Aucune disposition légale n'est
ici citée, et aucune ne doit être déduite de leur présence. Si un texte applicable —
guinéen, OHADA, ou du pays d'établissement — impose une durée différente, la présente
politique est amendée et versionnée (§13), et **la durée la plus longue s'applique
aux pièces déjà détenues**.

### 11.7 Droits de la personne

Accès, copie, et effacement anticipé. Un effacement anticipé est exécuté, sauf
lorsqu'une obligation de conservation y fait obstacle ; dans ce cas la personne reçoit
une réponse datée qui **nomme l'obligation invoquée**. Une opposition à laquelle on
répond par une généralité n'est pas une réponse.

---

## 12. Limites et responsabilité

Mowibo répond de l'exactitude des faits techniques qu'il atteste (§3) et de la
disponibilité de la surface de vérification. Il ne répond ni du contenu des
documents, ni des conséquences juridiques des actes scellés, ni des conséquences
d'une compromission d'un appareil dont il n'a pas la maîtrise.

Un utilisateur peut contester un cachet le concernant, obtenir la copie de
l'enveloppe et la trace du niveau invoqué, et demander la révocation du mandat sous
lequel il a été émis. Toute réclamation est journalisée et reçoit une réponse datée.

---

## 13. Versionnement

Cette politique est versionnée et datée. Chaque cachet est réputé émis sous la
version en vigueur à la date de son scellement ; les versions antérieures restent
publiées. Une modification qui restreindrait la portée d'un cachet déjà émis est
sans effet sur lui.

| Version | Date | Modification |
|---|---|---|
| 1.0 | 2026-08-15 | Version initiale |
| 1.2 | 2026-08-25 | §11.2 et §11.3 étendues aux **documents de résidence** et aux **documents de société**, qui suivaient déjà le même régime sans qu'il soit publié. §11.4 *bis* ajoutée : l'horloge d'une société part de la fin d'utilité de sa vérification, faute de « relation » à clore. Correction associée : ces documents étaient jusqu'ici conservés **sans terme** — la durée annoncée par la présente politique n'était exécutée par aucun code. |
| 1.1 | 2026-08-16 | §11 réécrite : les deux régimes de données (acte / pièce) sont nommés, la conservation des pièces d'identité est chiffrée — fin de la relation + 5 ans — « fin de la relation » et « effacer » sont définis. La mention antérieure « selon la réglementation applicable, minimum nécessaire » est retirée : elle n'engageait à rien et laissait croire à une obligation non citée. |