Nostr WoT SDK stabilise la récupération passkey et la signature fournisseur

Une passkey dérivée n'est pas une passkey de stockage

Le paquet d'identité distingue deux modes. En mode dérivé, la clé privée Nostr est calculée de façon déterministe depuis la sortie PRF WebAuthn. En mode stocké, cette sortie protège une clé privée existante, une graine ou un coffre contenant plusieurs comptes.

Les nouvelles informations d'identification portent un identifiant marqué qui annonce le mode avant toute lecture du stockage. Une passkey stockée n'est jamais interprétée silencieusement comme dérivée. Si une ancienne passkey non marquée ne fournit pas assez de preuves, resolvePasskeyIdentity renvoie ambiguous avec une clé publique candidate. L'application doit l'afficher et demander une confirmation avant de dériver un secret.

Cette séparation protège la continuité de l'identité. Le mode dérivé lie l'identité au calcul de la passkey. Le mode stocké permet de protéger à nouveau la même identité sous un autre relying party, à condition que l'hôte l'importe et la chiffre délibérément.

La récupération reste contrôlée par l'hôte

@nostr-wot/identity/vault fournit la cryptographie portable, la validation des enregistrements et l'orchestration. Il n'appelle aucun authentificateur et n'ouvre aucune connexion relais. L'hôte fournit WebAuthn ou le client natif, le transport, la signature et la vérification des événements ainsi que l'interface de consentement.

Un enregistrement peut contenir une clé ou un coffre à plusieurs comptes. Le chiffrement authentifie le type, l'identifiant du relying party, l'auteur et l'identifiant de la passkey. Avant d'écrire, le fournisseur doit inspecter le stockage existant. Tout blob non vide exige une confirmation de remplacement, même si les anciennes données sont illisibles. Un refus ou un échec n'est jamais redirigé silencieusement vers les relais.

Le stockage sur relais est également explicite. L'hôte doit l'autoriser, choisir les relais et recevoir au moins un accusé de réception. Les nouveaux enregistrements utilisent le kind provisoire 31778, qui n'est pas réservé par un NIP. Les formats hérités restent lisibles. Une écriture locale ou un accusé de réception ne prouve pas qu'un autre appareil pourra restaurer le compte.

Deux voies pour les comptes Nosskey existants

nostr-wot-sdk 3.0.1 lit les sauvegardes Nosskey explicites sous forme de clé directe ou enveloppée par NIP-44, tout en conservant leurs entrées PRF d'origine. La clé publique récupérée est comparée à la sauvegarde et le lecteur ne bascule pas vers un autre mode en l'absence de preuve.

Les applications qui ne souhaitent pas importer de clé privée peuvent utiliser NosskeyIframeSigner. Il verrouille la fenêtre iframe, l'origine HTTPS et le compte choisi, vérifie le contenu et les signatures, borne la durée des requêtes et exige une fermeture explicite. Le consentement du fournisseur et la prise en charge du navigateur restent nécessaires.

Ce qui change pour les intégrateurs

Les paquets stables s'installent sans tag de préversion :

npm install @nostr-wot/identity@1.1.0 nostr-wot-sdk@3.0.1 nostr-tools

L'hôte doit toujours tester les authentificateurs et la synchronisation sur de vrais appareils. Il doit préserver les champs inconnus lors de la réécriture d'un coffre, effacer les tampons secrets, confirmer la clé publique pendant une migration et expliquer où se trouve la récupération. Les enregistrements sont des instantanés qui doivent être actualisés après une modification de compte.

Les tags stables rendent les API testées installables sans next. Ils ne transforment pas les passkeys en sauvegarde universelle. Autoriser un relying party reste une décision de confiance, le kind provisoire peut évoluer et chaque application conserve la responsabilité du consentement, de la durabilité et d'une récupération vérifiable.