#dusk @Dusk
昨日、私はブロックチェーンのアイデンティティ・システムには、主に「誰かが何かにアクセスする資格があること」を証明する必要があるのだと考えていました。私はその観点でアイデンティティを見ていたので、クレデンシャルをオンチェーンに載せるという考えにも比較的簡単に納得してしまっていました。
しかし Citadel 2 を深掘りしていくと、クレデンシャルを証明する際に「何が開示されるのか」の問題があることが見えてきました。Citadel 2 は、有効なライセンスを保有していることを検証するだけでなく、そのライセンスと、その土台となる属性を非公開に保つことも目的として構築されています。この点が、「何かを証明すること」と「その証明の背後にある情報を明らかにすること」は、実はまったく別のことだと気づかせてくれました。
考えるべきなのは、Citadel 2 がこのプロセスをゼロ知識証明と、LP署名されたライセンス、さらにオンチェーンでのセッション検証と組み合わせて実行したいということです。私はかつて、ブロックチェーンがアイデンティティ主張を公開に検証できるなら、それで十分なはずだと思っていました。しかし実際のサービスでは、個人の属性や、使ったクレデンシャルそのものをオンチェーンに載せることが、必ずしも最も現実的な選択とは限りません。サービス側は、ユーザーが有効であることを知る必要がある一方で、ユーザーは自分についてすべてを開示したくない場合があります。
そこから私は、Citadel 2 を「典型的なオンチェーン・アイデンティティ」システムのようには見なくなりました。本当の野心は、クレデンシャル自体を露出せずに、ユーザーが有効なクレデンシャルを持っていることを証明し、そのうえで最終的なアクセス判断はサービス提供者に委ねたままにすることにあるように思えます。
このプライバシーのモデルが、現実のサービスで大規模に採用できるほどシンプルかどうかについては、私はまだ分かりません。もしかすると、次に注目すべき点はそこかもしれません。
$DUSK
$BTC
$TRUMP
オンチェーン・アイデンティティで最も重要なのは何でしょうか?
昨日、私はブロックチェーンのアイデンティティ・システムには、主に「誰かが何かにアクセスする資格があること」を証明する必要があるのだと考えていました。私はその観点でアイデンティティを見ていたので、クレデンシャルをオンチェーンに載せるという考えにも比較的簡単に納得してしまっていました。
しかし Citadel 2 を深掘りしていくと、クレデンシャルを証明する際に「何が開示されるのか」の問題があることが見えてきました。Citadel 2 は、有効なライセンスを保有していることを検証するだけでなく、そのライセンスと、その土台となる属性を非公開に保つことも目的として構築されています。この点が、「何かを証明すること」と「その証明の背後にある情報を明らかにすること」は、実はまったく別のことだと気づかせてくれました。
考えるべきなのは、Citadel 2 がこのプロセスをゼロ知識証明と、LP署名されたライセンス、さらにオンチェーンでのセッション検証と組み合わせて実行したいということです。私はかつて、ブロックチェーンがアイデンティティ主張を公開に検証できるなら、それで十分なはずだと思っていました。しかし実際のサービスでは、個人の属性や、使ったクレデンシャルそのものをオンチェーンに載せることが、必ずしも最も現実的な選択とは限りません。サービス側は、ユーザーが有効であることを知る必要がある一方で、ユーザーは自分についてすべてを開示したくない場合があります。
そこから私は、Citadel 2 を「典型的なオンチェーン・アイデンティティ」システムのようには見なくなりました。本当の野心は、クレデンシャル自体を露出せずに、ユーザーが有効なクレデンシャルを持っていることを証明し、そのうえで最終的なアクセス判断はサービス提供者に委ねたままにすることにあるように思えます。
このプライバシーのモデルが、現実のサービスで大規模に採用できるほどシンプルかどうかについては、私はまだ分かりません。もしかすると、次に注目すべき点はそこかもしれません。
$DUSK
$BTC
$TRUMP
オンチェーン・アイデンティティで最も重要なのは何でしょうか?
Private proof
21%
Transparency
29%
User control
14%
Both
36%
14 投票 • 投票は終了しました