#dusk $DUSK @Dusk
最初は、暗号学的に有効なCitadel 2のセッションが、どこでも使えるアクセスパスのようなものだと思っていました。オンチェーンで証明が検証されれば、サービスは私を受け入れるはずだと。
@Duskについて詳しく調べるうちに、その設計では証明の有効性とアクセス権限が分けられていることに気づきました。コントラクトは、私が登録済みでプロバイダーの署名があるライセンスを保有していることを検証し、どのライセンスを使ったかを明かさずにセッションを記録できます。その後、セッションCookieを共有すると、サービスはその公開記録と照合します。
ただし、最終的な判断は依然としてサービスに委ねられています。発行者を信頼していない場合、認証情報の有効期限が切れている場合や取り消されている場合、あるいはサービス側のチャレンジやリプレイ防止のルールを満たしていない場合、サービスは私を拒否できます。
このアプローチのこういうところが気に入っています。プライバシーを守るために、制御まで手放す必要はありません。現実世界のポリシーを維持しながら、開示する情報を制限できます。
ユーザーはこのバランスに安心感を覚えるでしょうか。それとも、混乱するでしょうか。
証明の検証後に自動でアクセスできるほうがいいですか?それとも、サービスごとに確認するほうがいいですか?
最初は、暗号学的に有効なCitadel 2のセッションが、どこでも使えるアクセスパスのようなものだと思っていました。オンチェーンで証明が検証されれば、サービスは私を受け入れるはずだと。
@Duskについて詳しく調べるうちに、その設計では証明の有効性とアクセス権限が分けられていることに気づきました。コントラクトは、私が登録済みでプロバイダーの署名があるライセンスを保有していることを検証し、どのライセンスを使ったかを明かさずにセッションを記録できます。その後、セッションCookieを共有すると、サービスはその公開記録と照合します。
ただし、最終的な判断は依然としてサービスに委ねられています。発行者を信頼していない場合、認証情報の有効期限が切れている場合や取り消されている場合、あるいはサービス側のチャレンジやリプレイ防止のルールを満たしていない場合、サービスは私を拒否できます。
このアプローチのこういうところが気に入っています。プライバシーを守るために、制御まで手放す必要はありません。現実世界のポリシーを維持しながら、開示する情報を制限できます。
ユーザーはこのバランスに安心感を覚えるでしょうか。それとも、混乱するでしょうか。
証明の検証後に自動でアクセスできるほうがいいですか?それとも、サービスごとに確認するほうがいいですか?
