Sovereign verification

Ce que sovereign verification veut dire

La vérification d’un Evidence Token requiert trois choses : le token lui-même, la clé publique enregistrée pour l’appareil qui l’a produit, et une implémentation de vérificateur. Aucune de ces trois choses n’a besoin d’impliquer YinkoShield. L’opérateur stocke les clés publiques. L’opérateur fait tourner le vérificateur. L’opérateur applique la policy.

Ce n’est pas une option de déploiement. C’est une propriété architecturale. Il n’y a pas de chemin de fallback où la vérification appelle silencieusement un endpoint YinkoShield quand le vérificateur de l’opérateur est indisponible. Il n’y a pas de licence check au runtime. Il n’y a pas de télémétrie que l’opérateur n’a pas demandée.

outcomes

Ce que cela vous permet de faire aujourd'hui que vous ne pouviez pas avant

• Vérifier dans le chemin d'auth sans dépendre d'un service fournisseur

  Pas d'appel distant à YinkoShield, pas de licence check, pas de dépendance runtime. Une panne fournisseur ne casse pas votre flow de paiement.

• Passer les audits réglementaires sans YinkoShield dans le périmètre

  Les régulateurs vérifient l'evidence avec l'infrastructure propre de l'opérateur. Notre présence dans le narratif d'audit est structurelle, pas opérationnelle.

• Mettre à l'échelle la capacité de vérification dans votre propre infrastructure

  Le débit est fonction de votre CPU, pas du quota d'un tiers. La performance du vérificateur est la vôtre à tuner.

• Substituer les implémentations de vérificateur sans casser le substrat

  La spec est le contrat. L'opérateur est libre de forker le vérificateur de référence, de le hardening, ou de le faire tourner sur une stack différente — le protocole est inchangé.

• Diagnostiquer les rejets spécifiquement

  Chaque échec a une raison de rejet structurée. Les litiges reçoivent des réponses, les alertes de fraude sont catégorisées, les échecs d'intégrité sont attribués — rien n'est 'verification failed'.

Le pipeline de vérification

Le vérificateur de référence implémente un pipeline en huit étapes. Les étapes échouent en mode fermé — un échec à n’importe quelle étape rejette sans procéder. Chaque raison de rejet est diagnosticable, pas anonyme.

• ·1 Parse JWS — découper le token compact sur . en trois segments. Décoder le header ; exiger alg = ES256 et kid présent. Rejeter alg = none et tout autre algorithme.
• ·2 Resolve key — chercher kid dans le key store de l’opérateur. Tenter au maximum un re-fetch via un canal mutuellement authentifié si inconnu. Rejeter si toujours absent.
• ·3 Verify signature — ES256 sur BASE64URL(header).BASE64URL(payload) avec la clé publique résolue. Rejeter sur tout échec cryptographique.
• ·4 Validate claims — décoder la payload. Exiger eid, did, kid, ts, seq, event_name, tctx, sig_ref. Le kid du header DOIT être égal au kid de la payload. Rejeter sur champs manquants ou malformés.
• ·5 Enforce freshness — rejeter si ts tombe hors de la fenêtre de fraîcheur définie par l’opérateur (recommandée ±5 minutes).
• ·6 Replay check — rejeter si (did, tctx, event_name, seq) est déjà présent dans le dedup store. Le store DOIT être partagé et atomique entre toutes les instances de vérificateur.
• ·7 Sequence regression — pour les événements retry (payment.retry, pos.txn.retry, login.retry, auth.retry), exiger seq supérieur à chaque seq antérieur pour le même tctx. Rejeter sinon.
• ·8 Trust level resolution — résoudre le niveau de trust depuis l’Evidence Record lié quand fetché (hardware_backed, hardware_bound, execution_proof, compromised_device) ; sinon retourner software_layer. Le trust est déclaré, jamais inféré.

Vérificateurs de référence

• Python — ≥3.9, cryptography, 96 tests
• JavaScript — Node ≥18, zéro dépendance, 87 tests
• Go — ≥1.21, zéro dépendance, package complet
• Java — ≥17, zéro dépendance, 53 tests

Chaque vérificateur est une implémentation indépendante de la même spec. La conformance cross-verifier fait partie de la checklist CONFORMANCE.md de YEI-001 — le même token se vérifie de la même façon dans chaque langage, ou l’un d’entre eux est cassé.

properties

Ce que vous obtenez quand le vérificateur tourne dans votre stack

• ·01 Aucun fournisseur dans le chemin

  La vérification est l'opérateur avec sa propre copie de la clé publique. Nous ne sommes pas consultés.

• ·02 Vérificateurs de référence en quatre langages

  Python, JavaScript, Go, Java. Chacun est une implémentation indépendante ; la cross-conformance fait partie de CONFORMANCE.md.

• ·03 Raisons de rejet diagnosticables

  Chaque étape du pipeline émet un code d'échec spécifique — jamais un générique 'invalid token'.

• ·04 Opération en pattern PKI

  Familier à toute équipe SecOps. Le modèle mental est la vérification de signature contre une clé publique stockée ; pas un protocole bespoke.

• ·05 Zero-télémétrie

  Le vérificateur n'émet aucune télémétrie que l'opérateur n'a pas demandée. Pas de compteur d'usage, pas de beacon de licence, pas de stream de stats anonymes.

• ·06 Tolérant au fork

  La spec, la suite de conformance, et les implémentations de référence sont suffisantes pour qu'un opérateur fasse tourner son propre vérificateur indéfiniment sans coordination avec nous.

• ·07 Composable avec la policy

  Le vérificateur produit un verdict structuré ; le moteur de policy de l'opérateur le consomme. La pondération du trust-basis, la fenêtre de fraîcheur, et le routage de reject-reason sont tous définis par l'opérateur.

Où en lire plus

La spec de vérification vit dans YEI-001 §6 et CONFORMANCE.md, partagée avec les régulateurs et partenaires qualifiés sous NDA. Les vérificateurs de référence sont livrés avec la spec.

Demander la spécification YEI-001 →