ADXが見た夢（ATPのUCANの話）

ADXが見た夢 ATPのUCANの話 2023.3.17 Bluesky/ATProtocol 勉強会#0

自己紹介 Bluesky発足当時からたまに追ってた Matrixには入ってないのでブログやGitLab/GitHub追う程度 Bluesky Socialエアプ webや暗号は専門外

おことわり規格概要は分かっている想定規格の技術的な話だが、古い仕様の話なので実用的ではない未来に復活する可能性も無くはない疑問・ツッコミ・野次賛辞歓迎資料公開時(or時間余ったら)ピックアップして補足予定

2022.10.18 ATP誕生

ADX? Authenticated Data eXperiment ATPの前身……というか開発段階の名前当時のリポジトリでは色々夢を語っていたが、改名と共に削除 architecture.md 今見てみると方針変更もいくつかある

変わったもの UCANや鍵管理システムの主張が控えめに仕様と実装に残りはしたが活用はされず DIDコンソーシアム→did:plcへ規模縮小 Lexiconによる機能拡張性

UCAN? 公開鍵間の推移的な権限委任を実現する仕様 https://ucan.xyz/ DID用OAuth 両者の公開鍵をJWTにまとめて署名 NostrのNIP-26と大体同じ原理

UCANサンプル（抜粋） { "iss": "did:key:z6Mkr5aefin1DzjG7MBJ3nsFCsnvHKEvTb...", "aud": "did:key:z6MkfQhLHBSFMuR7bQXTQeqe5kYUW51Hpf...", "nbf": 1529496683, "exp": 9256939505,
"att": [ { "with": "wnfs://demouser.fission.name/public/photos/", "can": "wnfs/OVERWRITE" } ], "prf": [ {"iss": "did:key:...", "aud": "did:key:z6Mkr5aef...", ...} ] } 鍵A (iss) 鍵B (aud) 権限委任 wnfs/OVERWRITE 上位委任 (prf)

UCANで何ができる(予定だった)か他ユーザやソフトに権限設定できる(TwitterのOAuth的用法) 主目的はおそらくクライアント認証 WordPressでいう「寄稿者」もLexiconで実現可能かも署名鍵マスターをユーザが持ち、PDSに子鍵を使わせる(妄想) NIP-04の要領でDMの実現が容易に？子鍵発行とかをいい感じに行うために鍵管理システムも予定されていた

ATPの署名のおさらい 1. repositoryのMST rootに対する署名 2. did:plcのログに対する署名一応ATPの外側なので詳細は触れない 3. com.atproto.server.createSessionのJWTに対する署名 PDSの署名鍵を使うのでユーザの鍵は無関係

UCANの使われどころ MST rootにUCANを含める commitへの署名鍵を選べる公式ウェブサイトに定義がある auth_token: 《UCAN token》

普通のrepository更新 1. クライアントがrecord作成 2. com.atproto.repo.createRecord等でPDSに作成要求 record作成不要なLexicon毎のAPIを使う可能性もある 3. PDSがrepositoryを更新してcommit作成

UCANを使ったrepository更新 1. クライアントがrepositoryを更新してcommit作成 repositoryは予めPDSと同期済の想定 2. com.atproto.sync.updateRepoでPDSにpush 複数commitまとめてpushしても良い 3. PDSがcommitを検証してマージ

R.I.P. 2023/01/06 実装に残っていたUCANライブラリ削除 "we weren't actually making use of this"
2023/01/25 実装からcom.atproto.sync.updateRepo削除 "doesn't make sense without client-held keys" 削除理由としては十分だが、明確に使わない方針へ

まとめ ADXはUCANのある未来を夢見ていたが、ATPは別の未来へ進んでいる UCANでも他でもいいけど権限管理機能欲しくない？

余談：OAuth 2023/03/10 OAuth対応を求めるissueが立て続けに作成される #646 IndieAuth推し #649 OAuth WGから#646に触発されて参戦？モチベーションはPDSの認証方式をATPで固定しないこと外部のOAuthサーバで認証する話で、ターゲットが異なる
とはいえそれは本来DID/SSIDが担うべき役割なのでは？ did:plcのsubjectはアカウント(だからユーザ認証不可)？

余談：登録しない理由検索の弱い/無いSNSにあまり価値を感じないため基本的にトピックベースで情報収集したい技術的興味とIndexerやLexiconへの期待からATPを追ってる今登録したアカウントはdid:plcと共に消える可能性があるため少なくとも現状の方針はDIDの変更を許さないせめてDIDドキュメント弄れれば他DIDと紐付けできるが……

追記：気になったコメント「did:plcはコンソーシアムで運営されるとMatrixに書いてた」だとするとADXの図そのままの形になると思って良さそう placeholderのために大袈裟な気も多少するが…… ATPが鍵管理させない話について「Nostrではユーザが鍵管理してる」実際Nostrは要求リテラシー（主に自己責任精神）高いと思う投稿が揮発性なのでガチガチに固めなくてもいいというのもある？ repositoryの仕組みについて「gitっぽい」実際意識してそうしているのは間違いない

追記：ATPに期待すること① 公式アカウント（RSS代替）自前でPDS運営できなくても保証しやすいはず did:webとhandle(DNS name)だとどっちが対応楽なんだろうサイト持ってなくても例えば他DIDからAlsoKnownAsできる DIDがもっと普及してくれないと厳しいか did:plcでは直接DIDドキュメント弄らせる気無さそうなので、逆リンクはあんまり期待できない

追記：ATPに期待すること② フォーラム・議論（BBS代替） Lemmy的な仕組みのLexiconがあればできそうユーザ側がrecord持つのは厳しいので、他アカウントから投稿するためのAPIとかが欲しくなる UCANが有ればユーザのPDS通さなくてもいけそう正直ATPと相性良くはないが、ただただ欲しいどちらかというとDiscourse+APに期待すべきか？

ADXが見た夢（ATPのUCANの話）

ADXが見た夢（ATPのUCANの話）

yamarten

More Decks by yamarten

Other Decks in Technology

Featured

Transcript