Zwischen v1.29.0 am 2025-12-27 und v1.30.0 am 2026-01-02 hat SSP zwei Releases ausgeliefert, die im Changelog klein und im Architekturdiagramm groß wirken. v1.29.0 hat Request-Authentifizierung ergänzt — die Wallet prüft Herkunft und Integrität jeder eingehenden dApp-Anfrage. v1.30.0 hat SSP Identity Signing ergänzt — die Wallet kann ihre eigene Identität gegenüber einem entfernten Dienst beweisen, nicht nur eine Transaktion signieren. Zusammen härten sie die dApp-Request-Oberfläche, die mit WalletConnect geöffnet wurde, und machen aus dem ursprünglichen Identity-Feature eine erstklassige Primitive, die Dienste herausfordern können.
Request-Authentifizierung landet (v1.29.0)
Eine dApp-Anfrage — signiere dies, genehmige das, wechsle auf diese Chain — erreicht die Wallet über einen Transport. Bei WalletConnect ist dieser Transport eine über Relay vermittelte Sitzung; beim In-Page-Provider eine Chrome-Erweiterungs-Nachricht. Jeder Transport hat mindestens eine Vertrauenslücke: das Relay kann gefälscht werden, die Seite kann ein Phishing-Klon sein, die Nachricht kann manipuliert werden.
Die Request-Authentifizierung schließt diese Lücken von der Wallet-Seite aus. Bevor SSP den Bestätigungsbildschirm rendert, prüft sie, wer fragt und was. Die in der Anfrage behauptete Herkunft wird mit dem Transport abgeglichen, der sie geliefert hat. Die Payload wird auf Integrität geprüft — die Wallet signiert keine Anfrage, die im Transit verändert wurde. Und die Anfrage wird gegen den Sitzungszustand geprüft, den die Wallet bereits hält, damit eine wiedergespielte Anfrage aus einer anderen Sitzung nicht mit fremdem Pairing durchrutscht.
Nichts davon ändert, was Sie sehen, wenn eine legitime dApp eine Signatur anfordert. Der Bestätigungsbildschirm sieht gleich aus. Was sich ändert: Der Weg zwischen der dApp und diesem Bildschirm hat jetzt Leitplanken, die die Wallet selbst durchsetzt, statt darauf zu vertrauen, dass der Transport ehrlich angibt, für wen er liefert.
Identity Signing folgt (v1.30.0)
Eine Woche später ging v1.30.0 in die andere Richtung. Bis dahin konnte eine SSP-Identität Nachrichten signieren — Strings, die belegen, dass der Nutzer einen Schlüssel kontrolliert. v1.30.0 ergänzt die Möglichkeit, als Identität zu signieren: Ein entfernter Dienst kann eine Challenge ausstellen, die die erwartete SSP-Identität benennt, und die Wallet gibt eine Signatur zurück, die die Antwort so an diese Identität bindet, dass der Dienst sie verifizieren kann.
Der Unterschied ist subtil und tragend. Eine Nachricht zu signieren beweist, dass ein Schlüssel etwas kontrolliert. Identity-Signing beweist, dass ein Schlüssel eine benannte Identität kontrolliert — ein stabiles Handle, das der Dienst bereits mit Rechten, Salden oder Abos verknüpft hat. Für Dienste, die nicht nur wissen müssen „ist ein Nutzer da?“, sondern „ist es derselbe Nutzer, der das Konto angelegt hat?“, schließt Identity Signing den Kreis. v1.30.0 hat außerdem die Behandlung von Request-Popups poliert — weniger Flackern, weniger verlorene Popups, schnellerer Rückkehr-Fokus.
Warum das für dApps zählt
Das dApp-Bedrohungsmodell teilt einen kleinen Satz an Grundursachen. Origin-Spoofing — eine bösartige Seite gibt sich als eine vertrauenswürdige aus. Wiedergespielte Anfragen — eine in einer Sitzung signierte Payload wird abgefangen und in einer anderen eingereicht. Phishing-Oberflächen — eine Anfrage, die auf dem Bestätigungsbildschirm legitim wirkt, geht in Wahrheit an den Vertrag eines Angreifers.
Die Request-Authentifizierung verengt alle drei, weil die Wallet aufhört, den Transport als maßgeblich zu behandeln. Die Herkunft muss zum Transport passen, die Payload muss zum Gesendeten passen, die Sitzung muss zu der gepairten passen. Jeder Check ist für sich klein; zusammen machen sie den Bestätigungsbildschirm zu etwas, dem der Nutzer trauen kann, die Realität abzubilden. Identity Signing verengt einen anderen Angriff — die Kontoübernahme durch Neu-Pairing — weil ein Dienst, der die Wallet bittet, als benannte Identität zu signieren, aus „eine Wallet hat sich angemeldet“ eine verifizierbare Bindung macht.
Wie es zu WalletConnect passt
WalletConnect hat die Tür zu Tausenden dApps geöffnet. v1.29.0 hat das Schloss an diese Tür gebracht, und v1.30.0 die Klingel. Beide landen auf derselben Oberfläche: dem Request-Flow. Die Request-Authentifizierung stellt sicher, dass die Anfrage, die die Wallet sieht, die ist, die die dApp gesendet hat. Identity Signing stellt sicher, dass die Antwort, die die dApp sieht, die ist, die Ihre Wallet gesendet hat, signiert von der Identität, die die dApp erwartet hat. Das Paar macht aus einer WalletConnect-Sitzung von „zwei Endpunkten, die Blobs austauschen“ ein „zwei Endpunkten, die einander beweisen können, wer sie sind“.
Von Identity zu Identity-Signing
Das ursprüngliche SSP-Identity-Feature hat der Wallet eine stabile Identitätsoberfläche gegeben — eine abgeleitete Adresse für Messaging und Nachweise, getrennt von den transaktionalen Adressen, von denen Sie ausgeben. Das war die Einführung. v1.30.0 ist die Fortsetzung: dieselbe Identität, jetzt als Credential nutzbar, das ein Dienst namentlich anfordern und auf seiner Seite verifizieren kann.
So sieht es aus, wenn eine Wallet zur erstklassigen Identitäts-Primitive wird statt zum reinen Schlüsselverwalter. v1.29.0 macht die Eingaben vertrauenswürdig; v1.30.0 macht die Ausgaben verifizierbar. Die meisten Nutzer werden den Unterschied nie direkt sehen. Die dApps und Dienste, die gegen diese Oberfläche integrieren, werden aber feststellen, dass SSP jetzt beweisen kann, wer es ist, und prüfen kann, wer fragt — jedes Mal.