mirror of
https://github.com/nostr-protocol/nips.git
synced 2024-12-23 00:45:53 -05:00
NIP-85: Attestation of DNS-based identity providers
This commit is contained in:
parent
88246c2741
commit
346704d7c8
108
85.md
Normal file
108
85.md
Normal 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.
|
Loading…
Reference in New Issue
Block a user