Dusk が Citadel でアイデンティティをどう扱っているかについて、かなりの時間をかけて調べてきました。そして時間を置くほど、これは別のデータ投棄ではなく、ユーザーに実際のコントロールを渡そうとする実務的な試みのように感じられます。

あなたは信頼するプロバイダにライセンスを申請します。プロバイダはオフチェーンであなたを検証し、属性に署名し、暗号化したバージョンをオンチェーンに登録します。後でアクセスが必要になったら、有効な登録済みライセンスを所持していることを示す証明を生成します。チェーンには「セッションが発生した」という事実だけが記録されます。ウォレットの中身や、特定のライセンス、個人情報そのものについては何も記録されません。次に、セッションクッキーをサービスに送ります。そして、サービス側の独自ルールに基づいて入室を許可するかが決まります。

この分離が重要です。Citadel は、ポリシーを設定するふりをしていません。サービスは引き続き、受け入れる発行者（issuer）を選び、どの属性が有効とみなされるか、そして何かが失効したかどうかを判断します。ユーザーは毎回、自分の全ファイルを手渡しているわけではありません。機関は自分たちでデータを保存しないため、コストと漏えいリスクを抑えられます。

明らかな限界は、やはりライセンスプロバイダを信頼する必要があることです。もしその数が少なく、あるいは集中しているなら、「セルフソブリン（self-sovereign）」の部分は見た目ほど薄くありません。実際のサービスに統合してもらうことのほうが、暗号技術よりも難しいのです。また、クッキーはベアラ型なので、使い回しやバインディングはサービス側で慎重に扱わないといけません。

十分な当事者が実際に使えば、許可制のマーケット（permissioned markets）のあり方を変えるかもしれません。あるいは、金融分野のニッチから出ない、便利なツールのままで終わるかもしれません。

この仕組みがスケールに影響するために、最初に動かないといけないのは誰だと思いますか――ユーザー、発行者（issuers）、それともサービス提供者自身でしょうか？

#dusk $DUSK @Dusk $BTW $BR
#USStorageStocksExtendLosses #EthereumOpensGlamsterdamEarlyTestnet