Skip to content

Latest commit

 

History

History
110 lines (81 loc) · 5.46 KB

26.md

File metadata and controls

110 lines (81 loc) · 5.46 KB
Raw

NIP-26

イベント署名の委任

draft optional

このNIPは他の鍵ペアを使ってイベントを署名するための委任の方法を定義する。

この提案の活用法として、クライアントと対話するときにルート鍵ペアの使用を回避できることが挙げられる。例えば、ユーザーは使用したいクライアント毎に新しい鍵ペアを作成し、コールドストレージへ保存するルート鍵ペアと代えて新しい鍵ペアにイベントを署名させることができる。

'delegation'タグの紹介

このNIPで導入されるdelegationタグは次のような書式で示される。

[
  "delegation",
  <pubkey of the delegator>,
  <conditions query string>,
  <delegation token: 64-byte Schnorr signature of the sha256 hash of the delegation string>
]
委任トークン

委任トークンは次の文字列のsha256ハッシュへの64バイトのシュノア署名でなければならない。 (訳注: 以下に示される文字列は、委任トークンではない。委任文字列である。)

nostr:delegation:<pubkey of publisher (delegatee)>:<conditions query string>
クエリ文字列の条件句

上記のクエリ文字列には、以下のフィールドと演算子が対応している。

フィールド:

  1. kind
    • 演算子:
      • =${KIND_NUMBER} - 委任された鍵は、指定されたイベントkindのみに署名できる。
  2. created_at
    • 演算子:
      • <${TIMESTAMP} - 委任された鍵は、指定されたタイムスタンプより過去に作成されたイベントにのみ署名できる。
      • >${TIMESTAMP} - 委任された鍵は、指定されたタイムスタンプより未来に作成されたイベントにのみ署名できる。

単一の条件を指定するには、対応しているフィールドと演算子を使用する必要が有る。複数の条件を1つのクエリ文字列で指定する場合、条件句は&で組み合わされる必要が有る。

例えば、次に示される条件句の文字列は有効である。

  • kind=1&created_at<1675721813
  • kind=0&kind=1&created_at>1675721813
  • kind=1&created_at>1674777689&created_at<1675721813

大半のユースケースでは、以下の事が推奨される。

  1. クエリ文字列には、現在の時刻を反映したcreated_atより未来のみの条件を含めるべきである。
  2. クエリ文字列には、空でなく、極端に遠い未来の時刻でないcreated_atより過去のみの条件を含めるべきである。もし、委任が時間的範囲に拘束されない場合、ルート鍵ペアを認証に利用するのと同様のセキュリティリスクが発生する。

例

# 委任する鍵:
privkey: ee35e8bb71131c02c1d7e73231daa48e9953d329a4b701f7133c8f46dd21139c
pubkey:  8e0d3d3eb2881ec137a11debe736a9086715a8c8beeeda615780064d68bc25dd

# 委任される鍵:
privkey: 777e4f60b4aa87937e13acc84f7abcc3c93cc035cb4c1e9f7a9086dd78fffce1
pubkey:  477318cfb5427b9cfc66a9fa376150c1ddbc62115ae27cef72417eb959691396

次に示す委任文字列は、現在のタイムスタンプが1674834236のとき今から30日間、委任される鍵 (477318cf...) へノートの署名権限を付与するものである。

nostr:delegation:477318cfb5427b9cfc66a9fa376150c1ddbc62115ae27cef72417eb959691396:kind=1&created_at>1674834236&created_at<1677426236

次に示す委任トークンは、上記の委任文字列のSHA256ハッシュへの委任する鍵 (8e0d3d3e...) による署名である。

6f44d7fe4f1c09f3954640fb58bd12bae8bb8ff4120853c4693106c82e920e2b898f1f9ba9bd65449a987c39c0423426ab7b53910c0c6abfb41b30bc16e5f524

委任された鍵 (477318cf...) は委任する鍵 (8e0d3d3e...) に代わってイベントを構築できる。委任された鍵は自身の秘密鍵でイベントに署名して公開する。

{
  "id": "e93c6095c3db1c31d15ac771f8fc5fb672f6e52cd25505099f62cd055523224f",
  "pubkey": "477318cfb5427b9cfc66a9fa376150c1ddbc62115ae27cef72417eb959691396",
  "created_at": 1677426298,
  "kind": 1,
  "tags": [
    [
      "delegation",
      "8e0d3d3eb2881ec137a11debe736a9086715a8c8beeeda615780064d68bc25dd",
      "kind=1&created_at>1674834236&created_at<1677426236",
      "6f44d7fe4f1c09f3954640fb58bd12bae8bb8ff4120853c4693106c82e920e2b898f1f9ba9bd65449a987c39c0423426ab7b53910c0c6abfb41b30bc16e5f524"
    ]
  ],
  "content": "Hello, world!",
  "sig": "633db60e2e7082c13a47a6b19d663d45b2a2ebdeaf0b4c35ef83be2738030c54fc7fd56d139652937cdca875ee61b51904a1d0d0588a6acd6168d7be2909d693"
}

委任トークンの署名検証の結果が有効で、条件を満たしている (この例ではkind=1、created_at>1674834236、created_at<1677426236) 場合、委任は有効だと見做される。

クライアントは、委任されたノートをあたかも委任した鍵 (8e0d3d3e...) によって直接発行されたかのように表示する必要が有る。

リレーとクライアントの対応

リレーは["REQ", "", {"authors": ["A"]}]のようなリクエストに対してpubkeyとdelegationタグ[1] の値の両方を問い合わせることで答えるべきである。

リレーは、委任される鍵 (477318cf...) によって公開されたイベントを委任する鍵 (8e0d3d3e...) が削除することを許可するべきである (SHOULD)。