Aller au contenu
AyiID

SDK et intégration

Sécurité et vie privée

La vie privée n’est pas une option : c’est l’architecture. AYIiD est conçu pour prouver sans exposer.

Aucune image ne quitte le téléphone
La capture et le traitement biométrique se font sur l’appareil. Les API de liveness et de liaison puce n’acceptent que des scores normalisés, des condensats et des embeddings opaques, jamais d’image ni de donnée biométrique brute.

Minimisation des données

Le moteur ne stocke aucune donnée personnelle brute (PII). Le sujet est un DID pseudonyme ; la charge utile transmise au fournisseur KYC est opaque et non stockée. Seuls des résultats normalisés (booléens, score, attributs dérivés) sont conservés.

  • Preuve seule par défaut : en mode PROOF_ONLY, le vérificateur ne reçoit qu’un booléen signé, aucune donnée.
  • Divulgation sélective : les attributs précis ne sont partagés que sur choix explicite du détenteur.
  • Embeddings, pas d’images : les gabarits de visage sont des vecteurs opaques calculés localement.

Consentement vérifiable

Chaque partage est autorisé par une signature EIP-712 du détenteur, revérifiée côté serveur. Le consentement lie la demande, le vérificateur, la décision, le périmètre divulgué, un nonce et une échéance. Voir Concepts.

Attestations signées et révocables

Les résultats sont des attestations signées par l’émetteur (EIP-712) et ancrées on-chain au mieux, vérifiables hors ligne via la clé publique de l’émetteur. Toute attestation peut être révoquée (statut public VALID ou REVOKED).

Anti-fraude

La Preuve de Personne Vivante (PoLP) et la liaison à la puce du passeport (Passive Authentication eMRTD) protègent contre l’usurpation : photos, masques, deepfakes et flux virtuels sont écartés par l’agrégation de signaux et l’attestation d’intégrité de l’appareil (Play Integrity, Key Attestation, App Attest).

Durcissement des accès

  • Rôles stricts : chaque route vérifie le rôle du jeton. Pour un détenteur, l’identité concernée provient toujours du jeton, jamais du corps.
  • Limitation de débit : les routes d’authentification sont fortement limitées (anti-bruteforce sur clés API et signatures).
  • Réponses non énumérantes : les erreurs sensibles restent génériques pour ne pas guider un attaquant.
  • Webhooks signés : HMAC-SHA256 sur le corps brut, vérification en temps constant. Voir SDK.
Bonnes pratiques d’intégration
Gardez la clé API et le secret de webhook côté serveur. Vérifiez toujours la signature des webhooks sur le corps brut. Servez la documentation et vos front-ends en HTTPS.