【Trusted Web】研究
第2回:”Trusted Web”の基本機能

Jasmy League
Jasmy League
Published in
15 min readJun 14, 2021
iStock/bsd555

01. Trusted Web基盤構築にあたっての最終目的

前回では、Trusted Webなるものについて少し考えてみました。

と言っているうちに、令和3年3月31日付で「Trusted Web ホワイトペーパー ver1.0」が発表されました。1)

こちらも含めて、おさらいをすると、Trusted Webは、

① 「自分に関連するデータに対する他者からのアクセスについて、自らがコントロールをすること」と

② 「使う側と提供する側と明確な意思による合意形成の仕組み(基盤)を整備すること」で、

未知の相手でも事実を確認しない状態で相手先が期待した通りにふるまうと信じる度合が高い環境を実現し

現状のインターネットが抱える課題(歪み)を解決しようとしている、情報・通信基盤、という理解でした。

そのような現状のインターネットが抱える課題(歪み)を解決するために、現在のインターネットからさらに一歩進めた自律分散協調型の通信情報基盤が、Trusted Webの仕組みと言えそうです。その仕組みを使うことで、今のインターネットが抱える課題の解決だけでなく、最終的に新たな付加価値を創出することが目的となりそうです。

今回は、さらに一歩進み、Trusted Webの機能について見ていきましょう。

前回のおさらいとして上記にあげた「トラステッドウェブなるもの」が現状のインターネットにおける歪みをばっちり解決したと仮定した場合、データの出し手、データの受け手、データ授受に関するステークホルダーの間で複数の役割(ロール)が実現しているであろうと、ホワイトペーパーでは整理されています。

02. Trusted Webにおけるステークホルダー

ここからは、ホワイトペーパーに記載されている、「④車両等のライフサイクルにおける価値評価」のユースケースを基に、これらのステークホルダーの役割を見ていきましょう。ここでは、さらに「車両を保有しているオーナーが車を売る場合」にフォーカスして考えてみます。

ユースケース全体のステークホルダーは、図1のようになりますが、話を簡単にするために、まずは「中古車を購入したい人」を中心に見ていきましょう。

この場合、「オーナー」が所有している車は、「完成車メーカー」が車両を製造します。「完成車メーカー」は車両を「カーディーラー」に販売を委託し、「オーナー」が「カーディーラー」から車両を購入したことがわかると思います。ここでは、「オーナー」の保有車両は、コネクテッドカーであるとし、車がネットワークに繋がることで、車両に搭載された各種センサーから、車両の機器や部品などのデータが「完成車メーカー」に通知されているものとします。そのデータを基に「完成車メーカー」が車の状態を「オーナー」に通知をします。「オーナー」は、その通知された情報に従い「整備工場」で整備や修理を依頼し、車両の状態を保つものとします。

そして、「オーナー」が保有している車両を、「中古車販売事業者」が査定し買い取り、その車を「中古車を購入したい人」が購入するのです。

図1. ステークホルダー一覧:車両等のライフサイクルにおける価値評価

そして、「オーナー」の関心は、以下3点と考えられます。

1) 自分の車の価値を高く評価してもらいたい。

2) 自分の車を安全な状態に保ち適切に評価してもらいたい。

3) でも、メンテナンス費用は抑えたい。

図2. 車のオーナーの関心

ですが、この車両を扱う「中古車販売事業者」と、「中古車を購入したい消費者」の関心は以下と考えられます。

中古車販売事業者 :車の事故歴や修理歴を把握して、出来る限り正確に車の査定を行いたい

中古車を購入したい人:中古車を不当に高く購入したくない。

しかし、販売データ、整備データ、車検データ、車のデータなどは、各ステークホルダーが保有しており、現状ではデータの共有が困難なため、「オーナー」の持つ車が正確にどうなっているかが把握できず、「中古車販売事業者」は効果的な査定ができないことにフラストレーションを抱えていると考えられます。

そして、「中古車を購入したい人」も、「中古車販売事業者」の提示する金額の妥当性について疑問を抱く場合もありそうです。それは、「オーナー」が中古車を高値で売りたい心理が働きがちのため、事故歴や修理歴などを意図せず「中古車販売事業者」に隠してしまうことも極めて稀にあるからかもしれません。その内容も「中古車を購入したい人」が知りたいことでしょう。

図3. 車を買う中古車販売事業者と消費者の関心

そのようなことを解決し、「中古車を買いたい人」が満足できるように、Trusted Webの仕組みを活用することが考えられるのです。そして、それが、「中古車販売事業者」や「オーナー」も満足されるようになるのです。

前提条件がここまでになります。「車両を保有しているオーナーが車を売る場合」、図4に示すようにステークホルダーの役割は以下のようになります。

❶ データの出し手 :オーナー

❷ データの受け手 :中古車販売事業者

❸ データの出し手の基になる情報の生成

a) 本人確認情報や登録車情報等:国

b) 販売情報と車の情報 :カーディーラー(販売店)

c) 車の状態通知 :完成車メーカー(OEM)

d) 車の整備・修理情報 :整備工場(整備点検事業者)

❹ 最終的なデータの受け手 :中古車を購入したい人

❺ トラストアンカー :国

図4. 車を売る場合の各ステークホルダーの役割

このようなスキームの中で、データ提供時に双方で合意した条件が履行されているかの検証の仕組みと、P2P(peer-to-peer)で合意形成がされ、相手が期待した通りにふるまう度合いが高い環境(トラスト)でのデータ授受が行われるような自立分散協調型の通信情報基盤なわけです。

03. Trusted Webシステム基盤の基本的なビジネス要件(実現したい要件)とそれを実現させるための機能

Trusted Webではビジネス要件の代わりに、必要な原則を定義しています。

支える仕組み:

① 持続可能なエコシステム

② マルチステークホルダーによるガバナンス

③ オープンネスと透明性

ユーザーの観点:

④ データ主体によるコントロール

⑤ ユニバーサル性

⑥ ユーザー視点

システムの観点:

⑦ 継続性

⑧ 柔軟性

⑨ 相互運用性

⑩ 公開容易性・拡張性

これらを社会実装するための設計には以下の4つの基本機能が必須であるとしています。

個人や法人識別をする機能(Identifier管理機能)

本ユースケースでは、個人識別や本人確認のために運転免許証記載の運転免許番号が使われ、車両の識別のために車検証記載の車体番号が使われると考えられます。運転免許証と車検証は国が発行し、法人の場合、会社法人等番号があります。

もう少し具体的に見ていきましょう。

法人の場合、法人番号があります。それを法人IDとして利用することもできますし、サービス提供時だけ専用IDを利用し、そこに各法人のサービス内容等を紐づけることもできるのです。ここでは、完成車メーカーの法人IDがOEM_A、完成車メーカーの提供するコネクテッドカーのサービスがCON_A、整備工場の法人IDがFA_A、カーディーラーの法人IDがCDL_A、中古車販売事業者の法人IDがOCDL_Aとします。

個人であるオーナーを識別するために運転免許番号をIDとして利用することができます。ここではその番号をIID_Xとします。また車検証には車両番号CID_Xがあります。しかし、プライバシー保護の観点から、そのIID_XやCID_Xをそのまま使うことが望ましくないこともあるでしょう。その場合、オーナー自らVID_Xを発行し、そこに運転免許証と車検証が紐づいていることが属性情報ATT_Xとして示されるだけにすることも可能になります。ここに、コネクテッドカーのサービスがCON_A、整備工場FA_A、カーディーラーCDL_Aも、さらに紐づけられるのです。そして、CDL_Aの属性情報には購入情報(含む、メーカー情報、車両情報)があり、CON_Aの属性情報には車両状況の履歴があり、FA_Aの属性情報には整備・修理履歴があるのです。

また、中古車を購入したい個人はIID_Yとなるでしょうが、同様にプライバシー保護の観点から、中古車購入希望者のIDとしてVID_Yが利用され、そこに運転免許証が紐づいていることが属性情報ATT_Yに示されていることでしょう。

図5. 各ステークホルダーのID
図6.「オーナー」と「中古車を買いたい人」が持つIDと属性情報

ここでは、「オーナー」と「中古車を買いたい人」のみについて説明しましたが、このように必要な時に必要な情報が紐づけられたIDを発行・管理する仕組みが、identifier管理機能になります。

提供されたデータの真贋確認の手間をなくす機能(Trustable Communication機能)

ここで各個人や各法人が発行した専用ID本当に正しいのか?が疑問になる場合があります。

まず、運転免許証と車検証は国が発行し、法人の場合、会社法人等番号があります。これらは、国がトラストアンカーとなり、本人であることを担保し、かつ車の証明や、会社の存在も担保するわけです。

また、「オーナー」自ら発行したVID_Xを見てみましょう。VID_Xには属性情報ATT_Xが紐づいています。この属性情報ATT_Xには運転免許証と車検証が紐づいています。これらの運転免許証と車検証がトラストアンカーとしての国が証明してくれることで、この情報が正しいことがわかります。また、「オーナー」の第三者によるレビュー結果がポジティブである場合、「オーナー」が安心できる方だと判断できるでしょう。つまり、中古車販売事業者は査定時に、「オーナー」が信頼できる方であることが事前にわかるのです。

また、同様に「中古車販売事業者」が自ら発行した、査定用IDのVID_Dに紐づく第三者によるレビュー結果がポジティブの場合はいかがでしょうか?そして、図に記載していませんが、事業者であれば登記簿による証明も可能です。それらのデータにより、同様に中古車販売事業者が信頼できると事前にわかるでしょう。

では、実際に車の査定時に、どのようなやり取りが行われるのかを見ていきましょう。

「オーナー」が「中古車販売事業者」に査定申し込みを行い、それとともに「オーナー」の属性を開示します。

例えば、図7に記載されているように、開示範囲は、

車検証 :オーナーの氏名/住所を除く記載事項全て

車両購入情報 :店舗名、店舗住所、購入日時、車種情報

車両情報・整備情報等:全て

とします。そして、その情報の利用できる期間は、査定見積もりが行われると想定される、申し込みから24時間以内として開示できるのです。

図7. オーナーが持つIDと属性情報の開示

このように属性を各々が管理し、その内容をその都度照会しなくても相手の属性が検証可能になり、またその属性の開示範囲や利用期間などを自分が決めて開示できるのです。そして、それらの属性がトラストアンカーとなる国が担保することや、第三者によるレビューにより、その内容の信頼性が判断できるようになるのです。この信頼性のことを、ホワイトペーパーでは「Trust」と呼んでいるようです。

データのやり取りをする双方で様々な条件を設定し合意形成を行う機能(Dynamic Consent)

「オーナー」が「中古車販売事業者」に保有車両査定申し込み時に、「中古車販売事業者」側で業務多忙のため、24時間以内の見積もりができない場合があったとしましょう。その場合、「中古車販売事業者」が「オーナー」が提示した利用期間内では査定結果を連絡することができません。この場合、逆に「中古車販売事業者」から「オーナー」に条件提示ができます。この場合、条件受諾から3営業日で完了できることが「中古車販売事業者」側から「オーナー」に連絡されています。「オーナー」がそれを了承する場合、このやり取りの続きとして、「オーナー」から

利用目的 : 査定目的に限る。

保存方法 : 査定結果受領まで保持可能。その後破棄。

とデータの利用目的の特定と、保存方法について条件提示があるでしょう。

その内容を、「中古車販売事業者」が了承した場合、以下の条件でのデータ提供が合意となります。

車検証 :オーナーの氏名/住所を除く記載事項全て

車両購入情報 :店舗名、店舗住所、購入日時、車種情報

車両情報・整備情報等:全て

利用期間 : 条件受諾時から3営業日。

利用目的 : 査定目的に限る。

保存方法 : 査定結果受領まで保持可能。その後破棄。

図8. 「オーナー」と「中古車販売事業者」との合意形成プロセス

このようにデータ授受の合意形成において、データの取扱いについて条件設定ができ、かつその条件が一致することで合意が成立する機能をDynamic Consentと言います。本ユースケースでは、人が合意までのやりとりをすることを想定して説明しましたが、これをエージェントに代理して合意までのやり取りを行ってもらうことも想定されています。このやり取りのときに悪質な相手をブロックすることもできるようです。ホワイトペーパーでは、このエージェントはプログラムを含むと記載されていますので、場合によっては、このエージェントがAIになるのかもしれませんね。

データ授受の際の合意形成が確実に行われたかの確認や、その合意条件内容が履行されていることの確認に必要な情報を記録され、それが、検証できる機能(Trace機能)

データ授受の合意形成についてさらに詳しく見てみましょう。合意形成のやりとりには、図9のように時刻情報time1, time2, time3, time4が付随しているのが、わかるかと思います。この履歴情報が、「オーナー」と「中古車販売事業者」の属性情報の中に、査定履歴として記録されるのです。この履歴情報が、「オーナー」と「中古車販売事業者」ともにお互いに見られるようにしておけば、この合意形成が確実に行われたかの確認ができるでしょう。今回の場合、time4に合意形成が確実に行われたことがわかります。ただし合意形成のプロセスにおいて、この情報も開示することを明示的に示すことが必要であることは言うまでもないでしょう。ここではその具体的な内容は省略します。

そして、データ授受に関しても同様の履歴が記録され、お互いに確認できるようになっていれば、その合意条件内容が履行されているかの検証ができるようになるでしょう。

図9. 「オーナー」と「中古車販売事業者」との合意形成プロセス(時刻情報有)
図10. 「オーナー」と「中古車販売事業者」の査定履歴(合意形成時)

このように、データ授受の際の合意形成が確実に行われたかの確認や、その合意条件内容が履行されていることの確認に必要な情報が記録され、それが検証できる機能がTrace機能と言うようです。それ以外にもホワイトペーパーでは、条件不履行時における取り消しや、第三者への「移転」についても同様に履歴が記録され、検証できるようになっていることが記されています。

05. 最後に

というわけで、今回はTrusted Webのユースケース、「④車両等のライフサイクルにおける価値評価」を基に、4つの基本機能について見てみました。「中古車を購入したい人」にとって、このように査定が安心して行われていることがわかれば、「中古車販売事業者」から安心して中古車を購入することができることがわかるのではないのでしょうか?

ところで、Jasmyが提供するSKC(セキュアナレッジコミュニケーター)の機能はご存知でしょうか?よろしければ、是非Jasmyのホワイトペーパー2)をご覧になってください。

このTrusted Webの世界が、Jasmyの目指す「データの民主化」と交わる部分がでてきているように見受けられます。では、ガバナンスはどうなっているのでしょうか、、、、?(続:第3回へ続きます)

参考:

1) Trusted Web ホワイトペーパーVer1.0

https://www.kantei.go.jp/jp/singi/digitalmarket/trusted_web/pdf/documents_210331-2.pdf

2) Jasmyホワイトペーパー

https://jasmy.co.jp/images/whitepaper.pdf

--

--