Entre v1.29.0 le 2025-12-27 et v1.30.0 le 2026-01-02, SSP a livré deux versions qui paraissent petites dans le changelog et grandes dans le diagramme d'architecture. v1.29.0 a ajouté l'authentification des requêtes — le portefeuille vérifie l'origine et l'intégrité de chaque requête dApp qu'il reçoit. v1.30.0 a ajouté la signature d'Identité SSP — le portefeuille peut prouver sa propre identité à un service distant, pas seulement signer une transaction. Ensemble, elles durcissent la surface des requêtes dApp ouverte par WalletConnect et transforment la fonctionnalité d'Identité originale en une primitive de première classe que les services peuvent défier.
L'authentification des requêtes arrive (v1.29.0)
Une requête dApp — signe ceci, approuve cela, bascule sur cette chaîne — arrive au portefeuille via un transport. Avec WalletConnect ce transport est une session relayée ; avec le fournisseur in-page c'est un message d'extension Chrome. Chacun a au moins une faille de confiance : le relais peut être usurpé, la page peut être un clone de phishing, le message peut être forgé.
L'authentification des requêtes ferme ces failles côté portefeuille. Avant que SSP n'affiche l'écran de confirmation, il vérifie qui demande et ce qu'il demande. L'origine revendiquée par la requête est comparée au transport qui l'a délivrée. La charge utile est vérifiée pour l'intégrité — le portefeuille ne signe pas une requête modifiée en transit. Et la requête est confrontée à l'état de session que le portefeuille détient déjà, pour qu'une requête rejouée depuis une autre session ne passe pas avec l'appairage de quelqu'un d'autre.
Rien de tout cela ne change ce que vous voyez quand une dApp légitime vous demande de signer. L'écran de confirmation a l'air identique. Ce qui change, c'est que le chemin entre la dApp et cet écran a maintenant des garde-fous que le portefeuille applique lui-même, au lieu de faire confiance au transport pour dire la vérité sur le destinataire de la livraison.
Suit la signature d'Identité (v1.30.0)
Une semaine plus tard, v1.30.0 est partie dans l'autre direction. Jusqu'alors, une Identité SSP pouvait signer des messages — des chaînes prouvant que l'utilisateur contrôle une clé. v1.30.0 ajoute la capacité de signer en tant qu'identité : un service distant peut émettre un défi nommant l'Identité SSP qu'il attend, et le portefeuille renvoie une signature qui lie la réponse à cette identité d'une manière vérifiable par le service.
La différence est subtile et porteuse. Signer un message prouve qu'une clé contrôle quelque chose. La signature d'identité prouve qu'une clé contrôle une identité nommée — un identifiant stable que le service a déjà associé à des permissions, soldes ou abonnements. Pour les services qui doivent savoir non seulement « y a-t-il un utilisateur ? » mais « est-ce le même utilisateur qui a créé ce compte ? », la signature d'identité boucle la boucle. v1.30.0 a aussi poli la gestion des pop-ups de requête — moins de scintillement, moins de pop-ups perdus, retour au focus plus rapide.
Pourquoi cela compte pour les dApps
Le modèle de menaces dApp partage un petit ensemble de causes racines. Usurpation d'origine — une page malveillante prétend être une page de confiance. Requêtes rejouées — une charge utile signée dans une session est capturée et soumise dans une autre. Surfaces de phishing — une requête qui paraît légitime à l'écran de confirmation est en réalité dirigée vers le contrat d'un attaquant.
L'authentification des requêtes resserre les trois parce que le portefeuille cesse de traiter le transport comme faisant autorité. L'origine doit correspondre au transport, la charge utile doit correspondre à ce qui a été envoyé, la session doit correspondre à celle qui a été appariée. Chaque vérification est petite isolément ; ensemble, elles font de l'écran de confirmation quelque chose à quoi l'utilisateur peut se fier pour refléter la réalité. La signature d'identité resserre une attaque différente — la prise de compte par réappariement — parce qu'un service qui demande au portefeuille de signer en tant qu'identité nommée transforme « un portefeuille s'est connecté » en lien vérifiable.
Comment cela s'articule avec WalletConnect
WalletConnect a ouvert la porte à des milliers de dApps. v1.29.0 a posé la serrure sur cette porte, et v1.30.0 a posé la sonnette. Les deux atterrissent sur la même surface : le flux de requêtes. L'authentification des requêtes garantit que la requête vue par le portefeuille est celle envoyée par la dApp. La signature d'identité garantit que la réponse vue par la dApp est celle envoyée par votre portefeuille, signée par l'identité que la dApp attendait. Le duo transforme une session WalletConnect de « deux extrémités échangeant des blobs » en « deux extrémités qui peuvent chacune prouver à l'autre qui elles sont ».
De l'Identité à la signature d'Identité
La fonctionnalité d'Identité SSP originale a donné au portefeuille une surface d'identité stable — une adresse dérivée pour la messagerie et les preuves, distincte des adresses transactionnelles depuis lesquelles vous dépensez. C'était l'introduction. v1.30.0 est la suite : la même identité, désormais utilisable comme un identifiant qu'un service peut demander par nom et vérifier de son côté.
C'est à cela que ressemble un portefeuille qui devient une primitive d'identité de première classe et non plus un simple porteur de clés. v1.29.0 rend les entrées dignes de confiance ; v1.30.0 rend les sorties vérifiables. La plupart des utilisateurs ne verront jamais la différence directement. Les dApps et services qui s'intègrent contre cette surface, en revanche, constateront que SSP peut désormais prouver qui il est et vérifier qui demande — à chaque fois.