some thoughts on identity

[hckjck]

nostr is great!

...but, there is one fundamental problem I see. The identity.

The major thing I currently dislike about clients, is the fact of exporting and importing identity keypairs. IMHO this is a major security risk and caused by the definition itself.

NIP-01 defines the identity as followed.

https://github.com/nostr-protocol/nips/blob/2f84cd97e38c0a824cc27ea2ac976545e9e3f09e/01.md?plain=1#L13

In fact, a user can have multiple keypairs, depending on the amount of clients a user runs. This turns a keypair from a user identifier into a client identifier, what it actually is.

Thinking of keypairs identifying clients instead of users, lead me to the following definition.

Each client creates, loads and stores a unique cryptographic identifier in a secure place. This identifier represents client's identity. Client identifiers can not be exported by users. They are unique and bound to the client. New client identities can be created with the consequence of data loss.

User authentication represents an additional layer of abstraction. This could be introduced by identity providers. Same as relays, me as a user pick an identity provider of my choice I trust. There I build my user identity, which I can make authentic by social proofs. The identity provider allows me to manage clients which are associated with my user identity. The identity provider signs my client keys , so other clients can proof the authenticity and the ownership of clients. Making contacts with other clients, me as a user can decide, if I want to share only my client identity or my user identity. Both should be able to interact with the system, but on different identification level.

[fiatjaf]

If users have multiple public keys it becomes much harder for clients to find these users, display their metadata and their posts, interact with them etc. It ruins the simplicity completely.

[alexgleason]

See: https://nsecbunker.com

(I have also been thinking about mnemonic phrases)

[hckjck]

If users have multiple public keys it becomes much harder for clients to find these users, display their metadata and their posts, interact with them etc. It ruins the simplicity completely.

The client does not know anything about users, only clients. Clients are also only able to communication with other clients not users. Finding a client from its client identity is what the protocol currently does. To find a client via a user identity, the client would first need to request client identifiers from an identity provider bound to that user. Then everything would proceed as usual.

[staab]

Finding a client from its client identity is what the protocol currently does.

This is what Scuttlebutt does. The way nostr works, is you share keys between clients in a variety of ways.

That said, after working on encrypted chat for a while, I do think an identity layer would be a good enhancement to nostr. But it's a very hard problem involving a centralized name repository and stateful logic around key exchange and invalidation. It would be pointless to do it halfway.

[alexgleason]

Remote signers and hardware wallets are the way to go. In the Bitcoin future people will already have these things, so they just need to be extended for Nostr.

[mikedilger]

The problem of exporting a private key can be solved if people were interested in doing so. Gossip has exported private keys in a password-encrypted form since day 1, but other clients never adopted importing those. I suppose I screwed up the PR somewhat (didn't use TLV like I should have) and it had lots of churn based on feedback so I think people might have gotten lost in the changes. I should write a new PR and resurrect it. https://github.com/nostr-protocol/nips/pull/133

[BTW gossip still supports exported private keys in all 3 historical variants of that PR, just in case someone has one from way back]

[alexgleason]

@mikedilger Is it just a password protected zip, or a custom format?

[vitorpamplona]

The Identity issue was the reason I ditched Nostr when @fiatjaf first introduced it about 2-3 years ago. If you come from the corporate or the DID world, where they claim to have good solutions, Nostr's approach just looks wrong. However, I have worked with DID management and other types of identity management systems and I can tell you the problem is just delegated to the next guy at infinitum. Layers and layers of delegation. It's not actually fixed. When you analyze the full scope of what happens in DIDs or corporations, you will eventually find the weak link. And the weak link is basically a person, with a private key, trying to keep it as safe as possible, while signing for stuff from time to time. Which is exactly the same as we have in Nostr.

PS: Identity providers are cancer. Let's hope we don't need to bring them here to sell identity solutions to users.

I do think personal Signing Devices will help. A user's private key should be on 1 or 2 signing apps (say one for this phone and one for the computer). Signing apps basically implement NIP-46 while granting granular signing access to any other application the user might have on the phone or in the desktop/web. The idea is to minimize inputting the private key everywhere.

Social recoveries can be implemented by signing apps for cases where a user has their phone stolen and key rotation can be implemented at the protocol level. There were some ideas in the past. But basically, the current key includes a secret for the next key. And if the next key starts to be used, it invalidates the previous key. Relays and Clients keep track of the state of rotation.

Lots to do :)

[mikedilger]

@alexgleason custom format. https://github.com/nostr-protocol/nips/pull/133 scrypt key derivation, XChaCha20-Poly1305 encryption, associated data to remember if the private key was ever known to be handled insecurely (exported in cleartext, or imported from cleartext).