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 / Stargate

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 / Stargate

Le moteur de politiques de Stargate (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 / Stargate

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 / Stargate

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. Stargate combine les deux, en utilisant chacun là où il est l'outil approprié.

Aligné sur le programme national eID de la Suisse

Swiyu est le programme national suisse d'identité électronique, actuellement en développement. Il repose sur le même modèle de Self-Sovereign Identity (SSI) et de confiance décentralisée qui sous-tend Stargate et SEAL. Ce n'est pas une coïncidence — les mêmes principes architecturaux qui résolvent la confiance institutionnelle à grande échelle sont désormais adoptés au niveau national.

Vereign est impliqué dans le processus de consultation Swiyu depuis ses premières phases. Georg Greve a siégé au Swiyu Technical Advisory Council, apportant son expérience pratique du déploiement DKMS à l'échelle de production dans le système de santé suisse. Cette implication directe garantit que l'architecture de Vereign reste alignée sur l'infrastructure réglementaire et identitaire en évolution de la Suisse.

Pour les organisations qui déploient Stargate aujourd'hui, l'alignement Swiyu signifie que leur infrastructure de confiance est pérenne par rapport à la direction réglementaire suisse. Les décisions architecturales sont compatibles — les organisations ne construisent pas seulement pour les exigences d'aujourd'hui, mais pour l'environnement de confiance que la Suisse construit.

Stargate fournit cette architecture

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 Stargate, 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 Stargate se poursuit tout au long de 2026, choisi par le système de santé suisse comme future infrastructure de confiance.

Découvrir Stargate

É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 Stargate avec échange de données structurées se poursuit tout au long de 2026.

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. Stargate 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.

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