Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
ATPの「A」
Search
yamarten
April 28, 2023
Technology
0
260
ATPの「A」
https://428lab.connpass.com/event/280610/
yamarten
April 28, 2023
Tweet
Share
More Decks by yamarten
See All by yamarten
Bluesky 2019〜2022
yamarten
1
200
PDS連合ことはじめ
yamarten
0
770
ADXが見た夢(ATPのUCANの話)
yamarten
0
320
Other Decks in Technology
See All in Technology
【CEDEC2025】現場を理解して実現!ゲーム開発を効率化するWebサービスの開発と、利用促進のための継続的な改善
cygames
PRO
0
410
メモ整理が苦手な者による頑張らないObsidian活用術
optim
0
150
Expertise as a Service via MCP
yodakeisuke
1
160
サイバー攻撃のシミュレーション:攻撃者の視点からみる防御のむずかしさ!AWSで試してみよう / 20250423 Kumiko Hemmi
shift_evolve
PRO
1
110
MCPに潜むセキュリティリスクを考えてみる
milix_m
1
890
AIに全任せしないコーディングとマネジメント思考
kikuchikakeru
0
280
経理出身PdMがAIプロダクト開発を_ハンズオンで学んだ話.pdf
shunsukenarita
1
240
MCPと認可まわりの話 / mcp_and_authorization
convto
2
310
「育てる」サーバーレス 〜チーム開発研修で学んだ、小さく始めて大きく拡張するAWS設計〜
yu_kod
1
190
Ktor + Google Cloud Tasks/PubSub におけるOTel Messaging計装の実践
sansantech
PRO
1
340
「AI駆動開発」のボトルネック『言語化』を効率化するには
taniiicom
1
220
VLMサービスを用いた請求書データ化検証 / SaaSxML_Session_1
sansan_randd
0
130
Featured
See All Featured
Automating Front-end Workflow
addyosmani
1370
200k
Building Flexible Design Systems
yeseniaperezcruz
328
39k
Product Roadmaps are Hard
iamctodd
PRO
54
11k
Designing for humans not robots
tammielis
253
25k
Why You Should Never Use an ORM
jnunemaker
PRO
58
9.5k
Git: the NoSQL Database
bkeepers
PRO
431
65k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
234
17k
Art, The Web, and Tiny UX
lynnandtonic
301
21k
Documentation Writing (for coders)
carmenintech
72
4.9k
Reflections from 52 weeks, 52 projects
jeffersonlam
351
21k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
18
1k
A Modern Web Designer's Workflow
chriscoyier
695
190k
Transcript
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拡張が必要