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.
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.