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

NIP-85: Attestation of DNS-based identity providers

Browse Source
This commit is contained in:
Václav Navrátil 2024-05-01 20:33:26 +02:00 committed by GitHub
parent 88246c2741
commit 346704d7c8
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
1 changed files with 108 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

108
85.md Normal file
View File

@ -0,0 +1,108 @@
NIP-85
======
Attestation of DNS-based identity providers
--------------------------------------------
`draft` `optional`
NIP-85 extends the well established NIP-05 in the way that clients would be able to verify not only the `<local-part>` but also assess the `<domain>` part based on published attestations from other NIP-05 identity providers. This will allow clients to select trusted identity providers which then will extend to all of their attestees.
#### Example
If a client sees an event like this:
```json
{
"pubkey": "b0635d6a9851d3aed0cd6c495b282167acf761729078d975fc341b22650b07b9",
"kind": 0,
"content": "{\"name\": \"bob\", \"nip05\": \"bob@example.com\"}"
...
}
```
It will make a GET request to `https://example.com/.well-known/nostr.json?name=bob` and get back a response that will look like
```json
{
"names": {
"bob": "b0635d6a9851d3aed0cd6c495b282167acf761729078d975fc341b22650b07b9"
},
"attestators": {
"bob@example.com": [ "https://example1.net", "https://example2.org" ],
"example.com": [ "https://nip-provider1.test", "https://example3.info" ]
}
}
````
or with the **recommended** `"relays"` attribute:
```json
{
"names": {
"bob": "b0635d6a9851d3aed0cd6c495b282167acf761729078d975fc341b22650b07b9"
},
"relays": {
"b0635d6a9851d3aed0cd6c495b282167acf761729078d975fc341b22650b07b9": [
"wss://relay.example.com",
"wss://relay2.example.com"
]
},
"attestators": {
"bob@example.com": [ "https://example1.net", "https://example2.org" ],
"example.com": [ "https://nip-provider1.test", "https://example3.info" ]
}
}
````
If the pubkey matches the one given in `"names"` (as in the example above) that means the association is right and the client can continue to verify attestations from the `"attestators"` attribute contains an object with two optional attributes. One equal to the (`<local-part>` and `<domain>`) `"nip05"` identifier with value consisting of an array of URLs of attestators atesting this individual `"nip05"` identifier. The second attribute is equal to the `<domain>` and the value is an array of URLs attesting the whole `<domain>` of the DNS-based identity provider.
### Attestation verification
Attestation can be conducted on an individual level for a specific `"nip05"` identifier or for a whole domain. The differentiator between individual and domain attestation request is the occurrence of `@` in the value of the `"attest"` URL parameter.
#### Individual attestation verification
Client will make a GET request to `https://example1.net/.well-known/nostr.json?attest=bob@example.com` and get back a response that will look like:
```json
{
"attestations": {
"bob@example.com": "b0635d6a9851d3aed0cd6c495b282167acf761729078d975fc341b22650b07b9"
},
"attestators": {
"example1.net": [ "https://well-known-nip-provider.test", "https://nip-provider2.test" ]
}
}
````
The response contains a JSON document object with one mandatory `"attestations"` and one optional `"attestators"` attribute. In `"attestations"` if the public key for the given `"nip05"` matches the previously received `pubkey`, the client then concludes that the given `"nip05"` is attested by this provider.
The optional `"attestators"` attribute can contain an object with `<domain>` attribute and value as an array of URLs attesting the whole `<domain>` of the DNS-based identity provider allowing recursive domain attestation.
#### Domain attestation verification
Client will make a GET request to `https://nip-provider1.test/.well-known/nostr.json?attest=example.com` and get back a response that will look like:
```json
{
"attestations": {
"example.com": true
},
"attestators": {
"nip-provider1.test": [ "https://another-known-nip-provider.test", "https://nip-provider3.test" ]
}
}
````
The response contains a JSON document object with one mandatory `"attestations"` and one optional `"attestators"` attribute. In `"attestations"` if the attribute matches the requested `<domain>` and the value is `true`, the client then concludes that the whole `<domain>` is attested by this provider.
The optional `"attestators"` attribute can contain an object with `<domain>` attribute and value as an array of URLs attesting the whole `<domain>` of the DNS-based identity provider allowing recursive domain attestation.
### Notes
Clients should track the recursive requests to the attestators domains to prevent infinite loops of recursive attestations.
Client should keep requesting attestation until a link between atteste and the trusted identity provider is established, all attestation options are exhausted or an attestation limit set by the client is reached.
For implementation clients can use different colors and or emojis to display the `"nip05"` validity and attestation status. For example gold check-mark for fully attested, blue check-mark for valid but not attested and red cross for invalid `"nip05"` identities.