$DUSK をCitadel2で使うとき、「一度KYCすればどこでも再利用できる」という点がすごく腑に落ちました。少し時間をかけて落ち着いてドキュメントやコードリポジトリを読み込んだら、ここに前提条件が埋め込まれていることに気づきました。

一連の流れを簡単に言うと、ユーザーはLP経由でオフラインの本人確認を行い、暗号化された証明書をオンチェーンに記録します。以後各アプリにアクセスするときは、ZK証明によって自分の適合性を示し、プライバシー情報を公開する必要がありません。

最初は、KYCを1回行って証明書を取得すれば、どこでも使えるのだと思いました。でもCitadelのプロトコルのロジックに沿って突き詰めていくと、重要な細部があることが分かりました。Service Providerは、どのLicense Providerを信頼するかを自分で決められる権利があるのです。

Citadel自体は、すべてのSPが同一の証明書基準を受け入れることを強制していません。例を挙げると、A業務が信頼するLPがあっても、B業務はそれを認めないことがあります。A業務で行ったKYCで取得した証明書が、B業務で受け入れられなければ、また一からやり直しになります。「一度のKYC」の再利用範囲は、自然に「お互いに同じLPのバッチを認め合う小さなコミュニティ」内に限定されます。この輪を外れると、再利用は無効になります。$BTR

本当は、企業向けの接続ドキュメントがどれくらい書き込まれているかを見たかったです。いろいろ確認しましたが、W3sper SDKは確かにありました。一方で、企業レベルの接続ガイドや権限管理の設計といったものは、あまり十分にまとまった版が見当たりませんでした。場所の選び方が悪かった可能性もありますが、少なくとも公開されている情報を見る限り、企業がそのまま直接接続するハードルは確かに高いようです。

EUのeIDASを例に比較すると、現実世界ではすでにアイデンティティ相互承認が進んでいますが、ZKに依存していません。Citadelの技術思想自体は問題ないと思います。ただ、アイデンティティのプロトコルはネットワーク効果が最も重要です。多数のライセンスLPがいて、さらに各種の業務SPがこれらの証明書を受け入れる意思があるからこそ、このシステムは動きます。すでに実際に稼働している外部のライセンスLPの事例があるか探してみましたが、はっきりした公開情報はあまり見つかりませんでした。あるいは今はまだ初期段階で、情報が十分に展開されていないのかもしれません。ただ、少なくとも今見えている範囲では、主に#dusk 自体が推し進めているようで、外部のライセンス提供側の参画の痕跡は目立ちません。

現時点では否定の結論は出しませんが、次の2つの重要なシグナルは継続的に追いかけます。外部のライセンスLPが実際に稼働すること、そしてJS SDKが正式にリリースされること。この2つの変化を確認できるまでは、「終身再利用KYC」にはまだ長い道のりがありそうです。@Dusk 。