Identités d'équipe partagées : une identité, plusieurs personnes

Une équipe peut partager une identité CardanoWall, mais partager une identité revient à partager la graine d'identité. Il n'en existe aucune version allégée.

Transmettre la graine constitue une délégation totale. Quiconque la détient peut signer des records au nom de cette identité et déchiffrer les records scellés qui lui sont adressés. CardanoWall peut rendre ce mode de travail confortable entre des comptes distincts, mais ne peut pas transformer une graine en une autorité partielle, révocable et attribuée par personne. La cryptographie ne se plie pas ainsi.

N'utilisez donc une identité partagée que lorsque l'autorité partagée est précisément ce que vous recherchez.

Qu'est-ce qu'une identité d'équipe partagée ?

C'est une seule identité Label 309 utilisée par plus d'une personne ou d'un compte.

Une identité Label 309 prend racine dans une unique graine d'identité de 32 octets. Quiconque importe cette graine reconstitue la même clé de signature et les mêmes clés de réception, dans n'importe quel compte et dans n'importe quel outil compatible. L'identité n'est pas liée à un seul compte CardanoWall, car la graine la définit à elle seule.

Une rédaction pourrait gérer ainsi une identité « Équipe Presse ». Le rédacteur en chef crée l'identité, sauvegarde la graine et la partage avec des collègues sélectionnés via un canal de confiance. Chaque collègue importe la graine dans son propre compte et la déverrouille avec ses propres passkeys. À partir de ce moment, ils détiennent tous la même identité cryptographique.

Que peut faire chaque détenteur de la graine ?

Tout ce que l'identité peut faire. La graine est la racine, pas une permission restreinte.

Chaque détenteur peut :

• signer de nouveaux records Label 309 au nom de l'identité ;
• déchiffrer les records scellés adressés à l'identité ;
• lire les records scellés entrants une fois qu'il les a déverrouillés ;
• réexporter la graine et la transmettre à son tour ;
• importer l'identité dans un autre outil compatible, comme le CLI open source ;
• publier les adresses de réception de l'identité où bon lui semble.

Cela n'a rien à voir avec le fait d'inviter quelqu'un dans un espace de travail avec des permissions limitées et un bouton de révocation. Il n'existe aucun niveau « lecture seule » ou « publier mais sans déchiffrer ». Détenir la graine, c'est détenir toute l'identité.

Quand une identité partagée a-t-elle du sens ?

Quand le monde extérieur doit voir une seule identité qui représente un rôle, et non une personne.

Les cas raisonnables comprennent :

• une adresse de réception pour une rédaction ;
• l'identité de pièces d'un service juridique ;
• un contact pour la divulgation de failles de sécurité ;
• l'identité d'un comité d'audit ;
• l'identité d'une équipe de conformité ;
• l'identité des archives d'une entreprise ;
• l'identité partagée d'un petit projet.

Dans chacun de ces cas, l'identité publique représente une fonction ou une équipe, et le fait que plusieurs personnes se tiennent derrière elle est précisément l'objectif.

Quels sont les risques d'une identité partagée ?

L'attribution devient partagée, et l'exposition aussi.

Si plusieurs personnes peuvent signer au nom de la même identité, un vérificateur extérieur ne voit jamais qu'une seule clé publique Ed25519. La chaîne n'enregistre pas quel humain a utilisé la graine. Cela peut être exactement ce que l'équipe souhaite — ou un véritable problème de responsabilité, selon la situation.

Les autres risques découlent de la même racine :

• n'importe quel membre peut divulguer la graine, délibérément ou par accident ;
• un seul appareil compromis peut compromettre toute l'identité ;
• un ancien membre peut conserver une copie après son départ ;
• chaque record scellé envoyé à l'identité est lisible par tous les détenteurs de la graine ;
• aucune rotation de clés n'est prévue — changer de clés revient à passer à une nouvelle identité.

L'autorité partagée fonctionne, mais elle exige une discipline opérationnelle autour d'elle.

Comment CardanoWall gère-t-il cela entre les comptes ?

Chaque compte conserve sa propre copie chiffrée de l'identité partagée.

Si deux personnes — appelons-les Alice et Bob — importent toutes deux la même graine, chaque compte obtient son propre lien compte-vers-identité et son propre coffre chiffré. Les passkeys d'Alice déverrouillent le coffre d'Alice ; ceux de Bob déverrouillent le sien. La même identité cryptographique apparaît simplement dans les deux comptes, sans aucun état partagé côté serveur entre eux.

Pour rattacher une identité préexistante, celui qui l'importe doit prouver qu'il détient réellement la graine — et non simplement qu'il connaît les clés publiques, que n'importe qui peut lire depuis un profil ou depuis la chaîne. Le compte signe un défi serveur à usage unique avec la clé dérivée de la graine avant que le lien ne soit créé. Cela empêche quelqu'un de rattacher une identité dont il ne connaît que les clés publiques, tout en laissant un véritable détenteur de la graine établir le lien.

Les libellés d'affichage restent privés à chaque compte. Alice pourrait étiqueter l'identité « Équipe Presse » ; Bob pourrait l'étiqueter « Réception ». Ces libellés résident à l'intérieur du coffre chiffré de chaque compte, jamais dans l'identité publique, de sorte qu'aucun compte ne peut voir le libellé de l'autre et qu'une fuite de base de données n'en révèle aucun.

La facturation reste, elle aussi, propre à chaque compte. Si Alice publie depuis son compte, c'est le compte d'Alice qui paie. Il n'existe aucun solde partagé, car aucun solde ne pourrait être imposé cryptographiquement dès lors que quiconque détient la graine peut de toute façon publier.

Une identité partagée peut-elle être révoquée pour une seule personne ?

Pas cryptographiquement — pas une fois que cette personne connaît déjà la graine.

CardanoWall peut retirer l'identité du coffre d'un compte, retirer un passkey ou désactiver l'identité dans un compte donné. Ce sont de véritables contrôles au niveau du service, et ils comptent pour les comptes que vous contrôlez.

Mais aucun d'eux n'atteint une copie de la graine qui réside déjà dans le gestionnaire de mots de passe de quelqu'un, sur une impression, dans sa mémoire, dans une sauvegarde, dans un outil de bureau ou dans un second compte. La connaissance de 32 octets ne peut pas être rappelée.

Ainsi, si quelqu'un qui détenait la graine ne devrait plus avoir d'autorité, la démarche honnête consiste à créer une nouvelle identité et à retirer l'ancienne — et non à prétendre que l'ancienne graine peut redevenir secrète.

Quelle est une bonne procédure pour une identité partagée ?

Traitez la graine comme le secret partagé de grande valeur qu'elle est.

Avant que quiconque la partage, l'équipe devrait s'accorder sur :

• qui est autorisé à détenir la graine ;
• comment la graine est transférée (en personne, ou chiffrée de bout en bout) ;
• où réside la copie de sauvegarde faisant autorité ;
• qui peut ajouter l'identité à un compte ;
• quels passkeys déverrouillent le coffre de chaque compte ;
• qui est autorisé à publier au nom de l'identité ;
• ce qui se passe lorsqu'une personne s'en va ;
• quand l'identité doit être remplacée ;
• où les nouvelles clés publiques sont annoncées.

Mettez cela par écrit avant qu'un incident ou un changement d'effectif ne force la décision sous pression.

Une équipe devrait-elle utiliser une seule identité partagée pour tout ?

Généralement non.

Des identités distinctes gardent les flux de travail propres et limitent les dégâts. Une entreprise pourrait gérer une identité pour les divulgations de sécurité, une autre pour les pièces juridiques, une autre pour les versions publiques et une autre pour les audits internes.

Cette séparation limite le rayon d'impact. Si une identité est compromise, les autres n'héritent pas automatiquement de la compromission. Elle facilite aussi le raisonnement sur le carnet d'adresses et le mode liste blanche, puisque chaque identité a une finalité claire et restreinte.

Que faire lorsque l'équipe change ?

Créer une nouvelle identité. La connaissance de l'ancienne graine ne peut pas être révoquée, donc une rupture nette est la seule véritable solution.

Lorsqu'une identité partagée est compromise, ou qu'un ancien détenteur doit perdre l'accès, la marche à suivre est la suivante :

1. créer une identité fraîche et sauvegarder sa nouvelle graine ;
2. ne partager la nouvelle graine qu'avec les membres qui doivent encore la détenir ;
3. mettre à jour les profils publics, les adresses de réception et les contacts avec les nouvelles clés ;
4. désactiver l'ancienne identité dans les comptes que vous contrôlez ;
5. cesser d'utiliser les anciennes adresses de réception ;
6. éventuellement publier un record au nom de la nouvelle identité qui remplace l'ancienne.

Les records scellés déjà adressés à l'ancienne clé restent lisibles par tous ceux qui ont un jour détenu l'ancienne graine — y compris la personne dont vous vous séparez. C'est une propriété du chiffrement vers une clé publique de long terme, pas un défaut que vous pouvez corriger. Planifiez en conséquence ; ne prétendez pas que l'ancienne graine peut cesser d'avoir été partagée.

La version courte

Les identités d'équipe partagées sont puissantes, mais dénuées de nuance.

Elles permettent à une équipe d'exploiter une seule identité publique Label 309 sur plusieurs comptes et appareils. Mais quiconque détient la graine dispose de tout le pouvoir de signature et de déchiffrement, et ce pouvoir ne peut être ni accordé partiellement ni révoqué discrètement.

Utilisez une identité partagée pour les rôles qui ont véritablement besoin d'une autorité partagée. Utilisez des identités distinctes chaque fois que la responsabilité, la séparation ou la rotation comptent davantage.

Pour aller plus loin

• Votre identité est une graine
• Active, désactivée, supprimée : le cycle de vie d'une identité
• Comment CardanoWall stocke votre identité
• Des identités pour le travail sensible : pièces d'un lanceur d'alerte
• Le standard, au grand jour : label309.org et le code open source sur github.com/cardanowall