Les systèmes d'identité traditionnels s'arrêtent aux frontières organisationnelles. Voici ce qui les franchit.

Les outils d'identité standard ont été conçus pour une seule organisation. La confiance inter-institutionnelle à grande échelle exige une fondation différente — le choix de la santé suisse.

Discuter cette architecture pour votre organisation — sans engagement

Quatre limites structurelles des outils d'identité standard

OAuth (Open Authorization) et l'infrastructure à clé publique (PKI) sont d'excellents outils — au sein des limites d'une seule organisation. Ce ne sont pas des défaillances. Ce sont des contraintes architecturales qui deviennent visibles lorsque la confiance doit s'étendre entre organisations.

Confiance de jeton

Contrainte OAuth / PKI

Les jetons OAuth sont approuvés dans les limites de leur émetteur. Entre organisations, cette limite se brise — l'organisation destinataire n'a aucun moyen de vérifier l'autorité de l'organisation émettrice.

Solution DKMS / Verimesh

DKMS établit une identité cryptographique autocertifiante — l'identité de chaque organisation est vérifiable par toute autre organisation, sans dépendre d'une autorité de certification partagée.

Granularité d'accès

Contrainte OAuth / PKI

Les scopes OAuth sont grossiers — conçus pour les permissions au niveau applicatif. Le consentement au niveau du graphe de ressources entre frontières organisationnelles nécessite un modèle différent.

Solution DKMS / Verimesh

Le moteur de politiques de Verimesh (Open Policy Agent, OPA) permet un contrôle d'accès programmable et granulaire qui opère entre les frontières de confiance organisationnelles.

Auditabilité

Contrainte OAuth / PKI

Les journaux OAuth sont organisationnels. Les pistes d'audit inter-organisationnelles — qui a accédé à quoi, quand, autorisé par qui — exigent un chaînage cryptographique qu'OAuth n'a pas été conçu pour fournir.

Solution DKMS / Verimesh

KERI (Key Event Receipt Infrastructure) fournit des pistes d'audit infalsifiables. Chaque événement d'identité est lié cryptographiquement et indépendamment vérifiable, créant une auditabilité inter-organisationnelle.

Architecture de confiance

Contrainte OAuth / PKI

OAuth suppose une autorité centrale — un fournisseur d'identité en qui tout le monde a confiance. La confiance institutionnelle distribuée entre des organisations souveraines ne peut pas dépendre d'une seule autorité.

Solution DKMS / Verimesh

DKMS permet une gestion souveraine des identités — chaque organisation contrôle ses propres racines cryptographiques. La confiance est établie bilatéralement, pas déléguée à un coordinateur central.

OAuth pour les jetons locaux, DKMS pour la confiance institutionnelle évolutive

KERI identity infrastructure architecture diagram showing key event log, witnesses, watchers, and cross-organizational trust establishment
Infrastructure d'identité KERI — identifiants auto-certifiants, reçus d'événements de clé et confiance bilatérale sans autorité centrale

Il s'agit d'une évolution, pas d'un remplacement. OAuth (Open Authorization) est le bon outil pour l'authentification locale au sein des limites d'une seule organisation. DKMS (Decentralized Key Management System) est le bon outil pour la confiance institutionnelle à grande échelle — entre des organisations souveraines sans fournisseur d'identité commun. Verimesh combine les deux, en utilisant chacun là où il est l'outil approprié.

Complémentaire aux programmes nationaux d'identité électronique

Swiyu est le programme national suisse d'identité électronique. Il fait aujourd'hui fonctionner un pilote actif dans tous les cantons, le permis d'élève conducteur électronique, tandis que l'infrastructure de confiance de l'e-ID elle-même devrait être opérationnelle au premier semestre 2027. L'introduction de l'e-ID a été reportée, sans qu'une nouvelle date ait été annoncée, de sorte que le portefeuille national n'est pas encore en production. Les justificatifs swiyu sont émis au format SD-JWT VC, les identifiants et les attestations de confiance étant publiés dans des registres fédéraux. Pour l'e-ID elle-même, l'émetteur est l'État, en vertu du mandat de la loi sur l'e-ID de 2025, et le justificatif est conservé sur l'appareil du citoyen. D'autres justificatifs sur la même infrastructure sont émis par des cantons, des universités et des employeurs.

Vereign est impliqué dans le processus suisse d'e-ID depuis le début, à travers des réunions de participation et des échanges bilatéraux, et Georg Greve a siégé au Technical Advisory Circle convoqué par fedpol qui a préparé la décision technologique de 2024.

L'Union européenne mène le programme parallèle. Le cadre d'architecture et de référence de l'EUDI prévoit un portefeuille citoyen dans chaque État membre, et pour le justificatif d'identité fondamental de la personne, l'émetteur est également l'État. Il répond à la même question, comment une personne prouve son identité à une institution, et atteint la même limite : il ne fait pas le pont entre deux institutions situées dans des juridictions différentes. Verimesh est conçu pour les compléter tous deux, et non pour leur faire concurrence.

Pour les organisations qui déploient Verimesh, les deux sont complémentaires plutôt que concurrents. Un portefeuille national répond à la question de savoir comment une personne prouve son identité à une institution. Il ne répond pas à la manière dont deux institutions situées dans des juridictions différentes se vérifient mutuellement, ni à ce qu'il advient d'une décision de consentement après le partage des données. Verimesh conserve sa propre couche de confiance et est conçu pour parler les protocoles des portefeuilles en périphérie, de sorte qu'un client Verimesh puisse accepter une e-ID étatique lors de l'intégration et émettre ses propres justificatifs dans ce même portefeuille, dès que ces systèmes seront en production.

Verimesh fournit cette architecture

Verimesh (anciennement le projet Stargate) est l'implémentation en production de l'architecture de confiance basée sur DKMS décrite ci-dessus. Il combine OAuth pour l'authentification locale avec DKMS ancré sur KERI pour la confiance interorganisationnelle, un moteur de politiques programmable basé sur OPA, l'interopérabilité sémantique via Overlays Capture Architecture (OCA) et la communication vérifiable via SEAL.

SEAL, le composant de communication vérifiable de Verimesh, traite déjà plus de 800 000 messages vérifiés par mois dans le système de santé suisse. Le déploiement complet de Verimesh se poursuit tout au long de 2026, choisi par le système de santé suisse comme future infrastructure de confiance.

Découvrir Verimesh

Une seule racine, de l'application jusqu'au fil

Le mesh Verimesh fonctionne sur WireGuard, et la clé du tunnel partage la même racine que l'identité applicative. Les clés de tunnel Curve25519 de chaque organisation sont dérivées de son propre matériel Decentralized Key Management (DKMS) — aucune autorité centrale ne les délivre, et il n'y a aucun écart entre l'identité de la couche réseau et celle de la couche applicative. La rotation des clés est coordonnée avec DKMS (pré-rotation reposant sur KERI), et chaque établissement de tunnel est vérifiable face au Key Event Log. Aucun intermédiaire ne possède le flux de données.

Silencieux par conception

Les paquets non authentifiés ne reçoivent aucune réponse. Le mesh est invisible à un balayage de ports — il n'y a aucune surface d'attaque publique à sonder.

Environ 4 000 lignes que vous pouvez lire

WireGuard représente environ 4 000 lignes de code, contre quelque 100 000 pour OpenVPN et 400 000 pour IPsec. L'auditabilité est en soi une propriété de sécurité.

Aucune négociation, aucun déclassement

Des primitives modernes figées — Curve25519, ChaCha20-Poly1305, BLAKE2s, le handshake Noise_IKpsk2. La confidentialité persistante (perfect forward secrecy) avec renouvellement des clés toutes les deux minutes environ et la dissimulation d'identité sont intégrées, non configurées.

Souverain jusqu'au fil

Open Source de bout en bout, auto-hébergé, sans plan de contrôle SaaS sur le chemin. La souveraineté s'étend de l'application jusqu'au transport lui-même.

Une infrastructure éprouvée et sans surprise

Intégré au noyau Linux principal depuis 2020 — le même protocole que recommandent des éditeurs de sécurité tels que Palo Alto Networks. Il porte aujourd'hui le déploiement de Verimesh avec HIN.

Prêt pour la migration quantique

La couche de clé pré-partagée de WireGuard protège déjà le trafic d'aujourd'hui contre les attaques « stocker maintenant, déchiffrer plus tard ». Et comme les clés de tunnel sont dérivées de DKMS, le passage aux algorithmes post-quantiques devient une rotation de clés de routine sur le Key Event Log existant — et non une réémission massive de toutes les clés en une seule fois.

Voir le cycle de vie complet de la connexion

L'application du consentement est la raison d'être de DKMS

L'article 71(8) de l'EHDS crée une contrainte structurelle qu'aucune autorité centrale ne peut satisfaire : lorsqu'une personne retire son consentement à l'utilisation secondaire, ce retrait doit se propager à chaque institution qui détient ou dérive des données de la source originale. Aucune CA ne peut co-signer le retrait ; aucun fournisseur d'identité ne peut cascader la révocation. Cette contrainte est architecturalement incompatible avec l'identité centralisée.

DKMS satisfait cinq invariants qu'exige l'article 71 de l'EHDS : des identifiants liés à la personne qui survivent à une nouvelle inscription ; des enregistrements de retrait vérifiables et horodatés, ancrés dans le Key Event Log ; la réversibilité sans ré-identification ; la propagation inter-contrôleurs sans accords bilatéraux entre chaque paire d'institutions ; et l'impossibilité de lier l'enregistrement du consentement aux données qu'il couvre.

Une fois les données divulguées — partagées au sein d'un réseau hospitalier, d'un consortium de recherche ou d'une chaîne de payeurs — un retrait de consentement ultérieur doit néanmoins atteindre chaque responsable du traitement en aval. Les journaux d'événements de clés DKMS propagent la révocation de manière cryptographique : le KEL de chaque responsable est immuable et attesté, de sorte qu'une révocation ajoutée à l'extrémité de la personne devient vérifiable dans chaque institution qui détient un enregistrement dérivé.

Lire la thèse sur l'architecture du consentement

Éprouvé dans le système de santé suisse — choisi pour un déploiement à l'échelle nationale

HIN — Health Info Net — est le réseau suisse d'information de santé, reliant hôpitaux, cabinets de médecine générale et spécialistes au-delà des frontières cantonales. SEAL, le composant de communication vérifiable construit sur cette architecture de confiance, traite déjà plus de 800 000 messages vérifiés par mois. Le déploiement complet de Verimesh avec échange de données structurées se poursuit tout au long de 2026.

HIN — Health Info Net

800 000+

messages vérifiés par mois

850+

passerelles dans la santé suisse

30 000+

cabinets médicaux et institutions de santé

Architecture de confiance — questions fréquentes

Qu'est-ce que DKMS ?
DKMS (Decentralised Key Management) désigne la catégorie d'infrastructure d'identité dans laquelle la confiance cryptographique est ancrée au niveau de l'organisation, et non dans une autorité de certification centrale. Chaque organisation contrôle son propre matériel cryptographique et son propre Key Event Log (KEL) append-only. Vereign a co-fondé la DKMS Alliance pour formaliser DKMS en tant que catégorie aux côtés de PKI et OAuth.
En quoi DKMS diffère-t-il de PKI ?
PKI ancre la confiance dans des autorités de certification centrales — une compromission d'une CA affecte chaque sujet qu'elle a signé. DKMS ancre la confiance dans le Key Event Log propre à chaque organisation : une défaillance reste limitée à un seul contrôleur, la rotation de clé est native et atomique via les engagements de pre-rotation, et la confiance inter-juridictionnelle ne nécessite aucun traité de reconnaissance entre CA. DKMS, c'est la PKI à la périphérie, sans le point de défaillance unique.
DKMS remplace-t-il OAuth ?
Non. OAuth est adapté aux flux de tokens locaux à l'intérieur d'une organisation et doit continuer à y être utilisé. DKMS résout un problème pour lequel OAuth n'a jamais été conçu : établir une confiance vérifiable entre organisations sans intermédiaire partagé. Les deux sont complémentaires — OAuth pour les tokens locaux, DKMS pour la confiance institutionnelle à l'échelle.
DKMS est-il prêt pour le post-quantique ?
Oui. DKMS traite la rotation de clé comme une opération de premier ordre. Lorsque des algorithmes post-quantiques sont requis, la migration devient une rotation de clé de routine sur le Key Event Log existant, au lieu d'une réémission massive de certificats. La propriété de pre-rotation de KERI signifie que la clé suivante peut être n'importe quel algorithme choisi par le contrôleur — y compris des schémas post-quantiques — sans rompre les relations de confiance existantes.
Qui maintient DKMS ?
DKMS est une spécification ouverte. La DKMS Alliance — co-fondée par Vereign — coordonne la spécification. L'implémentation de référence de KERI (le protocole sous-jacent à DKMS) est maintenue en open source par la communauté KERI plus large. Verimesh et SEAL de Vereign sont des implémentations AGPLv3+ de la couche DKMS, en production dans la santé suisse.
DKMS nécessite-t-il une blockchain ?
Non. DKMS utilise des Key Event Logs (KELs) chaînés par hash pour l'intégrité append-only, mais il n'y a ni couche de consensus, ni token, ni ledger distribué. Le choix d'éviter la blockchain est délibéré — l'infrastructure réglementée exige une vérification déterministe, pas une finalité probabiliste.
Vereign peut-il m'aider à intégrer le wallet swiyu ou EUDI ?
Oui. Vereign est la couche de confiance institutionnelle qui complète les wallets nationaux d'e-ID, pas un concurrent. Un wallet national (swiyu, EUDI) prouve qui est une personne face à une institution. Verimesh répond à la frontière que ces wallets ne couvrent pas : comment deux institutions se vérifient directement, entre juridictions, y compris les personnes, rôles et agents qui agissent en leur sein, et ce qu'il advient d'une décision de consentement une fois les données partagées.
Vereign est-il un concurrent des wallets nationaux ?
Non. Verimesh est conçu pour compléter swiyu et EUDI plutôt que de leur faire concurrence. Un wallet national répond à la question de savoir comment une personne prouve son identité à une institution ; il ne répond pas à la manière dont deux institutions situées dans des juridictions différentes se vérifient mutuellement, ni à ce qu'il advient d'une décision de consentement après le partage des données. Verimesh conserve sa propre couche de confiance et est conçu pour parler les protocoles des wallets à la périphérie.
Le pont Verimesh vers swiyu ou EUDI est-il en production ?
Non. Les composants du pont (un fournisseur OID4VCI/VP, l'export de justificatifs, le mappage d'identifiants) sont architecturaux, démontrés au niveau de la conception, pas livrés. Verimesh lui-même est en production dans la santé suisse : la passerelle et l'AC centrale chez HIN fonctionnent en production, les premiers clients sont migrés et les utilisent, et la migration sur le réseau HIN doit s'achever avant fin 2026.

Réservez une revue d'architecture — cartographiez vos frontières de confiance.

Cette architecture est déployée dans le système de santé suisse à l'échelle nationale. Que vous évaluiez des alternatives à l'identité centralisée ou planifiiez l'échange de données interorganisationnel, nous le cartographierons dans un appel de 30 minutes.

Réserver une revue d'architecture
Protection des données suisse Conforme au RGPD Open Source AGPLv3+ Hébergement suisse
Voyez comment l'architecture fonctionne étape par étape