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
200
ATPの「A」
https://428lab.connpass.com/event/280610/
yamarten
April 28, 2023
Tweet
Share
More Decks by yamarten
See All by yamarten
PDS連合ことはじめ
yamarten
0
360
ADXが見た夢(ATPのUCANの話)
yamarten
0
210
Other Decks in Technology
See All in Technology
障害対応をちょっとずつよくしていくための 演習の作りかた
heleeen
1
1.7k
Microsoft Intune 勉強会 第 2 回目
tamaiyutaro
2
470
開発パフォーマンスを最大化するための開発体制
ham0215
7
1.2k
リテール金融(キャッシュレス・ネット銀行・ネット証券)の競争環境と経済圏
8maki
0
1.6k
AWSに詳しくない人でも始められるコスト最適化ガイド
yuhta28
2
400
Cloud Service Mesh に触れ合う
phaya72
1
240
【SORACOM UG 東海】あらゆるモノがつながる社会へ、IoT と SORACOM
soracom
PRO
1
150
M5stackで使用できるpHセンサの開発
shinrinakamura
0
210
Cypress or Playwright?
rainerhahnekamp
0
170
.NET Profiler in 2024.
kkamegawa
2
1.8k
Amplify 🩷 Bedrock 〜生成AI入門〜
minorun365
PRO
8
940
R3のコードから見る実践LINQ実装最適化・コンカレントプログラミング実例
neuecc
3
2.8k
Featured
See All Featured
Six Lessons from altMBA
skipperchong
22
3k
Web Components: a chance to create the future
zenorocha
306
41k
The Mythical Team-Month
searls
217
42k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
8
3.4k
Making Projects Easy
brettharned
109
5.5k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
221
21k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
117
18k
Pencils Down: Stop Designing & Start Developing
hursman
117
11k
Product Roadmaps are Hard
iamctodd
45
9.7k
The Cost Of JavaScript in 2023
addyosmani
21
3.9k
Why You Should Never Use an ORM
jnunemaker
PRO
51
8.7k
Learning to Love Humans: Emotional Interface Design
aarron
267
39k
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拡張が必要