NIP-26
Delegated Event Signing
他の秘密鍵に署名を移譲(委任)できる仕組みです
秘密にしておきたい秘密鍵(root秘密鍵)を用意しておく
用意したroot秘密鍵でクライアントごとに発行しておいた公開鍵を署名すると委任できる
委任するイベントの種類と期間を制限できるようになっている
万が一、クライアントの秘密鍵が漏れても影響を小さく留めることができます
漏洩してしまったときに他人が操作ができてしまうこと自体はNIP-26では防げません root秘密鍵の方はクライアントに登録していないため、影響がありません
委任期間を短くイベントの種類を少なく設定すれば、漏れてもできることは制限される
2023/2/9時点では、対応しているクライアントは少ない?
知ってたらどなたか書いていただけると🙇
iOS Safari向けNIP-07拡張のNostoreが試験対応している(別にクライアント側の対応も必要なため現状動作しない) 技術的な話
イベント署名の移譲(=委任)
他のキーペアでイベントを署名できるように、イベントがどのように移譲されるかを定める
応用すると、クライアントとやりとりするときにrootキーペアを利用しないようにできる
ユーザはクライアントごとに使いたいキーペアを生成でき、ユーザのroot公開鍵の代わりにそのキーペアをイベントを生成するために使うことを認可できる
GnuPGの副鍵(subkey)の仕組みに似ている?
用語
delegator(移譲キーペア、委任キーペア)
他のキーペアに署名を許可するキーペア
応用例のrootキーペアに相当
delegatee(被移譲キー、受任キーペア)
署名を許可される側のキーペア
応用例の各クライアントのキーペアに相当
delegation タグ (移譲タグ)
移譲に必要な情報を含めるタグで、次の情報が含まれる:
移譲キーの公開鍵
条件に一致するイベントに限り、被移譲キーペアが署名を行うことを認可する
運用方法(推奨される条件)までは書かれていない
例として1ヶ月(30日)の間だけ許可するという署名のサンプルがある
クライアントの信頼性、安全性が十分でないと思うなら短くしたりkindを制限したりすると良い?
移譲トークンとは
nostr:delegation:<投稿者の公開鍵(被移譲キー)>:<条件クエリ文字列>
被移譲キーと条件クエリ文字列に対する署名を作ることで認可を表現する
防げないこと
いろいろなクライアントで脆弱性が指摘されている発展途上の段階の現在では、漏洩が考えうる大きなリスクになる これ深掘りして調査したいhideyoshi.icon
kuboon.icon 組織のアカウントA を delegator として、3つのdelegatee を三人の担当者に配れば、見かけ上は全てAの投稿に見え、通信ログを見ればどの担当者かがわかる、みたいな使い方もできそう?
kuboon.icon NIP-07 を使うとクライアントに秘密鍵を渡す必要がないので、実用上の優先度は低くなっている感じはする。