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

review for typos and style

Browse Source
This commit is contained in:
gzuuus 2024-02-14 09:59:52 +00:00
parent 778fa18d62
commit 63b2318429
1 changed files with 15 additions and 13 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

28
41.md
View File

@ -7,13 +7,13 @@ Identity management
`draft` `optional`
This NIP introduces a robust, best effort and verifiable way for users to manage their identities and standard ways to deal with catastrophe cases. It also describes simple identities and secured identities.
This NIP introduces a reliable and verifiable solution for users to manage their identities, along with standard procedures for dealing with catastrophic cases. It also outlines the differences between simple and secure identities.
# Basic concepts
* **Secured identities**
* These identities are composed of a master keypair and an active subkey.
* The master keypair is used to derive, secure, and back up subkeys, and acts as a trustworthy source of truth for announcements related to subkeys.
* To derive a subkey it is recommended, but not mandatory, to use bip-32 as described in NIP-06 with the derivation path `m/44'/1237'/<account>'/0/0`. This gives us HD addresses and a `xpub` that can be used as proof in a future catastrophe case. Other derivation paths can be used if the user knows what its doing. No derivation scheme needs to be used, users can just generate random keypairs and use them, this gives users less control over subkeys and no proof of derivation.
* These identities are composed of a **master keypair** and an **active subkey**.
* The master key pair is used to derive, secure and back up subkeys, and acts as a trusted source of truth for announcements related to subkeys.
* To derive a subkey it is recommended, but not mandatory, to use bip-32 as described in [NIP-06](https://github.com/nostr-protocol/nips/blob/master/06.md) with the derivation path `m/44'/1237'/<account>'/0/0`. This gives us HD addresses and a `xpub` that can be used as proof in a future catastrophe case. Other derivation paths can be used if the user knows what its doing. No derivation scheme needs to be used, users can just generate random keypairs and use them, this gives users less control over subkeys and no proof of derivation.
* The active subkey should be considered the current account in use for a master keypair, and there should only be one current subkey in use per master keypair.
* Both the master keypair and active subkey should maintain a list of relays in common.
* Users should follow the master keypair to stay up to date with announcements related to the active subkey or revocation certificates. However, it is not mandatory as the described conventions ensure backward compatibility. Subkeys can provide all necessary information to stay uptadate.
@ -22,7 +22,7 @@ This NIP introduces a robust, best effort and verifiable way for users to manage
* **Simple identities**
* They are regular nostr identities that are not backed by a master keypair.
* A simple identity can be transformed in a *Secured identity* by following the conventions described below.
* *Secured identities and simple identities differ from each other because *secured identities* master keypairs have a secure checkpoint created (event `kind:1775`) and a current subkey in use (event `kind:1776`). A subkey represents its role by adding a `p` tag to its kind-0, pointing to the public key of the master keypair.
* *Secured identities* and *simple identities* differ from each other because *secured identities* master keypairs have a secure checkpoint created (event `kind:1775`) and a current subkey in use (event `kind:1776`). A subkey represents its role by adding a `p` tag to its kind-0, pointing to the public key of the master keypair.
* *Simple identities* and master keypairs don't contain a `p` tag in their kind-0 to indicate that they don't belong to or are associated with other accounts.
* *Simple Identities* doesn't have a published secure checkpoint event.
* **`kind:1775` Secure checkpoint**
@ -40,12 +40,12 @@ This NIP introduces a robust, best effort and verifiable way for users to manage
* Revocation certificates or key migration are events that contain proofs that should be used to validate how trustworthy a new purpose identity is.
* When a *Simple Identity* publishes this event, a 60-day period begins during which a user may publish a competing migration event pointing to an earlier `kind:1776` event. After this period, clients SHOULD automatically update the user's follower list to the new pubkey.
* When the master key pair of a *secured identity* publishes a revocation certificate, clients can check to validate the following proofs.
* **Checkpoint Proof:** The client checks if a provided preimage and a secure checkpoint hash match.
* **Derivation tree proof(optional):** The client checks if the historical identities used in past `kind:1776` events belong to a given `xpub`.
* **Social proof(optional):** the event contains a list of people that the master keypair attaches to the revocation certificate as `p` tags. These pubkeys are designated as trusted identities that can judge/signal if the new proposed identity is trustworthy or not.
* If no social proof is required, clients can simply check the proofs provided, and if they are valid, they SHOULD automatically update the user's follower list to the new pubkey.
* If social proof is required, a 30-day period begins during which designated users can signal whether the new identity announced in the revocation certificate is trustworthy by reacting to the revocation certificate event with a `kind:7` reaction event.
* After this period, clients SHOULD automatically update the user's follower list to the new pubkey if there is sufficient evidence to validate the trustworthiness of the new identity.
* Checkpoint Proof: The client checks if a provided preimage and a secure checkpoint hash match.
* Derivation tree proof(optional): The client checks if the historical identities used in past `kind:1776` events belong to a given `xpub`.
* Social proof(optional): the event contains a list of people that the master keypair attaches to the revocation certificate as `p` tags. These pubkeys are designated as trusted identities that can judge/signal if the new proposed identity is trustworthy or not.
* If no social proof is required, clients can simply check the proofs provided, and if they are valid, they SHOULD automatically update the user's follower list to the new pubkey.
* If social proof is required, a 30-day period begins during which designated users can signal whether the new identity announced in the revocation certificate is trustworthy by reacting to the revocation certificate event with a `kind:7` reaction event.
* After this period, clients SHOULD automatically update the user's follower list to the new pubkey if there is sufficient evidence to validate the trustworthiness of the new identity.
* `kind:1775` and `kind:1777` MUST always be open timestamped. `kind:1776` SHOULD only be timestamped if it is published by a *simple identity*.
* Relays SHOULD NOT delete `kind:1040`, `kind:1775`, `kind:1776`, nor `kind:1777` events from their database upon receiving a `kind:5` event.
@ -76,7 +76,9 @@ Every *secured identity* starts as a *simple identity*. Then, if a *simple ident
```
- `pubkey` is the pubkey of the master keypair is creating the checkpoint.
- `kind` MUST be `1775`
- `content` is a hashed secret.
- `content` MUST be the hashed secret.
- `proof` tag MUST list the kind:1040 event that provides the Opentimestamp data.
- Subkey announce `kind:1776`:
- This event defines the subkey that will be in use.
- Subkey announce event example
@ -164,7 +166,7 @@ Multiple `kind:1776` events can exist. All `kind:1776` MUST be opentimestamped f
Relays SHOULD NOT delete `kind:1040` nor `kind:1776` events upon receiving a `kind:5` event.
## Migrating to a pubkey
### Secured identity
If the user needs to rotate to a new subkey, they simply follow the conventions described in `Rotating/whitelisting a pubkey` above. This is considered a minor catastrophe case
If the user needs to rotate to a new subkey, they simply follow the conventions described in `Rotating/whitelisting a pubkey` above. This is considered a **minor catastrophe case**
By having a master keypair as the source of truth, users don't need to timestamp events, and clients can perform the switch to the new subkey as soon as they validate the `kind:1776` events published by the master keypair and the active subkey.