PLCサーバーはDID毎に全てのoperationを保持しており、外部に提供する。これは単に履歴が追えるとか帳簿をつけているとかいうだけの話ではなく、もっと厳密な検証ができる。
operationはrotation keyの持ち主(通常はPDS)が発行するもので、主に直前のoperationのハッシュとPLCサーバーに対する操作、およびそれに対するrotation keyによる署名が含まれている。rotation keyの公開鍵の登録や変更もoperationによって行うため、operation logを辿っていけば各署名の検証に使うべき鍵も分かる。各operationの署名を検証することでoperationの正当性を、ハッシュを検証することでoperationの連続性を確認できる。
ついでに言えば、鍵漏洩などによる不正なoperationに対してはそれ以前のoperationから枝分かれすることでrecoveryするため、operation logが一繋がりであることを確認することは、枝分かれした一方は反映されていないことの確認にもなる。
これにより、PLCサーバーは途中のoperationの欠落や捏造を行えないため、これらのoperationを再現すればDIDドキュメントが本当にユーザーの操作によるものであることが検証できる。
operation logは一見これだけで不正を防げる仕組みに見えるかもしれないが、実際には十分ではない。
did:plcではDIDはcreate operationのハッシュから作られる。これは人間にとって可読性がとても低い(そのためにハンドルを別に作る必要があったと思っている)が、これはDID乗っ取りを防ぐために必要な仕様と思われる。簡単に言えば、DIDそのものに鍵由来の情報を含めないと、PLCサーバーはそのDIDのoperation logを捏造できてしまう。
例えば、cretation operationで任意の文字列をDIDとして指定できる仕様を考える。DIDが重複してもPLCサーバーが確実に検出して作成を止められるので、仕様としては成立するはず。しかしこの場合、ooperation logの署名を検証するための公開鍵もoperation logが示すものを使っているだけなので、署名の検証に成功したところで、operation log自体は信用できない。自分で適当な署名鍵(rotation key)で標的DIDに対するcreate operationを作ってしまえば、任意のDIDドキュメントをDIDに紐付けることができてしまう。
一方で今の仕様の場合、別の署名鍵を使うためにcreate operationを書き換えれば当然そのハッシュ値も変わり別のDIDになってしまうため、標的DIDのoperation logを捏造するにはハッシュ衝突を狙うしかない。そのため、PLCサーバーは仮に悪意を持っていても、DIDドキュメントの改竄捏造はできず、精々DID削除やDIDドキュメント更新拒否程度しかできない。
did:plcの検証は監査機関的なものを置くことを想定していそうなので一般ユーザーには関係無いとはいえ、検証コストは若干気になるところ。原理上create(もしくは以前に検証済みのoperation)から最新のoperationまで一つずつ検証していく必要があるため、DIDドキュメントが更新される度にコストは上がっていく。atproto的に言えばこれは主にPDS引越しやhandle変更時に生じるので、鍵変更を含めても大した頻度にはならないという想定なのかもしれない。
中央集権的であるとかはあまり気にならないというか、そういうの気にするならatprotoあまり向いていなさそうだが、DIDがランダムなハッシュ値なのはちょっと嫌。将来良い感じのDIDメソッドに対応した時に乗り換えたいと思っているので、今のアカウントはいつか捨てるつもりで使っている。