Tra v1.29.0 il 2025-12-27 e v1.30.0 il 2026-01-02, SSP ha rilasciato due versioni che sembrano piccole nel changelog e grandi nel diagramma di architettura. v1.29.0 ha aggiunto l'autenticazione delle richieste — il wallet verifica origine e integrità di ogni richiesta dApp che riceve. v1.30.0 ha aggiunto la firma di Identità SSP — il wallet può provare la propria identità a un servizio remoto, non solo firmare una transazione. Insieme induriscono la superficie delle richieste dApp aperta con WalletConnect e trasformano la funzione di Identità originale in una primitiva di prima classe che i servizi possono sfidare.
Arriva l'autenticazione delle richieste (v1.29.0)
Una richiesta dApp — firma questo, approva quello, passa a questa chain — arriva al wallet su un trasporto. Con WalletConnect quel trasporto è una sessione relayed; con il provider in-page è un messaggio dell'estensione Chrome. Ognuno ha almeno una falla di fiducia: il relay può essere impersonato, la pagina può essere un clone di phishing, il messaggio può essere falsificato.
L'autenticazione delle richieste chiude quelle falle dal lato del wallet. Prima che SSP renderizzi la schermata di conferma, verifica chi chiede e cosa chiede. L'origine rivendicata dalla richiesta è confrontata con il trasporto che l'ha consegnata. Il payload è controllato per integrità — il wallet non firma una richiesta modificata in transito. E la richiesta è confrontata con lo stato di sessione che il wallet già detiene, così una richiesta rigiocata da un'altra sessione non passa con il pairing di qualcun altro.
Nulla di tutto questo cambia ciò che vedi quando una dApp legittima ti chiede di firmare. La schermata di conferma sembra la stessa. Ciò che cambia è che il percorso tra la dApp e quella schermata ora ha guardrail che il wallet impone da solo, invece di fidarsi del trasporto perché dica la verità su per chi sta consegnando.
Segue Identity Signing (v1.30.0)
Una settimana dopo, v1.30.0 è andata nell'altra direzione. Fino ad allora, un'Identità SSP poteva firmare messaggi — stringhe che provano che l'utente controlla una chiave. v1.30.0 aggiunge la possibilità di firmare come identità: un servizio remoto può emettere una sfida che nomina l'Identità SSP che si aspetta, e il wallet restituisce una firma che lega la risposta a quell'identità in un modo che il servizio può verificare.
La differenza è sottile e portante. Firmare un messaggio prova che una chiave controlla qualcosa. La firma di identità prova che una chiave controlla un'identità nominata — un identificatore stabile che il servizio ha già associato a permessi, saldi o abbonamenti. Per i servizi che devono sapere non solo «c'è un utente?» ma «è lo stesso utente che ha creato questo account?», la firma di identità chiude il cerchio. v1.30.0 ha anche rifinito la gestione dei pop-up di richiesta — meno sfarfallio, meno pop-up persi, ritorno al focus più rapido.
Perché conta per le dApp
Il modello di minacce dApp condivide un piccolo insieme di cause profonde. Spoofing di origine — una pagina malevola finge di essere una di fiducia. Richieste rigiocate — un payload firmato in una sessione è catturato e inviato in un'altra. Superfici di phishing — una richiesta che sembra legittima sulla schermata di conferma è in realtà diretta al contratto di un attaccante.
L'autenticazione delle richieste restringe tutti e tre perché il wallet smette di trattare il trasporto come autorevole. L'origine deve corrispondere al trasporto, il payload deve corrispondere a quanto inviato, la sessione deve corrispondere a quella accoppiata. Ogni controllo è piccolo di per sé; insieme rendono la schermata di conferma qualcosa di cui l'utente può fidarsi per riflettere la realtà. La firma di identità restringe un attacco diverso — la presa di controllo dell'account per re-pairing — perché un servizio che chiede al wallet di firmare come identità nominata trasforma «un wallet ha effettuato l'accesso» in un legame verificabile.
Come si integra con WalletConnect
WalletConnect ha aperto la porta a migliaia di dApp. v1.29.0 ha aggiunto la serratura a quella porta, e v1.30.0 ha aggiunto il campanello. Entrambe atterrano sulla stessa superficie: il flusso delle richieste. L'autenticazione delle richieste garantisce che la richiesta vista dal wallet sia quella inviata dalla dApp. La firma di identità garantisce che la risposta vista dalla dApp sia quella inviata dal tuo wallet, firmata dall'identità che la dApp si aspettava. La coppia trasforma una sessione WalletConnect da «due estremi che scambiano blob» a «due estremi che possono provarsi a vicenda chi sono».
Da Identità a Identity-Signing
La funzione di Identità SSP originale ha dato al wallet una superficie di identità stabile — un indirizzo derivato per messaggistica e prove, separato dagli indirizzi transazionali da cui spendi. Quella era l'introduzione. v1.30.0 è il seguito naturale: la stessa identità, ora utilizzabile come credenziale che un servizio può chiedere per nome e verificare dal suo lato.
È così che un wallet diventa una primitiva di identità di prima classe invece di un semplice portachiavi. v1.29.0 rende gli input affidabili; v1.30.0 rende gli output verificabili. La maggior parte degli utenti non vedrà mai la differenza direttamente. Le dApp e i servizi che si integrano contro questa superficie, però, scopriranno che SSP ora può provare chi è e verificare chi chiede — ogni volta.