#dusk $DUSK

この2日間、また@Dusk の「Citadel 2」を見直してみました。

以前はずっと、それを「ZKの身元（アイデンティティ）ツール」みたいなものだと理解していましたが、今思うとその言い方は少し雑すぎます。

実際には、Citadelはプラットフォームの代わりにそんなに多くの判断をしようとしているわけではありません。

ユーザーはまずLicense Providerのオフライン検証を通過してcredentialを受け取ります。その後、あるサービスにアクセスするとき、自分が有効な資格を持っていることをZKで証明します。

ここまでで、Citadelが証明できるのはその資格が問題ないことだけです。

しかし、プラットフォームがそのLPを認めるのか、そのcredentialは今も使えるのか、取り消されていないのか、sessionは再検証が必要なのか……といったことは、Citadelがあなたの代わりに自動で処理するものではありません。

最初にこのあたりを見たときは、少し疑問に感じて「半分だけやっている」ようにも思いました。

でもあとで考えてみて、金融業務ではそもそも受け入れ（アドミッション）のルールが1つだけで済むはずがないのです。

同じ資格でも、地域や製品、プラットフォームが違えば使えるかどうかは別問題であり、それはまさに別の話です。

だからこそ、今の私はCitadel 2の設計をむしろ「かなり抑制的だ」と感じています。

「この証明が本物かどうか」をまず処理し、それが「十分かどうか」は具体的な業務側に判断を委ねる。

revocation、expiration、session replayといったものも、協定（プロトコル）がすべてあなたの代わりに解決してくれるように包み込んでいるわけではありません。

この点を私はかなり重視しています。

というのも、多くのプロジェクトはZKに触れると、何か問題が起きるたびに「暗号学なら何とかできる」という方向へ寄ってしまいがちだからです。

Citadel 2は、現時点での私の印象としては、そんなにふわふわした感じではありません。

むしろ、資格証明の層をきれいに整えたうえで、あとのルールは、誰が責任を持つべきかはそのまま誰が責任を持つ、というふうに見えます。