ATPの「A」 ATPの署名の話 2023.4.28 Bluesky/ATProtocol 勉強会#1 

おことわり この発表の主題は考察、というか「これ何だろうね？」 解説や紹介ではないし結論も主張も無い 現状の公式実装準拠のため、ドキュメントと矛盾する場合あり なお発表者はTypeScriptをHello World前に断念、つまり…… 

ATP? Authenticated: 認証された Transfer: データを送受信する Protocol: 決まりごと ちなみに: HTTP = HyperText Transfer Protocol 

Authenticated? 署名による保証を意味する（と思う） repositoryをMST（≒ハッシュ木）で 一つのハッシュにまとめて署名 コピーの改竄を検出可能 更新したら前回のCIDも含めて署名 署名はPDSが持つ秘密鍵を使う 公式PDS実装の鍵は全ユーザ同じ 

何に役立つ？（憶測） ネットワークや取得側PDSに よる改竄の検出 元PDSに問い合わせ不要 BGSの検証を可能にする？ 投稿側PDSの削除・改竄に対 する第三者による証明 ウェブ魚拓的に使える copy commit ＠ ＠ 

署名はどう検証する？ 検証されない署名に意味は無い 公式ライブラリのverifyFullHistoryを使えば検証できる com.atproto.sync.getRepoで取得したrepositoryに使えば検 証できるはず 完……とはならない 

何を検証する？ ちゃんと検証するなら過去commit含め repository全体があった方が良い 公式実装的にはcom.sync.getRecordで 得られる範囲で十分と考えられそう commitから対象recordへのパス以外 のCIDは展開しない それでも1record検証するためだけ にはちょっと重いかも 

誰が検証する？ 取得側のPDSで署名を検証するなら、 当然そのPDSは嘘を吐ける PDSは（ある程度）信頼する前提で はあるが…… とはいえクライアントで検証するの も（特にrepostとか）コスト重め 無差別に検証する訳ではなければ そんなに困らないかも ＠ ＠ record repo data? repo? 

その公開鍵は本物？ クライアントで検証する場合、直接DIDを 解決して公開鍵を取得する必要がある ATPで使うDIDなら誰でも解決できるはず 投稿者PDSに直接もらうのもあり DIDを管理しているPLCサーバがPDSと共謀 して嘘を吐いているかもしれない did:webの場合はユーザのコントロール 下にあるはずなので無条件に信じていい ＠ ＠ record repo repo DID pubkey PLC server PLC server 

DID⇔鍵はどう検証する？ DID操作もcommitのように署名している PLCサーバがoperation logとして保管 did:oydやanywiseなdid:keriに似たコンセプト 最初のoperationからDIDが導出できる 公式ライブラリのvalidateOperationLogで検証可能 operation logの取得方法は未確認 

その他の問題 投稿側のPDSの暴走は防げない 署名鍵を持つため、ローテーションしか止めれらない 引越しても、どのcommitからが暴走か問題は残る PDS引越し前のスナップショットは検証できるか 現状の実装案では全commitが作り直される did:webの場合、過去の署名鍵とDIDの紐付けはどこでする？ 

まとめ repositoryの署名は一部検証や存在証明に使える が、本当にこれがやりたかったことか……？ 他の使い途のアイディアあれば教えてください 公式にはアカウント可搬性のためっぽいが謎 ちゃんと検証するのは結構障害が多い ただし公式でも用意はしてくれているのでマシ 色々考慮は必要だし現時点で実用は厳しいかも 

おまけ：署名が取得できるAPI com.atproto.syncの一部が該当 getCheckout: 指定したcommit+MST getRepo: 指定した範囲のcommit+MST getRecord: 指定したrecordまでのcommitからのpath getCommitPath: 指定した範囲のcommit（MSTを含まない） subscribeAllRepos: 実行中の全変更（commit+MST+handle） handleの変更はrepository外（DID）の管轄だが見える 

おまけ：さらにその先 DIDとrepositoryの繋がりが検証できたとして、それは本当に 「ATP外で知ってるあの人」のものなのか？ did:webや一部のhandle・PDSはサーバ管理者を保証する じゃあ例えば古い名刺記載のhandleがもう他人である可能性 は？名刺の記載自体が嘘かも？ 最終的にシステム外の検証はシステム外でするしかない DIDが解決しうるが、活かすには普及＆did:plc拡張が必要