Merge pull request #227 from erikwestra/nip-05-security-proposal

Nip 05 security proposal

1 files changed, 10 insertions, 1 deletions

diff --git a/05.md b/05.md
index 992983f..d042b30 100644
--- a/05.md
+++ b/05.md
@@ -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
 {
@@ -44,6 +44,9 @@ or with the **optional** `"relays"` attribute:
   },
   "relays": {
     "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 `"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
 
 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.
 
+### 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
 
 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.