🐦

DID Placeholder (did:plc)レビュー

2023/03/06に公開

did

tech

SNS BlueSkyの基盤となるATProtocolのために作られたdidメソッドのplcを調べました。

概要

Placeholderの名前のとおり、一時的なもので他にもっと良いものがあれば置き換えたいと説明してる。
DID Placeholder is a cryptographic, strongly-consistent, and recoverable DID method.
- did:plcの特徴かつ、新しいメソッドを作った理由。
- 1.強い一貫性、2.高可用性、3.回復性、4.暗号学で守られた安価で速い更新
- 特にパフォーマンスを強く上げていて、did:ionを不採用にした理由だった。
- 一方で一部DIDスペックに沿っていないため将来拡張されるかもと但し書きされている。

ATProtocolのDID構成

did:plcとdid:keyの合わせ技である
- did:plcがメイン。アカウントや投稿などのSNSデータを記録する。
- did:keyが「簡易」公開鍵基盤。署名鍵と回復鍵の公開鍵を提供する。
  - 署名鍵が通常のDIDドキュメントの作成/更新に使われる。
  - 回復鍵は鍵盗難/紛失などのときのアカウント回復を行うために使われる。
  - did:keyの詳細は参考資料を参照。公開鍵をdidに載せたエイリアスのようなものでdid:key:[公開鍵]となる。
データの持ち方はPostgreSQLとIPFSの二段構え
- IPFSでDID Documentを保持している
- PostgreSQLで履歴管理している→Operation Log
  - IPFSの世代別管理や鍵変更履歴などを司っている。これが無いとBlueSkyは動かない
  - didの新規作成や論理削除
  - DID Documentの作成/更新や改版履歴
  - 鍵のローテーション
DIDのみでVCはない（今のところ）

詳細

以下、参考資料で上げたdid:plcの実装（PLCサーバ）を中心に見ていく。「クライアント」とはあくまでPLCサーバから見たときの関係であることに注意。

DIDの名前空間

did:plc:${base32Encode(sha256(createOp)).slice(0,24)}

まずクライアントでdid:keyを作成する。（注:参考資料で上げたdid:plcの実装では該当箇所が無いため詳細不明）
それらの情報を記載したcreateログを作る。
そのログをハッシュ処理したものがdid:plcの識別子になる。

OperationLog

type Operation = {
  type: string // operation type
  prev: CID | null // pointer to the CID of the previous operation in the log
  sig: string // base64url encoded signature of the operation
  ... // other operation-specific data
}

クライアントから送られるデータはこれになる。
typeは現在5個。各々は、ドキュメント作成、鍵管理、Service（URI）変更の3分類にまとめられる。
ユーザーの秘密鍵による署名が添付され検証される。
prevでIPFSドキュメントの前回のCID (Content IDentifier)がポインタされ改版履歴となる。
投稿などのSNSデータがさらに続く。

鍵ローテション

鍵の盗難/紛失などのときのアカウント回復で実行される処理で回復鍵により行う。
- 72時間の有効期限がある
- OperationLogのtypeのrotate_signing_key,rotate_recovery_keyで新しい鍵を登録する。
- did:plcが提供するのは鍵ローテーションの仕組みまで。リカバリー方法の実装はクライアント責務。署名鍵と一緒に自己管理する、管理者が保管しメールなど他のクレデンシャルで本人証明するなど。
- 現在のBlueSkyの実装では署名鍵・回復鍵ともサーバサイドのどこかで預かっているカストディアン型の様子。
鍵の変更履歴をOperationLogで管理している
- 新規作成や更新を無効鍵でできないようにする→最新の鍵による署名のみOKにする
- 過去のログ参照は鍵履歴のどれかが該当すれば検証OKとなる

DID document

{
  '@context': [
    'https://www.w3.org/ns/did/v1',
    'https://w3id.org/security/suites/ecdsa-2019/v1'
  ],
  id: 'did:plc:7iza6de2dwap2sbkpav7c6c6',
  alsoKnownAs: [ 'https://ali.example2.com' ],
  verificationMethod: [
    {
      id: 'did:plc:7iza6de2dwap2sbkpav7c6c6#signingKey',
      type: 'EcdsaSecp256r1VerificationKey2019',
      controller: 'did:plc:7iza6de2dwap2sbkpav7c6c6',
      publicKeyMultibase: 'zSSa7w8s5aApu6td45gWTAAFkqCnaWY6ZsJ8DpyzDdYmVy4fARKqbn5F1UYBUMeVvYTBsoSoLvZnPdjd3pVHbmAHP'
    },
    {
      id: 'did:plc:7iza6de2dwap2sbkpav7c6c6#recoveryKey',
      type: 'EcdsaSecp256r1VerificationKey2019',
      controller: 'did:plc:7iza6de2dwap2sbkpav7c6c6',
      publicKeyMultibase: 'zRV2EDDvop2r2aKWTcCtei3NvuNEnR5ucTVd9U4CSCnJEiha2QFyTjdxoFZ6629iHxhmTModThGQzX1495ZS6iD4V'
    }
  ],
  assertionMethod: [ 'did:plc:7iza6de2dwap2sbkpav7c6c6#signingKey' ],
  capabilityInvocation: [ 'did:plc:7iza6de2dwap2sbkpav7c6c6#signingKey' ],
  capabilityDelegation: [ 'did:plc:7iza6de2dwap2sbkpav7c6c6#signingKey' ],
  service: [
    {
      id: 'did:plc:7iza6de2dwap2sbkpav7c6c6#atpPds',
      type: 'AtpPersonalDataServer',
      serviceEndpoint: 'https://example2.com'
    }
  ]
}

アカウント作成直後のドキュメント例
サーバでOperationLogから作成されるためシンプルな構成
verificationMethodにdid:key形式（MULTIBASE/MULTICODEC）でエンコーディングした2つの公開鍵を添付している
assertionMethod/capabilityInvocation/capabilityDelegationで署名鍵を指定している（鍵の責務）
引っ越し想定してalsoKnownAs/serviceを変更するためのOperationLogのtypeを用意している

データの秘匿化

現時点でprivateDMは未実装である。
ただ、二者間の暗号化/複合化ならdid:keyで簡単にできそう。
グループはもう一段仕掛けを積まないと難しそう（3人以上で復号鍵を共有する手段が無い）。
全体的にOperationLogに振っているため、DID documentを使われなければ、対話的な選択開示などもできそうだがDID documentの存在意義は無くなりそう。

その他補足

OperationLogでSNSプロダクトはできる。署名検証もエンドポイント解決もOperationLogが主である。実際did:plcをホストしているPLCサーバの実装ではGET /:did/dataはIPFSにアクセスせずにレスポンスを作成している。そうなると確かに性能はPostgreSQLの構成やチューニング次第になる。
DIDは、他に個人リポジトリでミラーを作ってdid:webでホストすることができる。ATProtocolでdid:plcとdid:webの双方のリゾルバーを用意している。
とはいえ現状ではIPFSのDID documentはあまり意味がなく、エコシステムでの活用など将来的な布石のようにも見える。
BlueSkyは昨年秋に"federation"に舵を切ったが、やはりPLCサーバの権限/責務が大きく（鍵もカストディアンの様子）、サーバ運用コストのマネタイズモデルも不明である。ジャック・ドーシー氏はTwitterの反省点として企業の関与を無くしたインターネットネイティブのオープンプロトコルにすると打ち出していて今後どういう形でサービスを育てていくのか興味が増す。

参考資料

did:plcの概要　https://atproto.com/specs/did-plc
did:plcの実装（PLCサーバ）　https://github.com/bluesky-social/did-method-plc
did-coreのスペック　https://www.w3.org/TR/did-core/
did-keyのスペック　https://w3c-ccg.github.io/did-method-key/

概要

ATProtocolのDID構成

詳細

DIDの名前空間

OperationLog

鍵ローテション

DID document

データの秘匿化

その他補足

参考資料

Discussion