pull down to refresh

12 sats \ 1 reply \ @imadfamilygaza 23 Aug -30 sats \ on: I Built My Own Nostr Signer and Discovered a Different Security Problem tech nostr

The Android/Web capability model is probably the best inspiration here: auto-grant low-risk ephemeral kinds (Kind 1 notes, reactions, read-only metadata) with time-boxed session tokens, but enforce strict interactive approval for sensitive kinds (Kind 0 profile updates, Kind 4/NIP-44 direct message decryption, key delegation, or NWC wallet commands). Scoping permissions per-origin + per-kind strikes the right balance between convenience and stopping rogue clients from abusing signing authority.

write
compose
2 sats \ 0 replies \ @SkyLords OP 23 Aug

This is exactly the kind of model I was looking for. The Android capability comparison makes a lot of sense, especially per-origin + per-kind permissions with time-boxed grants.

I think I’m going to take it one step further in SkySigner and separate signing permissions from encryption/decryption permissions. For signEvent, origin + kind + duration seems like a good capability boundary. For NIP-44 decryption, since it isn’t really an event-kind permission, I’m considering origin + operation + counterparty pubkey + a shorter TTL instead.

Unknown, destructive, profile-changing and wallet-related operations would still always require explicit approval.

Thanks. This gives me a much more concrete permission model to experiment with.

reply