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
180
PDS連合ことはじめ
yamarten
0
710
ADXが見た夢(ATPのUCANの話)
yamarten
0
300
Other Decks in Technology
See All in Technology
SDカードフォレンジック
su3158
1
630
OpenLane-V2ベンチマークと代表的な手法
kzykmyzw
0
110
ElixirがHW化され、最新CPU/GPU/NWを過去のものとする数万倍、高速+超省電力化されたWeb/動画配信/AIが動く日
piacerex
0
150
Devinで模索する AIファースト開発〜ゼロベースから始めるDevOpsの進化〜
potix2
PRO
8
3.5k
Automatically generating types by running tests
sinsoku
2
3.4k
【Λ(らむだ)】最近のアプデ情報 / RPALT20250422
lambda
0
110
Mastraに入門してみた ~AWS CDKを添えて~
tsukuboshi
0
270
ソフトウェア開発現代史: "LeanとDevOpsの科学"の「科学」とは何か? - DORA Report 10年の変遷を追って - #DevOpsDaysTokyo
takabow
0
390
4/17/25 - CIJUG - Java Meets AI: Build LLM-Powered Apps with LangChain4j (part 2)
edeandrea
PRO
0
120
Cursor AgentによるパーソナルAIアシスタント育成入門―業務のプロンプト化・MCPの活用
os1ma
14
4.9k
Cross Data Platforms Meetup LT 20250422
tarotaro0129
1
700
白金鉱業Meetup_Vol.18_AIエージェント時代のUI/UX設計
brainpadpr
1
170
Featured
See All Featured
Producing Creativity
orderedlist
PRO
344
40k
Typedesign – Prime Four
hannesfritz
41
2.6k
Rebuilding a faster, lazier Slack
samanthasiow
80
8.9k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
32
2.2k
The Pragmatic Product Professional
lauravandoore
33
6.5k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
41
2.2k
Designing Experiences People Love
moore
141
24k
The MySQL Ecosystem @ GitHub 2015
samlambert
251
12k
RailsConf 2023
tenderlove
30
1.1k
Testing 201, or: Great Expectations
jmmastey
42
7.5k
VelocityConf: Rendering Performance Case Studies
addyosmani
328
24k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
331
21k
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拡張が必要