私は『Citadel 2』を読んでいて、一文の手前で立ち止まりました。その文は長くありません――「スマートコントラクトは、session のパスワード学的な有効性の検証だけを担う。あなたを入れるかどうかは、Service Provider が決める。」🤔

ユーザーは大変な苦労をして有効な証明を生成する。けれども物語はまだ終わっていない。いや、むしろ、これから始まる。

あなたは、自分がある License Provider が発行した有効なライセンスを保有していることを証明できる。資料はチェーンに載せる必要がなく、プライバシーも徹底して守られる。だが、サービス提供側にはまだ山ほど自分で判断すべきことがある。私はこの LP を信頼できるのか？どの属性を受け入れるのか？session の有効期限は切れていないか？取り消されていないか？この cookie はもう一度使えるのか？

プライバシーは守られている。でもビジネスポリシーは、あなたの代わりに決めてくれない。

最悪のシナリオはどんなもの？
ユーザーが proof の生成に成功し、ページに表示されるのはこうだ――「アクセス権がありません。」

たった四つの言葉。以上。🥶

ユーザーは推測し始める。証明が無効になったのか？発行者をサービス提供側が信頼していないのか？それとも属性がルールに合っていないのか？あれこれ当てずっぽうに考えても、まったく手がかりがない。

プライバシーは確かに漏れていない。けれど、時間がなぞ解きに消えていく。ユーザーにとっては、プライバシーは守られているのに、体験が崩壊する。

サービス提供側にとっては、すべての拒否が一つのエラーコードの奥に隠れてしまい、コンプライアンス上の境界すら説明できない。

この自制こそが、実は「目が覚めている」ことだ。
Citadel 2 の価値はまさにここにある。これは、あなたが適切な資格情報を持っていることを証明する。しかし「あなたはサービスを受けるべきだ」とは一切ふりをしない。

証明はあなたのもの。決定権はサービス提供側のもの。二つのことははっきり分かれている。

$DUSK のエコシステムは、それを実際の onboarding に活用したいはずだし、@Dusk は、アプリが proof の valid と policy denied をユーザーに別々に伝えるよう後押しすべきだろう。

証明が通っていないのか？証明は通っているのに、ポリシーが拒否しているのか？それを一つのエラーコードにまとめるのは手間が省ける。でも二つに分けるのは、ユーザーの判断力を尊重することだ。

ユーザーはどこで詰まっているのかを知っている。#dusk のプライバシー体験がようやく「完成」すると言える。

そうでなければ、プライバシー保護がどれだけ良くても、ユーザーが覚えているのは結局あの四つの言葉だけだ。🤷‍♂️