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

Bluesky/ATProtocol 勉強会#0

https://www.youtube.com/watch?v=OjP0VkjRsC4&t=3052s

Transcript

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

   View Slide

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

   View Slide

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

   View Slide

4. 2022.10.18 ATP誕生
   

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

8. 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)
   

   View Slide

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

   View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

14. 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"
    
    
    削除理由としては十分だが、明確に使わない方針へ
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide