nostr/nips
1
0
Fork 0
mirror of https://github.com/nostr-protocol/nips.git synced 2024-12-22 16:35:52 -05:00
Code Issues Actions Packages Projects Releases Wiki Activity

Suggested additions to NIP-05 to enhance security

Browse Source 
Proposing a couple of changes to the NIP-05 protocol to reduce the chance of fraudulent use of "verified" public keys.  At present, I could create an account on a well-known verifying server under a random name, and then send DMs pretending to be someone else, and there's no easy way for users to tell who the verifying account actually belongs to.

As well as displaying the name of the account on the verifying server, this PR suggests an enhancement to the JSON data being returned so that clients can redirect the user to the user's profile page on the server.  This will make it much easier for users to check that someone who claims to have verified their Nostr account is who they claim to be.
This commit is contained in:
Erik Westra 2023-02-06 10:11:26 +13:00 committed by GitHub
parent 025beb332c
commit cf053d2a41
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 10 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

11
05.md
View File

@ -35,7 +35,7 @@ It will make a GET request to `https://example.com/.well-known/nostr.json?name=b
} }
```` ````
or with the **optional** `"relays"` attribute: or with the **optional** `"relays"` and/or `"account_uris"` attributes:
```json ```json
{ {
@ -44,6 +44,9 @@ or with the **optional** `"relays"` attribute:
}, },
"relays": { "relays": {
"b0635d6a9851d3aed0cd6c495b282167acf761729078d975fc341b22650b07b9": [ "wss://relay.example.com", "wss://relay2.example.com" ] "b0635d6a9851d3aed0cd6c495b282167acf761729078d975fc341b22650b07b9": [ "wss://relay.example.com", "wss://relay2.example.com" ]
},
"account_uris": {
"b0635d6a9851d3aed0cd6c495b282167acf761729078d975fc341b22650b07b9": "https://bob.com/profile/bob"
} }
} }
```` ````
@ -52,6 +55,8 @@ If the pubkey matches the one given in `"names"` (as in the example above) that
The optional `"relays"` attribute may contain an object with public keys as properties and arrays of relay URLs as values. When present, that can be used to help clients learn in which relays that user may be found. Web servers which serve `/.well-known/nostr.json` files dynamically based on the query string SHOULD also serve the relays data for any name they serve in the same reply when that is available. The optional `"relays"` attribute may contain an object with public keys as properties and arrays of relay URLs as values. When present, that can be used to help clients learn in which relays that user may be found. Web servers which serve `/.well-known/nostr.json` files dynamically based on the query string SHOULD also serve the relays data for any name they serve in the same reply when that is available.
The optional `"account_uris"` attribute may contain an object with public keys as properties and URIs as values. When present, this allows clients to direct their users to a URI which provides more information about the account on the server which was used to validate the given public key. Clients should ignore any URIs which don't include the server's `<domain>`.
## Finding users from their NIP-05 identifier ## Finding users from their NIP-05 identifier
A client may implement support for finding users' public keys from _internet identifiers_, the flow is the same as above, but reversed: first the client fetches the _well-known_ URL and from there it gets the public key of the user, then it tries to fetch the kind `0` event for that user and check if it has a matching `"nip05"`. A client may implement support for finding users' public keys from _internet identifiers_, the flow is the same as above, but reversed: first the client fetches the _well-known_ URL and from there it gets the public key of the user, then it tries to fetch the kind `0` event for that user and check if it has a matching `"nip05"`.
@ -66,6 +71,10 @@ For example, if after finding that `bob@bob.com` has the public key `abc...def`,
Keys must be returned in hex format. Keys in NIP-19 `npub` format are are only meant to be used for display in client UIs, not in this NIP. Keys must be returned in hex format. Keys in NIP-19 `npub` format are are only meant to be used for display in client UIs, not in this NIP.
### Clients should display the name used to verify the public key
While users can choose their own Nostr username, displaying that username beside the "verified" icon and the name of the verifying server alone is an invitation for abuse. A malicious user could verify their public key using one account name, and then display a different account name within Nostr, misleading users into thinking they are someone else. To prevent this, clients should display the user's account name on the verifying server, rather than (or in addition to) their self-selected username within Nostr.
### User Discovery implementation suggestion ### User Discovery implementation suggestion
A client can also use this to allow users to search other profiles. If a client has a search box or something like that, a user may be able to type "bob@example.com" there and the client would recognize that and do the proper queries to obtain a pubkey and suggest that to the user. A client can also use this to allow users to search other profiles. If a client has a search box or something like that, a user may be able to type "bob@example.com" there and the client would recognize that and do the proper queries to obtain a pubkey and suggest that to the user.