nostr/nips

Fork 0

mirror of https://github.com/nostr-protocol/nips.git synced 2024-09-19 22:35:50 -04:00

ice-orestes faa1135102

fix nip-41 links to PR #1032 instead

2024-09-09 16:23:07 +01:00

12 KiB

Raw Blame History

NIP-0B

On-Behalf of - Simple Sub-Key Management

draft optional

This NIP defines a simple way for an Identity Sub-Key management system, including active, inactive and revoked public keys, for publishing On-Behalf of a master identity.

Motivation

The state of art now has two methods for enabling sub-key management:

NIP-26: Multiple key delegation and no revocation (just time bound)
NIP-41: More complete single key delegation and revocation (complex)

Each of these methods has their own pros and cons, but there's a very common use case that is not covered by any of these methods completely, which is having a master identity that is secure (possibly in cold storage), that can whitelist and blacklist multiple public keys (one for each device or app, for example), that can be used individually (less common but interesting for media management companies) and can publish on-behalf of one or several master identities.

Using NIP-26 for this purpose doesn't allow for blacklisting (revocation), or alternatively requires time bound delegation, with new delegation signing at every expiry. On the other hand NIP-41 is a more complete and complex identity management solution, but only allows for one active sub-key at any point in time, and that sub-key's only purpose is bound to the main identity.

References

This proposal came together with inputs from many other proposals and discussions, but these are the main ones:

NIP-26: Delegated Event Signing
NIP-41: Identity Management
NIP-06: Basic Key Derivation from Mnemonic Seed Phrase
NIP-51: Lists

Why I don’t like NIP-26 as a solution for key management
Thoughts on Nostr key management

Stateless key rotation using a series of hidden commitments
Key distribution, rotation, and recovery
Key rotation verified through root key attestation
Trusted public-key-bundle attestations for key rotation and group definition

Identity types

For clarity in this NIP, we'll use the following identities to describe the actors that are involved in the examples and use cases:

master: the master account, the content owner or author
active: an active sub account, device account, media manager or publisher account
inactive: a sub account that has been inactivated (but not compromised)
revoked: a sub account that has been revoked (it may have been compromised, and all events posted on-behalf of master need to be invalidated)

On-Behalf of Attestations List

This NIP introduces a replaceable event with kind 10100, which is used to keep a NIP-51 list of active, inactive or revoked public keys, for publishing events on-behalf of a master account. The only valid tag in this list is the p tag as defined below.

.content fields is unused and can be ignored if present.

This list is owned by the master account, and can only be updated by an event signed by the master account itself, so never using a b on-behalf tag (see below), neither by NIP-41 p tag in kind 0, nor using a NIP-26 delegation tag.

This list is ever growing, so each update has to include all previous attestations unchanged, and add one or more attestations to the list, otherwise they should be considered invalid and ignored by clients and relays.

Tag `b` (on-Behalf) for events

This NIP introduces a new tag: b, which is indexable by relays, and can be present in active account events, if attested at the on-behalf list above, formatted as follows:

[ "b", <pubkey of the master account> ]

To prevent spam, only one b tag can be present in an event.

If present and valid, the b tag will represent that clients and relays should consider that event as published by the master account specified in the b tag, instead of the one in the event .pubkey field.

If an invalid b tag is present, clients and relays should disregard the event, as if it had an invalid signature.

Tag `p` (with attestation string) for `kind 10100` list

This NIP also introduces a new attestation string for p tag. The p tag can be present multiple times in master account's kind 10100 On-Behalf Of attestations list, formatted as follows:

[
  "p", <pubkey>, <main relay URL>, <attestation string>
]

Field main relay URL can be omitted if not required or needed for accessing the sub account events, and in this case an empty string should be used in the second field of the p tag.

Active Attestation String

The Active Attestation should be a string in the following format:

"active:<timestamp>:<kinds comma separated list, optional>"

Last : is only required if an optional kinds list is present. Without a kinds list, the attestation is valid for all event kinds besides kind 10100.

Inactive and Revoked Attestation String

The Inactive or Revoked Attestations should be a string in the following formats:

"inactive:<timestamp>"

"revoked:<timestamp>"

To purposely limit the creative use cases, so that it doesn't become very demanding to compute the final state of an account, inactive and revoked attestations invalidate all previous active attestations, and subsequent active attestations are considered invalid as well.

This way the master account can decide, depending on the use case and criticality, if it makes sense to keep the published content valid, by adding an inactive attestation, or if it's preferable to invalidate all content published by that account, on its behalf, by adding a revoked attestation.

Subsequent Attestations Resolution

As the attestations are all timestamped, it is convention that a subsequent attestation overrides a prior one, but in the rare event of the same timestamp in attestations for the same public key, the latest in the tags array order should override the previous.

Examples

Considering:

master account:
8e0d3d3eb2881ec137a11debe736a9086715a8c8beeeda615780064d68bc25dd

active account:
477318cfb5427b9cfc66a9fa376150c1ddbc62115ae27cef72417eb959691396

Allow active account to publish kind 1 and kind 7 events on-behalf of the master account:

{
  "id": "567b41fc9060c758c4216fe5f8d3df7c57daad7ae757fa4606f0c39d4dd220ef",
  "kind": "10100",
  "pubkey": "8e0d3d3eb2881ec137a11debe736a9086715a8c8beeeda615780064d68bc25dd",
  "tags": [
      [
          "p",
          "477318cfb5427b9cfc66a9fa376150c1ddbc62115ae27cef72417eb959691396",
          "",
          "active:1674834236:1,7"
      ]
  ],
  "content": "",
  ...
  "sig": "a9a4e2192eede77e6c9d24ddfab95ba3ff7c03fbd07ad011fff245abea431fb4d3787c2d04aad001cb039cb8de91d83ce30e9a94f82ac3c5a2372aa1294a96bd"
}

The active account, while the master account has a valid active attestation at its kind 10100 list, can publish on-behalf of the master account, using the b tag on the event:

{
  "id": "e93c6095c3db1c31d15ac771f8fc5fb672f6e52cd25505099f62cd055523224f",
  "pubkey": "477318cfb5427b9cfc66a9fa376150c1ddbc62115ae27cef72417eb959691396",
  "created_at": 1677426298,
  "kind": 1,
  "tags": [
    [
      "b",
      "8e0d3d3eb2881ec137a11debe736a9086715a8c8beeeda615780064d68bc25dd"
    ]
  ],
  "content": "Hello, world!",
  "sig": "633db60e2e7082c13a47a6b19d663d45b2a2ebdeaf0b4c35ef83be2738030c54fc7fd56d139652937cdca875ee61b51904a1d0d0588a6acd6168d7be2909d693"
}

The event should be considered as published on-behalf of the master account, if at the timestamp 1677426298 the master account had a valid active attestation on its kind 10100 list. If the b tag is not validated by an active attestation, that content is considered invalid and relays and clients can ignore it.

When master account decides to allow on-behalf active for all kinds:

{
  "id": "567b41fc9060c758c4216fe5f8d3df7c57daad7ae757fa4606f0c39d4dd220ef",
  "kind": "10100",
  "pubkey": "8e0d3d3eb2881ec137a11debe736a9086715a8c8beeeda615780064d68bc25dd",
  "tags": [
    ["p",
    "477318cfb5427b9cfc66a9fa376150c1ddbc62115ae27cef72417eb959691396",
    "",
    "active:1674834236:1,7"],
    ["p",
    "477318cfb5427b9cfc66a9fa376150c1ddbc62115ae27cef72417eb959691396",
    "",
    "active:1721934607"]
  ],
  "content": "",
  ...
  "sig": "a9a4e2192eede77e6c9d24ddfab95ba3ff7c03fbd07ad011fff245abea431fb4d3787c2d04aad001cb039cb8de91d83ce30e9a94f82ac3c5a2372aa1294a96bd"
}

Or otherwise, when master account decides to not allow on-behalf for kind 7, but keep kind 1 active:

{
  "id": "567b41fc9060c758c4216fe5f8d3df7c57daad7ae757fa4606f0c39d4dd220ef",
  "kind": "10100",
  "pubkey": "8e0d3d3eb2881ec137a11debe736a9086715a8c8beeeda615780064d68bc25dd",
  "tags": [
    ["p",
    "477318cfb5427b9cfc66a9fa376150c1ddbc62115ae27cef72417eb959691396",
    "",
    "active:1674834236:1,7"],
    ["p",
    "477318cfb5427b9cfc66a9fa376150c1ddbc62115ae27cef72417eb959691396",
    "",
    "active:1721934607:1"]
  ],
  "content": "",
  ...
  "sig": "a9a4e2192eede77e6c9d24ddfab95ba3ff7c03fbd07ad011fff245abea431fb4d3787c2d04aad001cb039cb8de91d83ce30e9a94f82ac3c5a2372aa1294a96bd"
}

In the case that master decides to not permit on-behalf publishing for that active account anymore, but keep the already published events, for instance if the device that was using that active account is being substituted, and that key safely destroyed:

{
  "id": "567b41fc9060c758c4216fe5f8d3df7c57daad7ae757fa4606f0c39d4dd220ef",
  "kind": "10100",
  "pubkey": "8e0d3d3eb2881ec137a11debe736a9086715a8c8beeeda615780064d68bc25dd",
  "tags": [
    ["p",
    "477318cfb5427b9cfc66a9fa376150c1ddbc62115ae27cef72417eb959691396",
    "",
    "active:1674834236:1,7"],
    ["p",
    "477318cfb5427b9cfc66a9fa376150c1ddbc62115ae27cef72417eb959691396",
    "",
    "active:1721934607:1"],
    ["p",
    "477318cfb5427b9cfc66a9fa376150c1ddbc62115ae27cef72417eb959691396",
    "",
    "inactive:1722343578"]
  ],
  "content": "",
  ...
  "sig": "a9a4e2192eede77e6c9d24ddfab95ba3ff7c03fbd07ad011fff245abea431fb4d3787c2d04aad001cb039cb8de91d83ce30e9a94f82ac3c5a2372aa1294a96bd"
}

Or instead, if the active account got compromised, and it is best to consider all content published from that account,on-behalf of master account, to be compromised as well:

{
  "id": "567b41fc9060c758c4216fe5f8d3df7c57daad7ae757fa4606f0c39d4dd220ef",
  "kind": "10100",
  "pubkey": "8e0d3d3eb2881ec137a11debe736a9086715a8c8beeeda615780064d68bc25dd",
  "tags": [
    ["p",
    "477318cfb5427b9cfc66a9fa376150c1ddbc62115ae27cef72417eb959691396",
    "",
    "active:1674834236:1,7"],
    ["p",
    "477318cfb5427b9cfc66a9fa376150c1ddbc62115ae27cef72417eb959691396",
    "",
    "active:1721934607:1"],
    ["p",
    "477318cfb5427b9cfc66a9fa376150c1ddbc62115ae27cef72417eb959691396",
    "",
    "revoked:1722343578"]
  ],
  "content": "",
  ...
  "sig": "a9a4e2192eede77e6c9d24ddfab95ba3ff7c03fbd07ad011fff245abea431fb4d3787c2d04aad001cb039cb8de91d83ce30e9a94f82ac3c5a2372aa1294a96bd"
}

Relay & Client Support

Relays should answer requests such as ["REQ", "", {"authors": ["A"]}] by querying both the pubkey and on-behalf #b tags [1] value.

Relays SHOULD allow the master account to delete the events published by the active, inactive or revoked accounts, whenever the events have the on-behalf b tag present.

12 KiB Raw Blame History Unescape Escape