NIP-26

Delegated Event Signing

他の秘密鍵に署名を移譲(委任)できる仕組みです

秘密にしておきたい秘密鍵（root秘密鍵）を用意しておく

用意したroot秘密鍵でクライアントごとに発行しておいた公開鍵を署名すると委任できる

委任するイベントの種類と期間を制限できるようになっている

万が一、クライアントの秘密鍵が漏れても影響を小さく留めることができます

root秘密鍵の方はクライアントに登録していないため、影響がありません

委任期間を短くイベントの種類を少なく設定すれば、漏れてもできることは制限される

2023/2/9時点では、対応しているクライアントは少ない？

知ってたらどなたか書いていただけると🙇

技術的な話

イベント署名の移譲(=委任)

他のキーペアでイベントを署名できるように、イベントがどのように移譲されるかを定める

ユーザはクライアントごとに使いたいキーペアを生成でき、ユーザのroot公開鍵の代わりにそのキーペアをイベントを生成するために使うことを認可できる

GnuPGの副鍵(subkey)の仕組みに似ている？

用語

delegator（移譲キーペア、委任側キーペア）

他のキーペアに署名を許可するキーペア

応用例のrootキーペアに相当

delegatee（被移譲キー、受任側キーペア）

署名を許可される側のキーペア

応用例の各クライアントのキーペアに相当

移譲に必要な情報を含めるタグで、次の情報が含まれる:

委任側キーの公開鍵

条件に一致するイベントに限り、被移譲キーペアが署名を行うことを認可する

移譲トークンとは

nostr:delegation:<受任側キーの公開鍵>:<条件クエリ文字列>

受任側キーの公開鍵と条件クエリ文字列に対する署名を作ることで認可を表現する

防げないこと

ただし、委譲に期限を設けてあれば、漏洩しても被害は抑えられる

逆に期限を設定していなければ、永続的な許可を与えていることになるので、受任キーは委任キーと同じ権限を持つことになり、漏洩への防御として役に立たなくなる

運用について

漏洩の影響を防ぐには委任の期限を定期的に更新しなければならない

期間をどうするべきか？

運用方法（推奨される条件）までは書かれていない

例として1ヶ月(30日)の間だけ許可するという署名のサンプルがある

クライアントの信頼性、安全性が十分でないと思うなら短くしたりkindを制限したりすると良いかもしれない

どうやって委譲タグを更新するか？

定期的に委任側キーで委譲しなければいけない

クライアントが定期的に更新を提案する？

kind:100xxなどで公開しておく？

対応の課題

リレー

委任側キーをfilterに含むREQに対して、受任側キーからの投稿も含めて返さなければならない

挿入時に委任タグを検証して、検証が通ったらdelegator列に委任側キーを設定する？

pubkeyのクエリ時はauthorとdelegatorの両方を条件にする

委任タグの検証は一度正規なものだと判断できればキャッシュしても良いので、検証のコストは少なくできる（ただ、都度DBやキャッシュへの問い合わせが生じるので、都度検証するほうが早いかもしれない）

クライアント・ツール

委譲タグを管理しないといけない

受任側キーの生成、委譲タグの生成、委任側キーによる委譲タグに対する署名、委譲タグとトークンをクライアントに保存

これをユーザにわかりやすい形で提示しないといけない

クライアントは委譲タグが含まれていれば検証しないといけない

クライアントは委任側キーをauthorとして表示する必要がある

そこまで対応は難しくないはずではある

対応状況

2024/11時点ではリレーが対応しておらず、実質的に使用できない状況

nostr-rs-relay

デフォルトで無効化されている

nostream

以前は対応していたが、パフォーマンスに課題があり、2024/1/12に削除された