Stargate transforme l'infrastructure de messagerie de dépendante à la confiance à vérifiée par la confiance. Chaque échange entre organisations résout l'identité cryptographique, établit le consentement aux politiques et crée une piste d'audit vérifiable — sans surcharge de travail ni modifications de l'expérience utilisateur.
Réserver un parcours d'architecture de 30 minutesLes systèmes de confiance actuels obligent les organisations à dépendre d'autorités centrales pour chaque vérification d'identité et chaque échange de données. L'architecture de Vereign élimine ces dépendances en permettant à chaque organisation de contrôler sa propre identité cryptographique et de vérifier les autres directement. Voici comment cela fonctionne en pratique, de la gestion des clés à l'échange de données vérifié.
La séquence en 7 étapes ci-dessous est le chemin emprunté par chaque message Stargate — depuis le moment où votre client DNS émet une requête jusqu'au moment où les données arrivent vérifiées et auditées à destination.
Lorsque votre application résout le domaine d'un correspondant (p. ex. hopital-b.ch), le proxy DNS Stargate intercepte la requête avant qu'elle n'atteigne votre résolveur en amont. C'est le point d'entrée — aucune modification du code applicatif n'est requise. Le proxy opère de façon transparente au niveau réseau.
L'agent d'identité interroge l'enregistrement d'identité publié par le correspondant via Stargate. Deux résultats possibles : le correspondant est compatible Stargate (vérification cryptographique complète) ou non (livraison standard, message marqué comme non vérifié). C'est ainsi que Stargate assure la rétrocompatibilité — les messages vers des correspondants non-Stargate ne sont jamais bloqués.
Si le correspondant est compatible Stargate, un tunnel VPN WireGuard est établi avec des clés dérivées des enregistrements d'identité DKMS des deux organisations. Ces clés ne sont pas émises par une autorité de certification centrale — elles sont dérivées du journal d'événements KERI propre à chaque organisation. Le tunnel est bilatéral : chaque partie authentifie l'autre de façon indépendante.
Avant tout transfert de données, le moteur de politiques de Stargate (Open Policy Agent, OPA) évalue si cet échange est autorisé par les politiques des deux parties. Pour les données de santé, le résolveur FHIR vérifie le consentement au niveau de la ressource : consentements des patients, autorisations organisationnelles et réglementations sectorielles (EHDS, LPD suisse) sont évalués en temps réel. Les données non autorisées par les politiques ne transitent pas.
Vos jetons OAuth et certificats X.509 existants restent valides. Le pont de compatibilité de Stargate traduit les credentials KERI-ancrés au format JWT ou X.509 côté récepteur — localement, sans contacter d'autorité externe. Votre infrastructure d'identité ne change pas. Stargate l'étend pour fonctionner au-delà des frontières organisationnelles.
Le consentement aux politiques confirmé et le tunnel WireGuard chiffré établi, l'échange de données a lieu. SEAL (Secure Edge Application Layer) enveloppe chaque message d'une couche d'authenticité vérifiable — l'organisation réceptrice peut prouver qui a envoyé les données, quand et qu'elles n'ont pas été altérées. Cela remplace la dépendance de S/MIME aux autorités de certification tierces par une vérification bilatérale dérivée du DKMS.
Chaque échange génère une entrée dans le journal d'événements KERI (KEL) et le journal de transactions (TEL). Ces journaux sont infalsifiables et vérifiables de façon indépendante par toute partie — pas seulement par un serveur de journaux central. Pour les secteurs réglementés, cela signifie des pistes d'audit inter-organisationnelles cryptographiquement solides, disponibles sans infrastructure centralisée.
La pile de confiance de Stargate est conçue par couches. Chaque couche fait une chose bien et transfère proprement à la suivante. L'infrastructure existante se branche sur la couche de compatibilité — rien n'est arraché.
Stargate n'est pas un projet de remplacement. C'est une extension de l'infrastructure que vous exploitez déjà. Le tableau ci-dessous montre ce que vous conservez et ce que Stargate ajoute.
443 violations de données RGPD signalées quotidiennement en Europe, avec des amendes cumulées dépassant 1,2 milliard d'EUR — DLA Piper GDPR Fines and Data Breach Survey
C'est la bonne question. Trois projets bien financés n'ont pas réussi à livrer une identité décentralisée à grande échelle :
KERI est structurellement différent. Il n'a aucune dépendance à la blockchain. Les événements clés sont ancrés dans des journaux en mode ajout uniquement que chaque contrôleur tient indépendamment — aucun grand livre partagé, aucuns frais de gaz, aucune gouvernance de fondation requise.
La validation institutionnelle : GLEIF — la Global Legal Entity Identifier Foundation — exploite le système LEI mondial pour les institutions financières dans 180 pays. GLEIF a choisi KERI pour le système vLEI. Ce n'est pas une preuve de concept. C'est une infrastructure de production qui vérifie l'identité des institutions financières mondiales. Stargate s'appuie sur le même fondement KERI validé par GLEIF à l'échelle institutionnelle.
Découvrez comment une infrastructure de confiance vérifiée s'applique à vos exigences spécifiques et à votre environnement réglementaire.
