Identità di team condivise: un'identità, molte persone

Un team può condividere un'identità CardanoWall, ma condividere un'identità significa condividere l'Identity Seed. Non esiste una versione più leggera di questo gesto.

Consegnare il seed è una delega completa. Chiunque lo detenga può firmare record come quell'identità e decifrare i record sigillati indirizzati a essa. CardanoWall può rendere comodo il flusso di lavoro tra account separati, ma non può trasformare un seed in un'autorità parziale, revocabile e per singola persona. La crittografia non si piega in quel modo.

Quindi usa un'identità condivisa solo quando l'autorità condivisa è esattamente ciò che vuoi.

Cos'è un'identità di team condivisa?

È un'identità Label 309 usata da più di una persona o di un account.

Un'identità Label 309 è radicata in un singolo Identity Seed da 32 byte. Chiunque importi quel seed ricostruisce la stessa chiave di firma e le stesse chiavi di ricezione, in qualsiasi account e in qualsiasi strumento compatibile. L'identità non è legata a un solo account CardanoWall, perché è il seed da solo a definirla.

Una redazione potrebbe gestire così un'identità «Press Team». Il caporedattore crea l'identità, salva il seed e lo condivide con colleghi selezionati tramite un canale fidato. Ogni collega importa il seed nel proprio account e lo sblocca con le proprie passkey. Da quel momento, tutti loro detengono la stessa identità crittografica.

Cosa può fare ogni detentore del seed?

Tutto ciò che l'identità può fare. Il seed è la radice, non un permesso limitato a uno scopo.

Ogni detentore può:

• firmare nuovi record Label 309 come l'identità;
• decifrare i record sigillati indirizzati all'identità;
• leggere i record sigillati in arrivo una volta sbloccati;
• esportare di nuovo il seed e ricondividerlo;
• importare l'identità in un altro strumento compatibile, come la CLI open-source;
• pubblicare ovunque gli indirizzi di ricezione dell'identità.

Non è come invitare qualcuno in uno spazio di lavoro con permessi limitati e un pulsante di revoca. Non esiste un livello «sola lettura» o «pubblica-ma-non-decifrare». Chi detiene il seed detiene l'intera identità.

Quando ha senso un'identità condivisa?

Quando il mondo esterno deve vedere un'identità che rappresenta un ruolo, non una persona.

I casi ragionevoli includono:

• un indirizzo di ricezione di una redazione;
• un'identità per le prove di un ufficio legale;
• un contatto per le segnalazioni di sicurezza;
• un'identità per un comitato di audit;
• un'identità per un team di compliance;
• un'identità per i record aziendali;
• l'identità condivisa di un piccolo progetto.

In ciascuno di questi casi, l'identità pubblica rappresenta una funzione o un team, e il fatto che dietro di essa ci siano più persone è proprio il punto.

Quali sono i rischi di un'identità condivisa?

L'attribuzione diventa condivisa, e così l'esposizione.

Se più persone possono firmare come la stessa identità, un verificatore esterno vede sempre e solo una chiave pubblica Ed25519. La catena non registra quale essere umano abbia usato il seed. Questo può essere esattamente ciò che il team vuole — oppure un vero problema di responsabilità, a seconda della situazione.

Gli altri rischi derivano dalla stessa radice:

• un qualsiasi membro può divulgare il seed, deliberatamente o per errore;
• un solo dispositivo compromesso può compromettere l'intera identità;
• un ex membro può conservarne una copia dopo essersene andato;
• ogni record sigillato inviato all'identità è leggibile da ogni detentore del seed;
• non esiste alcuna rotazione delle chiavi — cambiare le chiavi significa passare a una nuova identità.

L'autorità condivisa funziona, ma richiede disciplina operativa attorno a sé.

Come gestisce CardanoWall tutto questo tra gli account?

Ogni account conserva la propria copia cifrata dell'identità condivisa.

Se due persone — chiamiamole Alice e Bob — importano entrambe lo stesso seed, ogni account ottiene il proprio collegamento account-identità e il proprio vault cifrato. Le passkey di Alice sbloccano il vault di Alice; quelle di Bob sbloccano quello di Bob. La stessa identità crittografica compare semplicemente in entrambi gli account, senza alcuno stato condiviso lato server tra di essi.

Per collegare un'identità preesistente, chi la importa deve dimostrare di detenere davvero il seed — non semplicemente di conoscere le chiavi pubbliche, che chiunque può leggere da un profilo o dalla catena. L'account firma una sfida una tantum del server con la chiave derivata dal seed prima che il collegamento venga creato. Questo impedisce a qualcuno di collegare un'identità di cui conosce solo le chiavi pubbliche, lasciando però che un autentico detentore del seed la colleghi.

Le etichette di visualizzazione restano private a ogni account. Alice potrebbe etichettare l'identità come «Press Team»; Bob potrebbe etichettarla come «Intake». Quelle etichette vivono all'interno del vault cifrato di ciascun account, mai nell'identità pubblica, così nessun account può vedere l'etichetta dell'altro e una violazione del database non ne rivela nessuna.

Anche la fatturazione resta per account. Se Alice pubblica dal suo account, paga l'account di Alice. Non c'è alcun saldo condiviso, perché nessun saldo potrebbe essere imposto crittograficamente quando chiunque abbia il seed può comunque pubblicare.

Si può revocare un'identità condivisa a una singola persona?

Non crittograficamente — non una volta che quella persona conosce già il seed.

CardanoWall può rimuovere l'identità dal vault di un account, rimuovere una passkey o disattivare l'identità in un dato account. Sono controlli reali a livello di servizio, e contano per gli account che controlli.

Ma nessuno di essi raggiunge una copia del seed che vive già nel password manager di qualcuno, in una stampa, nella sua memoria, in un backup, in uno strumento desktop o in un secondo account. La conoscenza di 32 byte non si può richiamare indietro.

Quindi se qualcuno che deteneva il seed non dovrebbe più avere autorità, la mossa onesta è creare una nuova identità e ritirare quella vecchia — non fingere che il vecchio seed possa tornare a essere segreto.

Qual è una buona procedura per un'identità condivisa?

Tratta il seed come il segreto condiviso di alto valore che è.

Prima che qualcuno lo condivida, il team dovrebbe concordare:

• chi è autorizzato a detenere il seed;
• come si trasferisce il seed (di persona o cifrato end-to-end);
• dove risiede la copia di backup autorevole;
• chi può aggiungere l'identità a un account;
• quali passkey sbloccano il vault di ciascun account;
• chi è autorizzato a pubblicare sotto l'identità;
• cosa succede quando qualcuno se ne va;
• quando l'identità va sostituita;
• dove vengono annunciate le nuove chiavi pubbliche.

Mettilo per iscritto prima che un incidente o un cambio di personale costringa a decidere sotto pressione.

Un team dovrebbe usare un'unica identità condivisa per tutto?

Di solito no.

Identità separate mantengono puliti i flussi di lavoro e contengono i danni. Un'azienda potrebbe gestire un'identità per le segnalazioni di sicurezza, un'altra per le prove legali, un'altra per i comunicati pubblici e un'altra ancora per gli audit interni.

Quella separazione limita il raggio d'impatto. Se un'identità viene compromessa, le altre non ne ereditano automaticamente la compromissione. Rende anche più semplice ragionare sulla rubrica e sulla modalità whitelist, perché ogni identità ha uno scopo chiaro e circoscritto.

Cosa fai quando il team cambia?

Crea una nuova identità. La conoscenza del vecchio seed non si può revocare, quindi un taglio netto è l'unica vera soluzione.

Quando un'identità condivisa viene compromessa, o quando un ex detentore deve perdere l'accesso, il percorso è:

1. crea un'identità nuova e salva il suo nuovo seed;
2. condividi il nuovo seed solo con i membri che dovrebbero ancora averlo;
3. aggiorna i profili pubblici, gli indirizzi di ricezione e i contatti con le nuove chiavi;
4. disattiva la vecchia identità negli account che controlli;
5. smetti di usare i vecchi indirizzi di ricezione;
6. facoltativamente, pubblica un record sotto la nuova identità che sostituisce quello vecchio.

I record sigillati già indirizzati alla vecchia chiave restano leggibili da chiunque abbia mai detenuto il vecchio seed — inclusa la persona da cui ti stai allontanando con la rotazione. È una proprietà del cifrare verso una chiave pubblica di lungo termine, non un bug che puoi correggere. Pianifica tenendone conto; non fingere che il vecchio seed possa essere ricondiviso all'indietro.

La versione breve

Le identità di team condivise sono potenti e poco selettive.

Permettono a un team di operare con un'unica identità pubblica Label 309 su più account e dispositivi. Ma chiunque abbia il seed ha pieno potere di firma e di decifratura, e quel potere non può essere concesso parzialmente né revocato in silenzio.

Usa un'identità condivisa per i ruoli che hanno davvero bisogno di autorità condivisa. Usa identità separate ogni volta che la responsabilità, la separazione o la rotazione contano di più.

Per approfondire

• La tua identità è un seed
• Attiva, disattivata, eliminata: il ciclo di vita di un'identità
• Come CardanoWall conserva la tua identità
• Identità per lavori sensibili: prove dei whistleblower
• Lo standard, allo scoperto: label309.org e il codice open-source su github.com/cardanowall