「Surface Web」のさらに上層「Trusted Web」では、信頼されるデータの転々流通ができる。あるデータの流通を考えると、その受け渡しには６種類の主体が関与する。
Ａ：大元の出し手
Ｂ：この受け渡しの出し手
Ｃ：この受け渡しの受け手
Ｄ：さらにその先の受け手
Ｅ：受け渡しに関する評価者
Ｆ：評価者を認証するアンカー
これら全体が、主体の認証・内容の認証・属性の認証をする「Authentication」の枠組みの中に入ることになる。具体的には４つの機能が想定されていて、
１）Identifier管理機能
主体Ｂが自分の識別子（ID）を発行して、属性（年齢・連絡先等）を必要な範囲で紐づけることができる機能。現在はサービス毎に識別子と属性が（プラットフォーマーに）決まっているが、これを主体の意思で管理できるというのがミソ。
２）Trustable Communication機能
主体ＢとＣは、Ｅから評価を受けた自らの属性を、必要な範囲で相互に開示する。これによって（最初の取引でも）相手の確からしさを確認できる。
３）Dynamic Consent機能
主体ＢとＣの間で、データのやり取りに関する条件設定と合意をさせ、さらに結果を管理することができる。特殊な条件を付けることも、その合意を得ることもダイナミックに行うことで、安心できる流通を促進する。
４）Trace機能
合意形成のプロセスや、その後条件が履行されているかどうかをモニタリングし、適正であるかどうかを検証できる機能。渡したらあとは分からない（Fire and forget）にならないための仕掛け。
こうして書き連ねるといかにも面倒くさそうだが、機能のほとんどは自動化されているので「慣れればどうということはない」ように思う。主体ＡについてはＢに渡る前のプロセスで、主体ＤについてはＣから渡る際のプロセスで、同様の手順を踏むことになる。その際にも主体Ｅは（別のＥかもしれないが）関与するし、Ｅか信頼できるはＦが評価しお墨付きを与える。Ｆは政府がその役割を担うこともあろう。
このスキームは、マルチステークホルダーによって管理監督される必要があり、スキーム全体の透明性も必要だ。そうスキームをどうやってガバナンスするかが、大きな課題だ。
＜続く＞
