Trust Webアーキテクチャーの構成要素
Trustを実現するには、データのやり取りをする相手を確認する必要があり、デジタル上で個人・法人等の属性が検証されることが必要となるが、属性を紐づけるための識別子を発行し、管理する機能として①のIdentifier管理機能が必要となる。
-
ここでいう識別子とは、固定的な識別子ではなく、自らが必要に応じて複数発行することができ、各識別子に対して、必要な属性情報を紐づけることができる。多数発行する識別子を使い分けることにより、プライバシー上、個人が特定されるリスクを回避することができる。
-
次に、上記のとおり、個人・法人等の「出し手」が識別子を発行し、それに対して「発行者」を含む第三者によって「お墨付き」等を与えられた属性(データ)が結び付けられて管理されることによって、必要に応じてそうした属性(データ)をコントロールしながら開示することが可能となる。発行者を含む第三者からの信頼の構築に資する属性(データ)の管理・開示の仕組みとして、②のTrustable Communication機能が必要となる。
この機能は、これまでW3C(World Wide Web Consortium)で議論されてきているVerifiable Credentials(VC)やその他の手段の応用が可能と考えられる。これらが想定している発行者による個人の資格の証明確認等のレベルのみならず、データの「出し手」に対する第三者のレビュー結果等も含み得ることとしている。
-
その場合にはレビューを行った当該第三者に関する属性を更に検証することにより、そのTrust自体を「受け手」が評価することを可能とするものである。これにより、送られるメッセージの内容の正しさを証明することは難しいとしても、メッセージの「出し手」に対するレビュー結果等で判断することにより、メッセージの内容の正しさを推定し得るものである。
-
受け手が相手の属性を検証する立場にある場合には、受け手は Verifiable Credentials の場合に照らすと、確認する者(verifier)でもあり、Sender と Receiverの関係に分解できる。
-
Trustable Communication 機能においては、それ以上確認する必要がないとされるトラストアンカーに加え、信頼できる発行者やレビューを行う第三者のリスト又は発行者等自体の信頼性を評価する更なる評価の仕組み等も必要となると考えられる。
-
「出し手」と「受け手」との間でデータのやり取りをする際に、双方で様々な条件設定をして合意を行うプロセスと結果を管理する機能が③Dynamic Consent機能である。
デジタルにおいては、本来、相手に応じて柔軟にカスタマイズした合意形成が可能であるにもかかわらず、現状のサービスでは、一律の内容の規約を承認するか否かの選択肢しかないことがほとんどであるが、その合意形成を動的に行う機能を目指すものである。
すなわち、デジタル社会における社会的活動の中で、当事者間の合意形成の際の意思を可能な限り同期させ、仮に齟齬があった場合には動的に修正できることを可能にするものである。
-
合意形成のプロセスや合意の履行をモニタリングし、適正であるか検証するための機能が、④Trace機能である。
これは、合意形成後も検証して相互の意思を同期させる意味合いに加え、特にデータ移転後も「受け手」や第三者に移転した場合にあっても合意条件に則した利用が行われているか監視し、必要に応じて措置を採ることができることにより、データを「受け手」に渡して以降は完全なブラックボックスになるという懸念を払拭する機能である。
Trusted Web ホワイトペーパーver1.0 概要③
Trust WebのTrustモデル
概要図③の「Trustモデル」図を拡大したのが下図。
① Identifier 管理機能
-
識別子を特定のサービスに依拠せず、各主体が発行でき、それを様々な属性(データ)と紐づけることができる。
-
分散型のIdentifierを想定しており、多数のIdentifierをその都度発行することでプライバシー等の特定リスクを下げることが可能となる。
-
本人の選択により、当該識別子と本人確認等のためのトラストアンカーを紐づければ、本人認証も可能となる。
② Trustable Communication 機能
-
識別子とそれに紐づく属性(データ)の組合せを各主体が管理していて、属性(データ)の発行者に都度直接照会することなく、相互に相手の属性(データ)を検証することが可能な仕組み。
-
識別子と紐づいた属性(データ)を管理し、開示の範囲や利用期間等を選択して開示できる。
-
出し手や属性(データ)の発行者等に対し、トラストアンカーによる属性、第三者によるレビュー結果、ポジティブリスト/ネガティブリスト等の属性が書き込まれ、それを受け手が参照することによって、出し手から送信される属性(データ)のTrustの度合いを確認することができる。
③ Dynamic Consent 機能
- 合意形成の際に、やりとりする属性(データ)の取扱いについてのきめ細かな条件設定が可能。双方の条件設定が一致すると合意が成立する。条件設定の項目は属性確認の範囲、選択的開示、保存方法、利用期間、利用目的・方法など
-
各主体の監督の下、意思決定を代理して執行するエージェントを利用することができる(ヒト等の主体あるいはプログラムを含む)
-
その際、相手の属性等の条件を設定して絞り込むこと(フィルタリング)ができ、悪質な相手およびその属性(データ)をブロックできる。
④ Trace 機能
-
合意の確認(プロセスごとの意思確認)ができる。
-
合意の際の選択により、合意形成後にその条件設定が履行されているか否かについて、検証に必要十分な情報を取捨選択して記録することが可能な状態となっており(トレースし)、検証ができる。
-
条件が履行されていない場合には、必要に応じて合意の取消し等が可能である。
-
属性(データ)について、当事者間のみならず、第三者に「移転」した場合にも、当初の条件設定(履行済みのものを除く)を付随してトレースできることで検証ができ、条件設定に基づき合意の取消し等のコントロールが可能な仕組みである。
Trusted Web ホワイトペーパーver1.0 概要④