ORION : faites confiance à l'identité, pas à la localisation

La plupart des systèmes supposent encore que la bonne adresse implique la bonne réponse. Si une requête arrive sur l'IP ou le nom d'hôte attendu, le client traite le contenu comme authentique. Ce raccourci est commode, et c'est aussi le point de rupture.

Il cède dans l'exploitation courante, pas seulement lors d'une attaque. Un détournement DNS, une route empoisonnée, un chemin censuré ou un basculement vers une autre région peuvent livrer des octets que l'éditeur n'a pas produits. Le client est arrivé. Il n'a pas appris qui a publié l'enregistrement.

ORION sépare ces deux questions. Atteindre un nœud, c'est du transport. Accepter l'enregistrement, c'est de l'identité. Le client valide un enregistrement cryptographique, pas les coordonnées de la machine qui l'a servi.

ORION — Open Resilient Identity Overlay Network — est un overlay d'identité décentralisé construit par Scraplay. L'éditeur signe les enregistrements avec Ed25519. Les pairs répliquent ces enregistrements et les résolvent par un lookup distribué, de sorte que l'enregistrement reste disponible même si un hôte ne l'est pas.

Le périmètre est étroit exprès. ORION ne remplace ni votre base de données, ni votre API, ni TLS. Il répond à une question que ces couches laissent ouverte dès qu'un enregistrement peut vivre à plusieurs endroits : est-ce l'enregistrement signé par l'éditeur, quel que soit le nœud qui l'a remis ?

L'éditeur signe un enregistrement d'identité avec sa propre clé. Les pairs indexent cet enregistrement et répondent aux recherches sur l'overlay. Le consommateur vérifie la signature localement. Le lookup n'a pas besoin d'un annuaire central, et la vérification n'exige pas de faire confiance au pair qui a renvoyé les octets.

Si un nœud tombe, d'autres peuvent continuer à servir le même enregistrement signé. Remplacer un serveur, changer de région ou perdre une machine ne crée pas une nouvelle décision de confiance. La localisation reste un détail d'exploitation. La signature reste l'ancre.

Prenons un client qui a résolu un nom d'hôte, puis a dû suivre ce nom vers une autre région. TLS peut encore présenter un certificat valide pour ce nom. Cela ne prouve pas, à lui seul, qu'un enregistrement d'identité répliqué est celui que l'éditeur a signé. C'est la vérification qu'ajoute ORION : la signature de l'enregistrement, indépendante de l'adresse qui l'a servi.

Les cas utiles sont ceux où l'infrastructure bouge et où l'identité ne devrait pas bouger. Une API qui doit survivre à un changement d'hôte. Un service fédéré entre régions. Tout client qui doit savoir qui a publié un enregistrement, et pas seulement quelle adresse a répondu.

ORION se place à côté de TLS et de la PKI. Ces couches protègent toujours la connexion et nomment les serveurs que vous exploitez. ORION ajoute une identité sur l'enregistrement, qui reste valable quand la topologie change. Il ne retire pas les certificats, et il ne demande pas de faire confiance à un nœud plutôt qu'à une signature.

ORION est une infrastructure que Scraplay construit et exploite, pas une architecture sur papier. Si vous concevez des systèmes qui doivent vérifier un éditeur après le déplacement du nom d'hôte, commencez par le projet. Si vous voulez voir si cette couche a sa place dans un système que vous exploitez déjà, nous pouvons regarder l'architecture avec vous.