TrustedWeb

Trusted Webの GithubページTrusted WebのYouTubeページTrusted WebのTwitterページ
/
Trusted Webの GithubページTrusted WebのYouTubeページTrusted WebのTwitterページ
/
Trusted Webとは

Trusted Webとは

特定のサービスに過度に依存せずに、データ自体とデータのやり取りを検証できる領域を拡大し、Trustを向上する仕組みです。

直面している課題Trusted Webが目指す方向性Trusted Webによって
出来るようになることフレームワークのアプローチ

直面している課題

  • 偽情報やフェイク動画が
    増えてきて、
    何を信頼して良いか
    分からない

    Challenge 1
    bubble tail

  • サービス提供に必要な
    顧客情報が必要だけど、
    サイバー攻撃や
    ミスによる流出が怖い
    し、情報管理も大変

    Challenge 2
    bubble tail

  • 住民票とか本人確認書類とか、
    手続きでよく使うものを
    オンラインで簡単に取れて、
    手続きで使えると便利なのに

    Challenge 3
    bubble tail

  • 温暖化対策で取引先にCO2データを
    渡さなきゃだけど、
    他の目的で使われないか不安

    Challenge 4
    bubble tail

  • ウエアラブルデータを使って、
    医療や科学の発展に貢献したいけど、
    どこが信頼できるのかなぁ

    Challenge 5
    bubble tail

  • 不正防止のため、本人確認したいけど、
    確認コストが高くなって、
    安価にサービス提供できなくなってしまう

    Challenge 6
    bubble tail

  • 必要なIDとパスワードが多すぎ。
    A社アカウントで、B社サイトにサインインできるけど、
    A社に私生活バレるのも嫌だな

    Challenge 7
    bubble tail

  • ウエアラブルデータ
    を使って、
    医療や科学の発展に
    貢献したいけど、
    どこが信頼できるのかなぁ

    Challenge 5
    bubble tail

  • 温暖化対策で取引先に
    CO2データを
    渡さなきゃだけど、
    他の目的で使われ
    ないか不安

    Challenge 4
    bubble tail

  • 必要なIDと
    パスワードが多すぎ。
    A社アカウントで、
    B社サイトに
    サインインできるけど、
    A社に私生活
    バレるのも
    嫌だな

    Challenge 7
    bubble tail

  • 不正防止のため、
    本人確認したいけど、
    確認コストが高くなって、安価にサービス提供
    できなくなってしまう

    Challenge 6
    bubble tail

共通する課題

  1. 1.

    やり取りされるデータが信頼できるか

  2. 2.

    データをやり取りする相手方を信頼できるか

  3. 3.

    提供したデータの相手方における取扱いを信頼できるか

=

カギとなるのが“Trust”

Trusted Webが
目指す方向性

  • Trustとは

    事実の確認をしない状態で、相手先が期待したとおりに振る舞うと信じる度合い

  • Trusted Webの目的

    デジタル社会における様々な社会活動に対応するTrustの仕組みをつくり、多様な主体による新しい価値の創出を実現すること

  • Trusted Webが実現を目指す
    Trustの仕組み

    特定サービスに過度に依存せず、

    ・

    ユーザ（人間又は法人）自身が自らに関連するデータをコントロールすることを可能とし

    ・

    データのやり取りにおける合意形成の仕組みを取り入れ、その合意の履行のトレースを可能としつつ

    ・

    検証(verify)できる領域を拡大することにより、Trustの向上を目指すものである

仕組みによりVerifiable（検証可能）な部分が増える

現在のインターネット

仕組みによりVerifiable（検証可能）な部分が増える

検証できる部分が小さく相手を
大きく信頼しないと意思決定できない。

Arrow

目指すところ

仕組みによりVerifiable（検証可能）な部分が増える

ある程度検証できる部分を増やす継続性、
相互運用性、更改容易性を充足する仕組み

「Trust」を高める

*スケーラビリティやエネルギー消費といった課題、特定の技術に依存しすぎることのない更改容易性の観点等も踏まえた
トレードオフもあるので、すべてを検証可能にするという考え方ではない。

Trusted Webによって
出来るようになること

#01

特定のサービスのアカウントではなく、
自らのアカウントによって、様々な
Webサービスが使えるようになる

自らのアカウントによって、様々なWebサービスが使えるようになる
Arrow
自らのアカウントによって、様々なWebサービスが使えるようになる
POINT

  • Webサービス提供者は、ログイン時に必要な属性情報を確認するだけでよく、顧客の個人情報を保有せずに済む
    （漏洩リスクや管理コストが減少する）

  • ユーザーは、自身の閲覧履歴やWebサービス利用状況をWEBサービス事業者に知られずに済むし、閲覧履歴に基づく
    広告が出にくくなるかもしれない

  • 特定のサービスアカウントに依存せず、ユーザーは多数のIDやパスワードを管理する必要がなくなる

  • A社サービスにおける自身の利用状況を、自分の判断で、B社サービスに連携し、便利なサービスが受けられるようになる
    （例：SNSの友達数）

#02

信頼の証明が多様になる

信頼の証明が多様になる
Arrow
信頼の証明が多様になる
POINT

  • 「上場企業の取引先が〇社以上ある」「銀行に法人口座がある」「A町にふるさと納税をしている」「B社に所属している」など、政府以外の様々な主体が、トラストアンカー（信頼の基点）になれる。

  • 様々な主体が、手軽にVCを発行できるようになると、信頼を証明するユーザーのコストや、信頼を確認するサービス事業者の確認コストが下がり（標準化されたデータ様式なので、一々目視で証明書に問題ないか確認不要になる）、サービスが多様化する

  • 様々な信頼の証明が「Verifiable　Credential」として発行され、ユーザーはそのVCをスマホ等のWalletに入れることができる。
    ユーザーはそのVCをデジタル化された証明書として、使うことができる。

Trusted Webが
目指す方向性

bg 1

デジタル・ビジネスにおけるネットワーク効果や収益逓増・費用逓減等の要因によって、
独占・寡占に至りやすく、ロックイン効果が働きやすいと考えられます。
新たなTrustの仕組みをデジタル・インフラに構築していく上では、現在見られるペインポイントの再来を回避するため、一部の企業活動に過度に依存することとならないよう、共有財（コモンズ）としてのインフラとしてのガバナンスのあり方の検討が不可欠となります。
このため、グローバルかつ技術中立指向のインターネットガバナンスを準用することが必要であり、標準化、実装、運用、コミュニティ形成等において、様々なステークホルダーが関与していくことが重要です。

Trusted Webの上で利用されるアプリケーションは、各国の既存の法制度や商慣習が構成する
Trustに根差した仕組みとも必要に応じて協調していきます。

bg 2

Trusted Webで解決したい課題

  • データの保持される場所に依存せず、データ自身を検証できる

  • データが保持されうる場所の間でのデータに関するやりとりを検証できる

これらを対象領域（ドメイン）横断で実現するため、可能な限り既存の技術を再利用しつつ、 組み合わせ可能な技術を見いだし整理し、
対象となるアプリケーションに共通している部分のモデルを見いだし、アーキテクチャに 抽象度高い形で統合する取組を行っております。

実現するためのアーキテクチャ

データを主体とした視点で、検証可能なデータ、アイデンティティ、メッセージ、トランザクションの4つの構成要素とし、
計算資源と通信を主体とした視点で、ノード、トランスポートの２つの構成要素として、あわせて６構成要素にて整理しております。
本アーキテクチャを実証事業等の取り組みから妥当性を検証し、アップデートを実施していきます。

実現するためのアーキテクチャ

6つの構成要素

  1. 01

    検証可能なデータVerifiable Data

    Trusted Webでの操作の対象となるデータ。
    《署名自身》の検証、《署名者》の検証、《署名の意図》の明確化によって、署名を含むデータ全体を検証できる

  2. 02

    アイデンティティIdentity

    検証可能なデータの一種。属性情報（所属組織名など）によって構成。データを検証可能とするため、アイデンティティに結びつけられている署名にまつわる情報との連携が必須アイデンティティ間の関係を表すアイデンティティグラフを参照可能とし、データの検証可能性を拡大

  3. 03

    ノードNode

    メッセージの送受信を司る。受信時に計算処理（合意形成など）を実行できる。ノードはトランザクションを記録し、記録はアイデンティティに紐づけて保持。

  4. 04

    メッセージMessage

    送信元から送信先への配送の確実性のある一方向メッセージ送信。ノード間でやりとりされるデータであり、ノードで実装される。

  5. 05

    トランザクションTransaction

    メッセージ送受の順番をノード間で確認できるデータとメカニズム。分散保持しつつ、記録を全てのノードで保持することを保証。外部記録に依存せず、秘匿した形で関係者間のみで共有できる。

  6. 06

    トランスポートTransport

    他のノードに対してメッセージを送信するための適切な手段を提供。様々な技術（インターネット・近接型無線通信など）を適用可能とするため、包括的な通信モデルの設計が必要。

Trusted Webがやらないこと

Trusted Webは、相互運用性が技術中立的に実現する状態の実現と継続を目指し仕組みであり、
既存の技術要素に対するオーバーレイ・アプローチによる開発を行います。

  • 実装される言語や、システムを制限しません。技術的な要件やユースケースに応じた選択が可能です。

  • サポートするアプリケーションの種類を制限しません。Trusted Webは検証可能な領域を広げるための構成案などを提示することはありますが、
    既存の仕組みを組みあわせてカスタマイズすることができます。

改善要望・お問い合わせ

Trusted Webは随時、アーキテクチャや取り組みへの改善要望・お問い合わせを受け付けております。

関連リンク

お問い合わせ時の注意事項

Trusted Web推進協議会HPへのお問い合わせをいただきありがとうございます。
頂いたご意見・コメントを適切に処理するため、以下のフォーマットに則った記載をお願いいたします。
※注意書き・記載例については送信時削除いただいて構いません。

＜メール件名＞
問い合わせ内容について、問い合わせ元様とその種別が一見して分かるよう簡潔な記入を件名欄へお願いいたします。
例）
【株式会社●●】Trusted Webの議論コミュニティへの参加要望
【株式会社●●】プライバシーポリシーに関する質問

＜問い合わせの種別＞
問い合わせ内容の種別を、以下よりご選択お願いいたします。
1. Trusted WebのGitHub上のコミュニティへの参加のご要望
2. HPの構成・コンテンツの記載内容等に関するご意見・コメント
3. その他ご意見・コメント

＜問い合わせの内容＞
1. Trusted WebのGitHub上のコミュニティへの参加のご要望
・参加を希望される組織名、個人名、ご連絡のつくメールアドレス、Githubアカウントをご記入下さい
例）●●株式会社、氏名、メールアドレス（参加希望人数分）、Githubアカウント
・参加を希望される議論の内容や貢献したい点について具体的にご記入下さい。
なお、ご希望の内容や貢献内容、経験等を踏まえ、コミュニティには参加いただけない可能性があること、ご了承願います。
例）自社で～～のシステムを開発しています。2022年度のユースケース実証において課題とされていた●●●について解決を試みており、Trusted Webの有識者に見てもらい指摘いただきつつ、必要に応じて改善を行い、Trusted Webの実現に向けて貢献に参加したいと考えています。

2. HPの構成・コンテンツの記載内容に関するご意見・コメント
・対象となるHPのページ・コンテンツ名称を明記のうえご記入下さい
例）ユースケースページの●●について、記載が「●●」とあるが、●●ではないか

3. その他ご意見・コメント
・問い合わせ内容について具体的にご記入下さい

お問い合わせ

お問い合わせ

Trusted Webの各ステークホルダーとコミュニケーションする場合は
お問い合わせフォームにご連絡ください。

お問い合わせ時の注意事項

Trusted Web推進協議会HPへのお問い合わせをいただきありがとうございます。
頂いたご意見・コメントを適切に処理するため、以下のフォーマットに則った記載をお願いいたします。
※注意書き・記載例については送信時削除いただいて構いません。

＜メール件名＞
問い合わせ内容について、問い合わせ元様とその種別が一見して分かるよう簡潔な記入を件名欄へお願いいたします。
例）
【株式会社●●】Trusted Webの議論コミュニティへの参加要望
【株式会社●●】プライバシーポリシーに関する質問

＜問い合わせの種別＞
問い合わせ内容の種別を、以下よりご選択お願いいたします。
1. Trusted WebのGitHub上のコミュニティへの参加のご要望
2. HPの構成・コンテンツの記載内容等に関するご意見・コメント
3. その他ご意見・コメント

＜問い合わせの内容＞
1. Trusted WebのGitHub上のコミュニティへの参加のご要望
・参加を希望される組織名、個人名、ご連絡のつくメールアドレス、Githubアカウントをご記入下さい
例）●●株式会社、氏名、メールアドレス（参加希望人数分）、Githubアカウント
・参加を希望される議論の内容や貢献したい点について具体的にご記入下さい。
なお、ご希望の内容や貢献内容、経験等を踏まえ、コミュニティには参加いただけない可能性があること、ご了承願います。
例）自社で～～のシステムを開発しています。2022年度のユースケース実証において課題とされていた●●●について解決を試みており、Trusted Webの有識者に見てもらい指摘いただきつつ、必要に応じて改善を行い、Trusted Webの実現に向けて貢献に参加したいと考えています。

2. HPの構成・コンテンツの記載内容に関するご意見・コメント
・対象となるHPのページ・コンテンツ名称を明記のうえご記入下さい
例）ユースケースページの●●について、記載が「●●」とあるが、●●ではないか

3. その他ご意見・コメント
・問い合わせ内容について具体的にご記入下さい

お問い合わせ