WebSAM eDocCenter by NEC

Knowledge ManagementTrust Services
Data Spaces, Trust Services

メモ

NEC社が提供する、WebSAM RakuformやWebSAM eDocCenterについて調査。 以下は、genAIを用いたので内容正誤については要注意。

WebSAM eDocCenter

基本情報

  • 製品名: WebSAM eDocCenter
  • 製品バージョン: Ver1.0
  • 提供元: NEC

製品仕様

主要機能

  1. トラストサービス機能
    • タイムスタンプ付与
    • eシール(PAdES)付与
    • 電子署名機能
    • ドキュメント検証機能

特長

  1. APIベースの提供
    • 各種トラストサービスをAPI経由で利用可能
    • 統一されたインターフェース
  2. 処理能力
    • キューイング処理による大量文書対応
    • スケジューラー機能搭載
    • インターバル機能による時間間隔調整
  3. セキュリティ
    • 外部とのやり取りはハッシュ値のみ
    • PDFの改ざん防止機能
    • 署名の有効性検証

製品体系

基本製品

  • WebSAM eDocCenter 実行基盤
  • アマノタイムスタンプサービス関連ライセンス

eシールパッケージ（予定製品）

  • 年間上限5万枚
  • 年間上限10万枚
  • 年間上限30万枚
  • 年間上限50万枚
  • 追加1000枚単位

価格

  • 価格情報は掲載なし（要問い合わせ）

リリース日

  • 明確な記載なし

分析・要約

本製品は、デジタルトランスフォーメーション時代における文書の電子化ニーズに応える製品として位置付けられています。主な特徴は：

  1. 業務効率化
    • 大量文書の自動処理
    • スケジューリング機能による効率的な運用
  2. コスト削減効果
    • ペーパーレス化による印刷・郵送コスト削減
    • 業務自動化による人件費削減
  3. セキュリティ対策
    • 文書の真正性確保
    • 改ざん防止
    • 安全な外部連携

導入検討時の注意点

  • 利用規模に応じたライセンス選択が必要
  • eシール機能は今後リリース予定
  • 具体的な価格は個別見積もりが必要

本製品は、特に大規模な文書管理が必要な企業や、法的要件での電子文書の真正性確保が求められる組織に適していると考えられます。

WebSAM Rakuform

基本情報

  • 製品名: WebSAM Rakuform
  • 製品カテゴリー: 帳票管理ソリューション
  • 最新バージョン: Ver7.0
  • 提供元: NEC

製品概要

帳票業務のシステム構築から運用までをサポートする総合的なソリューションで、以下の特徴があります： - 中小規模から大規模まで対応可能 - ノンプログラム指向の設計 - 多様なアウトプット条件に対応 - オープンな設計思想

重要な更新情報

  • 最新リリース: 2024年10月25日（Ver7.0）
  • 価格体系更新: 2024年11月22日
  • 関連製品: WebSAM eDocCenter（2023年12月22日公開）

主な特徴

  1. さまざまな業種の帳票作成に対応
  2. 専門知識不要のユーザーフレンドリーな設計
  3. 柔軟な帳票作成・保管・印刷機能

環境への配慮

NECの環境配慮基準を満たした製品として認定されています。

分析・考察

本製品は、以下の点で市場での競争力を持っていると考えられます： 1. 幅広い規模の企業に対応可能な柔軟性 2. 専門知識不要という導入障壁の低さ 3. 継続的なアップデートによる機能改善

参考情報

注：具体的な価格情報や詳細な製品仕様については、提供されたページ内容からは確認できませんでした。これらの情報については、NECの営業担当者への直接の問い合わせが必要となります。

共有

CyberTrust and iTrust

Knowledge ManagementTrust Services
Data Spaces, Trust Services

メモ

CyberTrust社のiTrustや近年のData Spacesと関係あるトラストサービスについて調査しまとめたもの。 ただし、GenAIを用いたので内容正誤には注意されたし。

1. iTrust 電子署名用証明書の種類

iTrust 電子署名用証明書は、利用目的や対象に応じて複数の種類が提供されており、電子署名法やセキュリティ要件に応じた設計がなされています。

1.1 個人向け電子署名用証明書

  • 概要: 個人が電子文書に署名するための証明書。
  • 用途:
    • 電子契約書への署名。
    • 個人の身元確認。
  • 特徴:
    • 電子署名法に準拠。
    • 高い信頼性を保証。

1.2 法人向け電子署名用証明書

  • 概要: 法人名義での電子署名を実現する証明書。
  • 用途:
    • 企業間取引における契約書や業務文書への署名。
    • 法人としての身元確認。
  • 特徴:
    • 法人の代表者や担当者を明確に識別。
    • 企業間の信頼性向上。

1.3 システム署名用証明書

  • 概要: システムやアプリケーションが自動的に電子署名を行うための証明書。
  • 用途:
    • 自動生成される契約書やレポートへの署名。
    • システム間のデータ交換の信頼性確保。
  • 特徴:
    • 人的操作を伴わない電子署名に対応。
    • 安全なデータ処理を保証。

1.4 時刻認証用証明書

  • 概要: データのタイムスタンプに関連する証明書。
  • 用途:
    • データの存在時刻や改ざんの有無を証明。
    • 証拠能力の向上。

2. リモート署名サービス

サイバートラストが提供するリモート署名サービスは、クラウド上で電子署名を実現する仕組みで、利便性とセキュリティを両立しています。

2.1 サービス概要

2.2 主な特徴

  1. 利便性
    • クラウド型サービスにより、どこからでも署名可能。
  2. 高いセキュリティ
    • HSM（ハードウェアセキュリティモジュール）を活用し、署名データを安全に保護。
  3. 法的効力
    • 電子署名法に準拠し、法的に有効な電子署名を提供。
  4. コスト削減
    • ハードウェアトークン不要で、導入・運用コストを抑制。

2.3 主な用途

  • 電子契約。
  • 行政手続き。
  • 企業間取引における文書署名。

3. 認定タイムスタンプ

電子帳簿保存法に対応した認定タイムスタンプの仕組みとその役割について解説しました。

3.1 認定タイムスタンプの概要

  • 定義: 国または公的機関から認定を受けたタイムスタンプサービス。
  • URL: サイバートラスト 認定タイムスタンプ
  • 目的:
    • 電子データの「存在時刻」と「改ざんの有無」を証明。
    • 電子帳簿保存法や電子契約における法的効力を担保。

3.2 認定タイムスタンプの仕組み

  1. データのハッシュ値生成:
    • 電子データからハッシュ値（データの指紋）を生成。
    • ハッシュ値は、データそのものを送信せずに安全性を担保。
  2. TSA（タイムスタンプ局）への送信:
    • ハッシュ値を認定タイムスタンプ局（TSA）に送信。
  3. 時刻情報の付与:
    • 信頼性の高い時刻情報（NTPサーバやGPSなど）を基にハッシュ値に時刻を付与。
  4. 電子署名の付与:
    • TSAが時刻情報とハッシュ値に電子署名を付与。
  5. タイムスタンプトークンの返却:
    • 時刻情報＋ハッシュ値＋電子署名を含むタイムスタンプトークンを返却。

3.3 認定タイムスタンプの検証方法

  1. データから再度ハッシュ値を生成:
    • 元のデータから新たにハッシュ値を生成し、トークン内のハッシュ値と比較。
  2. 電子署名の検証:
    • トークンに付与された電子署名を確認し、TSAから発行されたものであることを証明。
  3. 時刻情報の確認:
    • トークン内の時刻情報を確認し、データがその時点に存在していたことを証明。

3.4 認定タイムスタンプの特徴

  • 改ざん防止:
    • データが改ざんされるとハッシュ値が一致しなくなるため、改ざんの有無が即座に判明。
  • 法的効力:
    • 認定タイムスタンプは、電子帳簿保存法の「真実性」と「可視性」の要件を満たす。
  • 高い信頼性:
    • 国や公的機関から認定を受けたTSAが提供するため、信頼性が保証されている。

4. 電子帳簿保存法との関連

  • 電子帳簿保存法は、電子的に作成または保存された帳簿や書類の保存要件を規定しています。
  • 認定タイムスタンプは、この法律における「真実性」と「可視性」を担保する重要な技術です。

4.1 電子帳簿保存法の要件

  1. 真実性:
    • データが改ざんされていないことを証明。
    • 認定タイムスタンプを利用することで担保。
  2. 可視性:
    • 保存されたデータが容易に確認できること。
    • 電子データの検索性や表示性を確保。

参考リンク

以上が、これまでのチャット内容を体系化したまとめです。必要に応じてご活用ください！

参考

共有

IoT Trust of Toshiba デバイス・ストレージ

Knowledge ManagementTrust Services
Data Spaces, Trust Services

メモ

東芝デバイス&ストレージ株式会社のモノのトラストについてまとめたものを以下に示す。 ただし、genAIにて生成したものなので注意されたし。

1. トラストサービスの目的

トラストサービスは、IoT機器のセキュリティを強化するために以下の3つの目的を達成します。

1.1 製造工程からのトレーサビリティ

  • 鍵の書き込み マイコン製造時に安全に鍵を書き込み、認証局から電子証明書を発行。
  • トレーサビリティの確保 鍵と証明書を基に、機器の製造から運用までの追跡可能性を提供。

1.2 機器の長期メンテナンス保証

  • 証明書の長期更新 機器に対する長期サポートを実現。
  • 正規保守部品の提供 パッチ提供や正規部品の配布による安全なメンテナンスを保証。

1.3 IoT化の支援

  • 鍵の配布 IoT機器向けに鍵を配布し、セキュリティ基盤を提供。
  • エコパートナーとの連携 IoT機器のセキュリティを確保するための協力体制を構築。

2. Root of Trust対応マイコン

Root of Trust対応マイコンは、IoT機器のセキュリティをハードウェアレベルで担保する重要なコンポーネントです。

2.1 主な特徴

  • 証明書埋め込み 証明書を埋め込んだマイコンがトラストサービスと安全に接続・認証。
  • 2つのタイプの実装方法
    • コンパニオンタイプ
      • 既存のセキュリティ非対応プロセッサやマイコンに追加することでセキュリティを担保。
      • 最小構成でセキュリティを提供。
      • ホストプロセッサと連携。
    • スタンドアローンタイプ
      • セキュリティ非対応のマイコンを置き換える形で使用。
      • 機能・性能が充実し、堅牢なDPA（Differential Power Analysis）耐性を持つ。
      • スタンドアローンで動作可能。

2.2 主なセキュリティ機能

  • 真贋判定
  • セキュアOTA（Over-The-Air更新）
  • セキュアブート
  • データ保護

3. ソリューション全体の構成

トラストサービスは、東芝とサイバートラストが提供するハードウェア・ソフトウェアの統合ソリューションです。

3.1 東芝提供

  • ハードウェア
    • Root of Trust対応マイコン
  • ソフトウェア
    • デバイスドライバ
    • 暗号エンジン用API
    • サーバ接続用クライアントSDK
      • ISS/OTA Sub Client
      • Key Management

3.2 サイバートラスト提供

  • ソフトウェア
    • セキュアIoTプラットフォーム（証明書認証サービス）

4. 導入のメリット

  • セキュリティの導入ハードルを低減 エッジからクラウドまで、すぐに使えるハードウェア・ソフトウェア・サービスを提供。
  • IoT機器の本物性保証 トラストサービスを通じて、機器の真正性を保証。

5. 参考情報

以上が文書の内容をまとめたものです。必要に応じて追加情報や詳細な説明をお知らせください！

参考

共有

Trends of Mobility Data Spaces in Japan

Knowledge ManagementData Spaces
Data Spaces, Mobility

メモ

データスペースのユースケースのうち、モビリティは各国の事情を踏まえた課題感が存在するはずです。 たとえば、電車のダイヤの乱れが多い地域では、代替手段の探索需要や代替手段を含むスマートな移動に対する需要が高いはずです。 日本に関連するものをまとめてみます。 なお、本内容は生成AIを活用して出力したので内容の正誤、偏りには十分に注意されたし。

はじめに

  • この文書は、日本のモビリティデータスペースに関する取り組みを分析し、国際的な比較を通じてその特徴や課題を明らかにすることを目的としています。
  • 主な結論として、日本は国内でのデータ連携に注力している一方で、国際的な標準化や連携が課題となっていることが示されました。

セクション1：日本のモビリティデータスペースの現状

1.1 Japan Mobility Data Space (JMDS)

  • 概要
    JMDSは、日本国内でのモビリティデータの共有と連携を目指す基盤です。交通状況のリアルタイム分析や効率的なルート計画、公共交通機関の運行管理、自動運転技術の支援などに活用されています。
    • 主要プレイヤー：NTTデータ、デジタル庁、内閣府。
    • 特徴：オープンデータとプライベートデータの統合を推進し、都市間でのデータ共有の促進を目指しています。
    • 課題：地域間の連携不足、データ標準化の遅れ、データプライバシーの懸念。
    • 引用：NTTデータの公式発表

1.2 スマートシティとモビリティデータ

  • Kashiwa-no-haスマートシティ
    千葉県柏市の「Kashiwa-no-haスマートシティ」では、モビリティデータを活用して地域住民の移動効率を向上させる取り組みが進められています。
    • 具体例：電動アシスト自転車の共有サービスや、AIを活用した公共交通の運行最適化。
    • 成果：住民の移動時間削減、交通渋滞の緩和。
    • 引用：Kashiwa-no-haスマートシティ公式情報
  • 横浜市のモビリティプロジェクト
    横浜市では、モビリティデータを活用した「MaaS（Mobility as a Service）」の導入が進められています。
    • 具体例：スマートフォンアプリを通じて、電車、バス、タクシー、自転車の利用を一元化するサービス。
    • 成果：観光客や住民の利便性向上、公共交通利用の促進。
    • 引用：横浜市公式情報

1.3 地方自治体の取り組み

  • 福岡市の取り組み
    福岡市では、交通データを活用した都市計画が進められています。
    • 具体例：交通量データを基にした道路整備計画や、AIを活用した渋滞予測システムの導入。
    • 成果：交通事故の減少、通勤時間の短縮。
    • 引用：福岡市公式情報
  • 富山市のコンパクトシティ構想
    富山市では、公共交通を中心とした「コンパクトシティ」構想の一環として、モビリティデータを活用しています。
    • 具体例：路面電車の運行データを活用した効率化や、住民の移動パターン分析による新路線の提案。
    • 成果：公共交通利用率の向上、CO2排出量の削減。
    • 引用：富山市公式情報

セクション2：国際比較

  • 日本、欧州、アメリカ、中国のモビリティデータスペースにおける特徴を比較します。それぞれの取り組みは、技術開発の方向性や社会的背景に応じて異なります。

2.1 欧州（EU）の取り組み

  • 概要
    欧州では、GAIA-Xという大規模なデータインフラを中心に、国境を越えたデータ共有が進められています。この取り組みは、EU加盟国間でのデータ連携を強化し、物流や自動運転分野での効率化を目指しています。
    • 特徴：国際的な標準化を重視し、データの相互運用性を確保。
    • 課題：各国の規制調整が複雑で、データプライバシー問題が依然として大きなテーマ。
    • 引用：欧州委員会資料

2.2 アメリカの取り組み

  • 概要
    アメリカでは、民間企業が主導する形でモビリティデータの活用が進んでいます。VerizonのThingSpaceなどのIoT基盤が、スマートシティや自動運転車両のデータ連携に活用されています。
    • 特徴：スピード感のある技術開発と、民間主導による柔軟な運用。
    • 課題：標準化が不十分で、データの断片化が課題。
    • 引用：Verizon公式情報

2.3 中国の取り組み

  • 概要
    中国では、国家主導でモビリティデータの統合と活用が進められています。AIを活用した渋滞予測や都市間交通の効率化が行われ、都市部での交通問題解決に寄与しています。
    • 特徴：中央集権的な管理により、迅速な意思決定と実行が可能。
    • 課題：データ管理の透明性が低く、プライバシー保護の議論が不足。
    • 引用：中国政府資料

2.4 比較表

以下は、日本、欧州、アメリカ、中国のモビリティデータスペースの特徴を比較した表です。

項目 日本 欧州（EU） アメリカ 中国
主導者 政府と民間の協力 政府主導（GAIA-X） 民間主導（Verizonなど） 国家主導
データの種類 オープンデータとプライベートデータの統合 国境を超えたデータ連携 IoTデータの活用 AIを活用した統合データ
主な活用分野 スマートシティ、公共交通、自動運転 自動運転、物流最適化 スマートシティ、IoT 渋滞予測、都市間交通効率化
課題 地域間連携不足、国際標準化の遅れ 規制調整の複雑さ、プライバシー問題 標準化の不十分 データ管理の透明性欠如
参考URL 日本事例 欧州委員会資料 Verizon公式情報 中国政府資料

セクション3：課題と将来の展望

  • 日本の課題
    • 地域間連携の不足：地方自治体間でのデータ共有がまだ十分に進んでいない。
    • 国際的な標準化：欧州や中国のような国際的なデータ共有の枠組みに遅れ。
  • 将来の展望
    • 国内のデータ標準化を進め、地域間連携を強化する。
    • 国際連携を視野に入れたデータ共有基盤の構築。

結論

  • 日本のモビリティデータスペースは、国内でのデータ連携やスマートシティ構築において重要な役割を果たしています。
  • 一方で、国際的な標準化や連携が課題として残っており、欧州や中国の事例を参考にすることで、さらなる発展が期待されます。p

参考

共有

International Data Spaces Trustworthy and sovereign data sharing enable the data economy

Knowledge ManagementData Spaces
Data Spaces

メモ

International Data Spaces Trustworthy and sovereign data sharing enable the data economy のホワイトペーパーの概要。 以下は、GenAIを用いたまとめなので内容正誤には注意が必要。

1. 国際データスペースの重要性

国際データスペース（IDS）は、信頼できるデータ共有を可能にし、データ経済の基盤を形成します。データスペースは、複数の組織間でのデータ共有を促進し、参加者間の信頼を構築するための技術的インフラを提供します。IDSAは、データスペースの基準を確立し、データの価値と信頼を維持するための枠組みを提供します【2】。

2. データ主権の擁護

IDSAは、すべての個人と組織が自分のデータを制御できる世界を目指しています。データ主権は、データの管理と責任を誰が持つかを定義し、データの使用ポリシーや契約を明確にすることが重要です。IDSAは、データコネクタを通じて、これらのルールを理解し、遵守することを支援します【3】。

3. IDSAルールブック

IDSAルールブックは、データスペース内の組織間の相互運用性を確保するためのガイドです。データスペースを構築するための基盤を提供し、信頼性を確保するための必須要素を明確にします。相互運用性は、法的、組織的、意味的、技術的なレベルで重要です【4】。

4. データコネクタの役割

データコネクタは、データスペース内の参加者を接続し、データを安全に共有するためのソフトウェアです。これにより、データの流れが円滑になり、信頼性が確保されます。コネクタは、データ交換サービスを提供し、使用ポリシーを強制します【6】。

5. IDS認証

IDS認証は、データ経済における信頼と相互運用性を実現するための重要な役割を果たします。すべてのデータエンドポイントは共通の信頼フレームワークに従い、厳格なセキュリティ基準に基づいて認証されます【7】。

6. データスペースプロトコル

データスペースプロトコル（DSP）は、データスペースの技術実装の中核を成し、参加者間の相互運用性を保証します。標準化されたプロトコルを確立し、システム間のスムーズな通信を促進します【8】。

7. オープンソースの重要性

IDSAは、オープンソースを活用して市場の採用を加速させることを目指しています。透明性と協力を促進し、持続可能なエコシステムを構築することで、データ共有ソリューションの開発を推進します【9】。

8. 標準化の重要性

標準化は、相互運用性を可能にし、技術的障壁を減少させ、貿易を促進します。IDSAは、国際的な標準化活動を通じて、データスペースの実装を支援しています【11】【12】。

9. 成功事例

IDS標準に基づく成功事例が多くの業界で見られます。モビリティデータスペースやCatena-Xなどのプロジェクトは、データの安全な共有を促進し、新しいビジネス機会を生み出しています【16】【17】。

1. モビリティデータスペース（MDS）

  • 目的: 持続可能な交通を促進するために、モビリティサービスと気候変動への貢献を目指します。
  • 参加者: ドイツ政府を含む200以上のステークホルダーが参加。
  • 機能: リアルタイムのモビリティデータを利用し、交通の最適化や公共交通サービスの向上を図ります。
  • 特徴: IDS参照アーキテクチャに基づき、データの出所と品質を保証するための条件を設定できる仕組みが整っています。

2. Catena-X

  • 目的: 自動車産業のデータ主権とコラボレーションを促進します。
  • 参加者: Daimler、BMW、Volkswagenなど、業界の主要企業が参加。
  • 特長: 競争の激しい業界においても、透明で持続可能なサプライチェーンを実現することを目指します。

3. スマートコネクテッドサプライヤーネットワーク（SCSN）

  • 目的: 高度な製造業におけるサプライチェーンの遅延を解消するために開発されました。
  • 機能: パートナー間のコミュニケーションを促進し、重要な情報を追跡する能力を提供します。
  • 効果: 生産性の向上とコスト削減を実現します。

4. Eona-X

  • 目的: 移動、輸送、観光分野におけるデータ主権を促進します。
  • 参加者: Amadeus Group、SNCF、Air Franceなどの主要企業が参加。
  • 特徴: 複数の交通手段や観光地のデータを統合し、利用者の体験を向上させることを目指します。

10. IDSAの国際的な取り組み

IDSAは、データスペースのエコシステムを構築するために、他のデータ関連団体と協力しています。これにより、データ共有の原則を広め、国際的な協力を促進しています【13】【14】。

この要約は、IDSAの目的、活動、及びデータスペースの重要性を強調しています。

オープンソースの重要性

IDSAは、オープンソースを活用することで市場の採用を加速させることを目指しています。オープンソースは、イノベーションと協力を促進し、持続可能で多様なエコシステムを形成するための重要な要素です。IDSAのオープンソース戦略は、IDSコンポーネントの基盤を構築し、透明性、協力、コミュニティの参加を促進します。このアプローチにより、開発が迅速化し、コストが削減され、IDSソリューションが関連性を持ち続けることができます【9】。

また、IDSAはEclipse Foundationと協力し、Eclipse Dataspace Working Group（EDWG）を設立しています。この協力により、データスペースのための普遍的な標準とソフトウェアコンポーネントの開発が加速されます。IDSAは、オープンソースの開発者ネットワークを活用し、信頼できるデータ共有フレームワークの構築を進めています【9】。

https://dataspace.eclipse.org/become-a-member/

Eclipse Foundationの具体的なメンバーシップ費用についての情報は、以下の通りです。

Eclipse Foundationのメンバーシップ費用

メンバーシップレベル 年会費 主な特典
戦略的メンバー (Strategic Members) $50,000 理事会への席、アーキテクチャ評議会への席、戦略的メンバー専用プログラムへのアクセス
貢献メンバー (Contributing Members) $25,000 理事会での代表権、一般集会への参加と投票、Eclipse Working Groupsへの参加
アソシエイトメンバー (Associate Members) $5,000 公開メールリストへの参加、一般集会への出席
コミッターメンバー (Committer Members) 無料または低額 プロジェクトへの貢献

具体的な金額や詳細は、Eclipse Foundationの公式サイトにて確認できます。特に、最新の情報は公式サイトでの確認が推奨されます。 詳細については、以下のリンクを参照してください： - Eclipse Foundation Membership Levels & Fees [1] - Eclipse Foundation FAQ [2]

データスペースレーダーによる影響の推進

データスペースレーダーは、データスペースの取り組みを迅速に収集し、カタログ化するためのツールです。このツールは、世界中のデータスペースイニシアティブを可視化し、100を超えるエントリーが記録されています。

主な機能と目的

  • パノラマビューの提供: データスペースレーダーは、さまざまなセクターや地域、開発段階におけるデータスペースの取り組みを示します。これにより、参加者はどのようなイニシアティブが存在するかを把握できます。

  • 成功事例の紹介: ユーザーフレンドリーなオンラインフォームを通じて収集された成功事例を紹介し、他のプロジェクトチームが最適な技術を選択する際のガイドとして機能します。

  • 評価基盤の提供: データスペースレーダーは、ビジネス、組織、技術の側面から各イニシアティブの開発段階を評価し、包括的な評価の基盤を形成します。

参考

共有

Eclipse Dataspace Protocol Unofficial draft 13 Dec. 2024

Knowledge ManagementData Spaces
Data Spaces, Eclipase

メモ

このメモは、2024/12/13時点の GitHub上で公開されているEclipase Dataspace Protocolのドラフト の内容をまとめたものである。 生成AIにて概要を出力したので内容の正誤については注意されたし。

このドキュメントでは、Dataspace Protocolについて説明します。これは、使用制御によって管理され、Webテクノロジーに基づくエンティティ間で相互運用可能なデータ共有を促進するように設計された一連の仕様です。これらの仕様では、Dataspaceと呼ばれる技術システムの連合の一部として、エンティティがデータを公開し、契約を交渉し、データにアクセスするために必要なスキーマとプロトコルを定義しています。

この仕様の目的

この仕様の目的は、データ共有を容易にするために、データの提供方法を定義することです。

  1. データセットがDCATカタログとしてどのように展開され、使用制御がODRLポリシーとしてどのように表現されるか。 [3]
  2. データの使用を規定する契約がどのように構文的に表現され、電子的に交渉されるか。 [3]
  3. 転送プロセスプロトコルを使用してデータセットにどのようにアクセスするか。 [3]

データスペースプロトコルの主な概念

  • データスペース: エンティティ間での相互運用可能なデータセット共有を促進する一連の技術サービス。 [6]
  • 参加者: データセットを提供および/または消費するデータスペースメンバー。 [6]
  • 参加者エージェント: データセットを提供する参加者に代わって操作を実行するテクノロジーシステム。 [6]
  • カタログ: プロバイダー参加者によってアドバタイズされる、データセットとそのオファーを表すエントリの集合。 [6]
  • 契約交渉: データセットの利用規約を定義する契約について、プロバイダーとコンシューマーの間で行われる一連のインタラクション。 [6][8]
  • 転送プロセス: 契約の条件に基づいてデータセットへのアクセスを提供する、プロバイダーとコンシューマーの間の一連のインタラクション。 [7][8]

データスペースプロトコルは、次のドキュメントで構成されています。

  • データスペースモデルとデータスペース用語集のドキュメント。
  • HTTPSでの共通機能とそのバインディング。
  • カタログプロトコルとカタログHTTPSバインディングのドキュメント。
  • 契約交渉プロトコルと契約交渉HTTPSバインディングのドキュメント。
  • 転送プロセスプロトコルと転送プロセスHTTPSバインディングのドキュメント。 [3]

データスペースプロトコルは、データ転送プロセス自体をカバーしていません。 [4]

相互運用性を確保するために、データスペースプロトコルでは、参加者が互いのサポートされているバージョンを確実に発見できるようにする必要があります。 [9]

カタログプロトコル

カタログプロトコルは、コンシューマーが抽象的なメッセージ交換形式を使用してカタログサービスからカタログを要求する方法を定義します。 [10]

契約交渉プロトコル

契約交渉（CN）には、使用契約に基づいて1つ以上のデータセットを提供するプロバイダーと、データセットを要求するコンシューマーの2つの当事者が関与します。 [18]

転送プロセスプロトコル

転送プロセス（TP）には、使用ポリシーに基づいて1つ以上のデータセットを提供するプロバイダーと、データセットを要求するコンシューマーの2つの当事者が関与します。 [29]

参考

共有

Business model paper by IDSA

Knowledge ManagementData Spaces
Business Model, Data Spaces

メモ

はじめに

本報告書は、International Data Spaces Association（IDSA）が2024年11月に発表したポジションペーパーの分析に基づいています。

IDSA releases new position paper Data Spaces Business Models

以下、生成AIによりポイントを書き出しました。内容の正誤についてはご注意くださいませ。

背景と目的

  • データスペースの採用が進む中、ビジネスモデルの確立が課題
  • 技術的な概念から実践的なビジネスモデルへの移行が必要
  • 関係者間の共通理解と効果的なコミュニケーションの基盤構築

主要な発見

  1. データスペースのビジネスモデルには単一の解決策は存在しない
  2. 成功には3つの重要な特性が必要：
    • 協調型（Collaborative）
    • マルチサイド型（Multi-sided）
    • 進化型（Evolving）
  3. 初期段階での公的資金の重要性と、自己持続可能なモデルへの移行の必要性

セクション1：データスペースのビジネスモデルの特徴

1.1 ビジネスモデルの基本概念

  • 定義: 「組織が価値を創造し、提供し、捕捉する方法の説明」（Alex Osterwalder）
  • 重要な構成要素:
    1. WHAT：市場に提供する価値提案
    2. WHO：価値提案を市場に提供する主体
    3. HOW：価値提案の市場への提供方法
    4. TO WHOM：価値提案の対象顧客
    5. BALANCE：コストと収益のバランス

1.2 データスペース固有の特性

  • データの非競合性：
    • 同時に複数の利用が可能
    • 使用しても価値が減少しない
  • 分散型システムの特徴：
    • データ主権の確保
    • 相互運用性の実現
    • 信頼性の担保

セクション2：実例分析

2.1 モビリティデータスペース（MDS）

背景

  • ドイツ政府主導の取り組み
  • 2019年に開始
  • 約200の参加組織を獲得

ビジネスモデルの特徴

  • 価値提案：
    • 安全な分散型データマーケットプレイス
    • 欧州基準に準拠したデータ共有プラットフォーム
  • 収益モデル：
    • 初期：公的資金と株主出資
    • 将来：データ取引からの収益
  • 具体的なユースケース： 
    1
    2
    3
    4
    5
    6
    1. Pay as you drive保険
       - 保険会社とOEMの協力
       - 実際の車両使用データに基づく保険料設定
    2. 都市モビリティ最適化
       - リアルタイム交通データの活用
       - デジタルツインへの統合

2.2 Catena-X

背景

  • 自動車産業のサプライチェーン最適化
  • 主要自動車メーカーの参加（BMW、VW、Ford、Renaultなど）

ビジネスモデルの特徴

  • 運営構造：
    • Cofinity-X（運営会社）の設立
    • 参加企業のオンボーディング管理
  • ユースケース一覧： 
    1
    2
    3
    4
    5
    1. 製品カーボンフットプリント追跡
    2. バッテリー・製品パスポート
    3. サプライチェーンレジリエンス
    4. 部品トレーサビリティ
    5. マスターデータ管理

2.3 Smart Connected Supplier Network（SCSN）

背景

  • 2015年開始の応用研究プロジェクト
  • オランダの製造業サプライチェーン向け
  • 400以上の製造企業と11のITサービスプロバイダーが参加

ビジネスモデルの特徴

  • 価値提案：
    • 管理負担の軽減
    • 顧客要求への迅速な対応
    • データ処理の自動化
  • 収益モデル：
    • 接続エンドユーザーごとの固定料金
    • ITサービスプロバイダー経由の収益

セクション3：成功要因の分析

3.1 共通する成功要因

  1. 段階的アプローチ

    • 初期：公的資金活用
    • 成長期：参加者拡大
    • 成熟期：自己持続的モデル

  2. エコシステムの構築 

    1
    2
    3
    4
    - データ提供者
    - データ消費者
    - サービスプロバイダー
    - 技術プロバイダー

  3. 価値創造の明確化

    • 経済的価値
    • 社会的価値
    • 規制遵守価値

結論

  1. データスペースの成功には、技術的側面とビジネスモデルの両立が不可欠
  2. 初期段階での公的支援と、長期的な自己持続性のバランスが重要
  3. 参加者それぞれの価値創造を明確にし、適切なインセンティブ設計が必要

今後の展望

  • より多様なユースケースの開発
  • 産業間連携の促進
  • グローバルな標準化の進展

「データスペースのビジネスモデルは単一ではなく、状況に応じて進化する必要がある」 ― IDSA Position Paper, 2024

参考

共有

MVD_of_EDC

Knowledge ManagementDataspace ConnectorEclipse Dataspace Components
Dataspace Connector, EDC, IDS

メモ

MVDを用いた動作確認用のメモ

Eclipse Dataspace Componentsのセットアップ

まず、Eclipse Dataspace Components（EDC）をセットアップします。EDCは、データスペースにおけるデータ連携を実現するためのフレームワークです。以下の手順でEDCをセットアップします。

準備

必要環境 に必要となる環境が書いてある。

  • Docker
  • KinD (other cluster engines may work as well - not tested!)
  • Terraform
  • JDK 17+
  • Git
  • a POSIX compliant shell
  • Postman (to comfortably execute REST requests)
  • openssl, optional, but required to regenerate keys
  • newman (to run Postman collections from the command line)
  • not needed, but recommended: Kubernetes monitoring tools like K9s

Docker

Docker Desktop

kind

kindのインストール方法

JDK

JDK17をインストール

Postman

Postmanのダウンロード

openssl

1
sudo apt install openssl

newman

npmのインストールから必要

1
2
3
sudo apt install nodejs npm n
sudo n stable
sudo npm install -g newman

ソースコードのクローン

今回はMVDを用います。

1
2
git clone https://github.com/eclipse-edc/MinimumViableDataspace.git
cd MinimumViableDataspace

公式サイトの環境構成図

環境構成

ビルドと起動

k8s上で各種サービスを起動する。

ビルド

1
2
./gradlew build
./gradlew -Ppersistence=true dockerize

kind (k8s) 環境起動 

1
2
3
4
# Create the cluster
kind create cluster -n mvd --config deployment/kind.config.yaml
# Load docker images into KinD
kind load docker-image controlplane:latest dataplane:latest identity-hub:latest catalog-server:latest sts:latest -n mvd

1
2
3
4
# 確認
docker ps
CONTAINER ID   IMAGE                  COMMAND                   CREATED         STATUS         PORTS                                                                 NAMES
b7f31408c498   kindest/node:v1.27.3   "/usr/local/bin/entr…"   2 minutes ago   Up 2 minutes   0.0.0.0:80->80/tcp, 0.0.0.0:443->443/tcp, 127.0.0.1:32825->6443/tcp   mvd-control-plane

ingress NGINXコントローラをk8s上にデプロイ

1
2
3
4
5
6
7
8
# Deploy an NGINX ingress
kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/main/deploy/static/provider/kind/deploy.yaml

# Wait for the ingress controller to become available
kubectl wait --namespace ingress-nginx \
  --for=condition=ready pod \
  --selector=app.kubernetes.io/component=controller \
  --timeout=90s

今回のMVD環境をデプロイ

1
2
3
4
5

# Deploy the dataspace, type 'yes' when prompted
cd deployment
terraform init
terraform apply

確認

1
kubectl get pods --namespace mvd

結果 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
NAME                                                   READY   STATUS    RESTARTS   AGE
consumer-controlplane-68c4696c57-2qmh2                 1/1     Running   0          55s
consumer-dataplane-75d79bfd56-t5mt2                    1/1     Running   0          39s
consumer-identityhub-545fdb579c-df6bq                  1/1     Running   0          55s
consumer-postgres-687484545b-sp8xr                     1/1     Running   0          96s
consumer-sts-778bb7bb44-kfqxp                          1/1     Running   0          70s
consumer-vault-0                                       1/1     Running   0          95s
dataspace-issuer-server-7ff68bd8b4-qh7c7               1/1     Running   0          96s
provider-catalog-server-58b67bdb89-nxtvq               1/1     Running   0          54s
provider-identityhub-bb68bfcf4-bv42v                   1/1     Running   0          55s
provider-manufacturing-controlplane-86bdd7c967-b6r7h   1/1     Running   0          54s
provider-manufacturing-dataplane-7d66445bf8-dp24n      1/1     Running   0          39s
provider-postgres-7fd78d95b8-x2kzd                     1/1     Running   0          96s
provider-qna-controlplane-dc894c5ff-qxcd7              1/1     Running   0          55s
provider-qna-dataplane-8574c764fd-t2x8z                1/1     Running   0          39s
provider-sts-64cd87f4f6-n5cvq                          1/1     Running   0          70s
provider-vault-0                                       1/1     Running   0          95s

構成

  • Consumer
    • コントロールプレーン
    • データプレーン
    • アイデンティティ・ハブ
    • PostgreSQLサーバ
    • Vault
  • Provider
    • カタログ
    • QNAのコントロールプレーンとデータプレーン
    • Manufacturingのコントロールプレーンとデータプレーン
    • アイデンティティ・ハブ
    • PostgreSQLサーバ
    • Vault

データの流し込み

プロジェクト直下の、seed-k8s.shを使うとデータを流したりできる。

1
bash seed-k8s.sh

以下、内容を確認。

seed-k8s.shでは、Postman（Newman）を使って、コネクタに各種データを登録するなどしている。 例えば以下の通り。

seed-k8s.sh:23 

1
2
3
4
5
6
7
8
echo "Seed data to 'provider-qna' and 'provider-manufacturing'"
for url in 'http://127.0.0.1/provider-manufacturing/cp' 'http://127.0.0.1/provider-qna/cp'
do
  newman run \
    --folder "Seed" \
    --env-var "HOST=$url" \
    ./deployment/postman/MVD.postman_collection.json
done

上記の newman コマンドの引数に与えられているファイル deployment/postman/MVD.postman_collection.json にPostman（Newman）用のコンフィグファイルがある。 newmanコマンドのfolderオプションにある通り、今回は「Seed」フォルダ以下の内容を実行する。 なお、この登録処理は以下の両方のホストに実施される。 * provider-qna * provider-manufacturing

行われる処理は以下。

  • アセット登録
    • asset-1
    • asset-2
  • ポリシー登録
    • require-membership
    • require-dataprocessor
    • require-sensitive
  • コントラクト登録
    • member-and-dataprocessor-def
      • アクセスポリシーは require-membership
      • コントラクトポリシーは require-dataprocessor
      • 対象アセットは asset-1
    • sensitive-only-def
      • アクセスポリシーは require-membership
      • コントラクトポリシーは require-sensitive
      • 対象アセットは asset-2

続いて、スクリプトにある通り、deployment/postman/MVD.postman_collection.json の Seed Catalog Server フォルダ以下が実行される。 対象ホストは、 provider-catalog-server 。

seed-k8s.sh:35

1
2
3
4
5
6
7
echo "Create linked assets on the Catalog Server"
newman run \
  --folder "Seed Catalog Server" \
  --env-var "HOST=http://127.0.0.1/provider-catalog-server/cp" \
  --env-var "PROVIDER_QNA_DSP_URL=http://provider-qna-controlplane:8082" \
  --env-var "PROVIDER_MF_DSP_URL=http://provider-manufacturing-controlplane:8082" \
  ./deployment/postman/MVD.postman_collection.json
  • カタログアセット登録
    • linked-asset-provider-qna
    • linked-asset-provider-manufacturing
  • アセット登録
    • normal-asset-1
  • ポリシー登録
    • require-membership
  • コントラクト定義登録
    • membership-required-def

スクリプトを実行すると以下のような結果が得られる。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
Seed data to 'provider-qna' and 'provider-manufacturing'          
newman                                                                                                  
                                                                                                        
MVD+IATP                                                                                                
                                                                                                        
❏ Seed                                                                                                  
↳ Create Asset 1                                                                                        
  POST http://127.0.0.1/provider-manufacturing/cp/api/management/v3/assets [200 OK, 331B, 66ms]
  ✓  Status is OK or conflict                                                                           
                                                                                                        
↳ Create Asset 2                                                                                        
  POST http://127.0.0.1/provider-manufacturing/cp/api/management/v3/assets [200 OK, 331B, 23ms]         
  ✓  Status is OK or conflict                                                                           
                                                                                                        
↳ Create Membership Policy                                                                              
  POST http://127.0.0.1/provider-manufacturing/cp/api/management/v3/policydefinitions [200 OK, 342B, 71ms]
  ✓  Status is OK or conflict                             

(snip)

┌─────────────────────────┬───────────────────┬──────────────────┐
│                         │          executed │           failed │
├─────────────────────────┼───────────────────┼──────────────────┤
│              iterations │                 1 │                0 │
├─────────────────────────┼───────────────────┼──────────────────┤
│                requests │                 7 │                0 │
├─────────────────────────┼───────────────────┼──────────────────┤
│            test-scripts │                14 │                0 │
├─────────────────────────┼───────────────────┼──────────────────┤
│      prerequest-scripts │                21 │                0 │
├─────────────────────────┼───────────────────┼──────────────────┤
│              assertions │                 7 │                0 │
├─────────────────────────┴───────────────────┴──────────────────┤
│ total run duration: 466ms                                      │
├────────────────────────────────────────────────────────────────┤
│ total data received: 1.45kB (approx)                           │
├────────────────────────────────────────────────────────────────┤
│ average response time: 34ms [min: 19ms, max: 71ms, s.d.: 21ms] │
└────────────────────────────────────────────────────────────────┘

コンシューマとプロバイダの登録

続いて、コンシューマ登録。

seed-k8s.sh:49

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
echo "Create consumer participant"
CONSUMER_CONTROLPLANE_SERVICE_URL="http://consumer-controlplane:8082"
CONSUMER_IDENTITYHUB_URL="http://consumer-identityhub:7082"
DATA_CONSUMER=$(jq -n --arg url "$CONSUMER_CONTROLPLANE_SERVICE_URL" --arg ihurl "$CONSUMER_IDENTITYHUB_URL" '{
           "roles":[],
           "serviceEndpoints":[
             {
                "type": "CredentialService",
                "serviceEndpoint": "\($ihurl)/api/presentation/v1/participants/ZGlkOndlYjpjb25zdW1lci1pZGVudGl0eWh1YiUzQTcwODM6Y29uc3VtZXI=",
                "id": "consumer-credentialservice-1"
             },
             {
                "type": "ProtocolEndpoint",
                "serviceEndpoint": "\($url)/api/dsp",
                "id": "consumer-dsp"
             }
           ],
           "active": true,
           "participantId": "did:web:consumer-identityhub%3A7083:consumer",
           "did": "did:web:consumer-identityhub%3A7083:consumer",
           "key":{
               "keyId": "did:web:consumer-identityhub%3A7083:consumer#key-1",
               "privateKeyAlias": "did:web:consumer-identityhub%3A7083:consumer#key-1",
               "keyGeneratorParams":{
                  "algorithm": "EC"
               }
           }
       }')

curl --location "http://127.0.0.1/consumer/cs/api/identity/v1alpha/participants/" \
--header 'Content-Type: application/json' \
--header "x-api-key: $API_KEY" \
--data "$DATA_CONSUMER"

プロバイダ登録

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
echo "Create provider participant"

PROVIDER_CONTROLPLANE_SERVICE_URL="http://provider-catalog-server-controlplane:8082"
PROVIDER_IDENTITYHUB_URL="http://provider-identityhub:7082"

DATA_PROVIDER=$(jq -n --arg url "$PROVIDER_CONTROLPLANE_SERVICE_URL" --arg ihurl "$PROVIDER_IDENTITYHUB_URL" '{
           "roles":[],
           "serviceEndpoints":[
             {
                "type": "CredentialService",
                "serviceEndpoint": "\($ihurl)/api/presentation/v1/participants/ZGlkOndlYjpwcm92aWRlci1pZGVudGl0eWh1YiUzQTcwODM6cHJvdmlkZXI=",
                "id": "provider-credentialservice-1"
             },
             {
                "type": "ProtocolEndpoint",
                "serviceEndpoint": "\($url)/api/dsp",
                "id": "provider-dsp"
             }
           ],
           "active": true,
           "participantId": "did:web:provider-identityhub%3A7083:provider",
           "did": "did:web:provider-identityhub%3A7083:provider",
           "key":{
               "keyId": "did:web:provider-identityhub%3A7083:provider#key-1",
               "privateKeyAlias": "did:web:provider-identityhub%3A7083:provider#key-1",
               "keyGeneratorParams":{
                  "algorithm": "EC"
               }
           }
       }')

curl --location "http://127.0.0.1/provider/cs/api/identity/v1alpha/participants/" \
--header 'Content-Type: application/json' \
--header "x-api-key: $API_KEY" \
--data "$DATA_PROVIDER"

上記の通り、DIDを登録している。

成功すると以下のようなメッセージが見られる。

1
2
3
4
5
6
7
8
9
(snip)

Create consumer participant                                                                             
{"apiKey":"ZGlkOndlYjpjb25zdW1lci1pZGVudGl0eWh1YiUzQTcwODM6Y29uc3VtZXI=.TfDP+lAgK+GUb7f+dNSvU9WKpZPNV1zZ/YJ8gNoNlrI3zZkcrg8b7dWAYMYD+k3qOoVdp+ZAE3C5fHWgmsQtww==","clientId":"did:web:consumer-identityhub%3A708
3:consumer","clientSecret":"IMyZ5gqsnXihiftx"}                                                          
                                                                                                        
Create provider participant                                                                             
{"apiKey":"ZGlkOndlYjpwcm92aWRlci1pZGVudGl0eWh1YiUzQTcwODM6cHJvdmlkZXI=.h7Ta9GRuNSOrD7I/BS681E7OsvsX/YEpDrz/Mj+1nJxG3xAFtwTGCFP0qF/QxWdZ/aJvi7ywehpAu/Cg/Yi37w==","clientId":"did:web:provider-identityhub%3A708
3:provider","clientSecret":"P751oqFsm4npVkai"}

動作確認

READMEの「7. Executing REST requests using Postman」を参考に実施。

変数にはローカル環境用とKubernetes環境用があるので、今回はkubernetes環境用を使用。

deployment/postman/MVD K8S.postman_environment.json

Postmanでインポートすると以下のように環境が見える。

環境

続いて、collectionをインポートする。

deployment/postman/MVD K8S.postman_collection.json

コレクションをインポートすると、以下のように各種リクエストをPostmanから送れるようになる。

環境

カタログ

以下のように、環境をMVD K8Sに変更（右上）し、Get Cached Catalogsを実行すると、カタログ情報が見え、先程登録したasset-1とasset-2の情報が見えるはず。

asset-1の場合は以下のような感じ。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
{
    "@id": "fcc9cefa-c31e-4155-ad59-35294044cc6d",
    "@type": "dcat:Catalog",
    "dcat:dataset": [
        {
            "@id": "asset-1",
            "@type": "dcat:Dataset",
            "odrl:hasPolicy": {
                "@id": "bWVtYmVyLWFuZC1kYXRhcHJvY2Vzc29yLWRlZg==:YXNzZXQtMQ==:OThhZGM3OGQtZDM1Ny00MDQwLTlhYmUtYzI3YTIzYTMyNmUz",
                "@type": "odrl:Offer",
                "odrl:permission": [],
                "odrl:prohibition": [],
                "odrl:obligation": {
                    "odrl:action": {
                        "@id": "odrl:use"
                    },
                    "odrl:constraint": {
                        "odrl:leftOperand": {
                            "@id": "DataAccess.level"
                        },
                        "odrl:operator": {
                            "@id": "odrl:eq"
                        },
                        "odrl:rightOperand": "processing"
                    }
                }
            },
            "dcat:distribution": [
                {
                    "@type": "dcat:Distribution",
                    "dct:format": {
                        "@id": "HttpData-PULL"
                    },
                    "dcat:accessService": {
                        "@id": "6cccbc00-9fa5-4f99-a2d9-524d2881f72f",
                        "@type": "dcat:DataService"
                    }
                },
                {
                    "@type": "dcat:Distribution",
                    "dct:format": {
                        "@id": "HttpData-PUSH"
                    },
                    "dcat:accessService": {
                        "@id": "6cccbc00-9fa5-4f99-a2d9-524d2881f72f",
                        "@type": "dcat:DataService"
                    }
                }
            ],
            "description": "This asset requires Membership to view and negotiate.",
            "id": "asset-1"
        },

README通り、今回はプロバイダのQ&A departmentに着目する。 エンドポイント情報が、上記のアセット情報の直後にあるのを見つける。

1
2
3
4
5
6
7
"dcat:service": {
    "@id": "6cccbc00-9fa5-4f99-a2d9-524d2881f72f",
    "@type": "dcat:DataService",
    "dcat:endpointDescription": "dspace:connector",
    "dcat:endpointUrl": "http://provider-qna-controlplane:8082/api/dsp",
    "dcat:endpointURL": "http://provider-qna-controlplane:8082/api/dsp"
},

それとアセットのIDを確認しておく、odrl:hasPolicy.@idにある。 今回の例だと、

asset-1

1
2
3
4
"@id": "asset-1",
"@type": "dcat:Dataset",
"odrl:hasPolicy": {
    "@id": "bWVtYmVyLWFuZC1kYXRhcHJvY2Vzc29yLWRlZg==:YXNzZXQtMQ==:OThhZGM3OGQtZDM1Ny00MDQwLTlhYmUtYzI3YTIzYTMyNmUz",

asset-2 は一旦省略

コントラクトネゴシエーション

先の手順で確認した、asset-1のIDを変数に設定する。（実際には、各自の値を使用すること）

環境

これは、リクエストボディの以下に用いられる。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
{
    "@context": [
        "https://w3id.org/edc/connector/management/v0.0.1"
    ],
    "@type": "ContractRequest",
    "counterPartyAddress": "{{PROVIDER_DSP_URL}}/api/dsp",
    "counterPartyId": "{{PROVIDER_ID}}",
    "protocol": "dataspace-protocol-http",
    "policy": {
        "@type": "Offer",
        "@id": "{{POLICY_ID_ASSET_1}}",
        "assigner": "{{PROVIDER_ID}}",
        "permission": [],
        "prohibition": [],
        "obligation": {
            "action": "use",
            "constraint": {
                "leftOperand": "DataAccess.level",
                "operator": "eq",
                "rightOperand": "processing"
            }
        },
        "target": "asset-1"
    },
    "callbackAddresses": []
}

続いて、initiate negotiationを実行する。

環境

レスポンスが見られるはず。 ただし、この状態ではまだコントラクトネゴシエーションを開始しただけ。状況確認が必要。

状況の確認

続いて、Get Contract Negotiationsを実行する。

環境

ステータスがFINALIZEDになっていることがわかる。 今回は、1回実行しただけなので、以下のとおりだが、複数回実行するとそのぶんだけ並ぶ。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
[
    {
        "@type": "ContractNegotiation",
        "@id": "378b9249-b869-426f-b224-7879d358d2a1",
        "type": "CONSUMER",
        "protocol": "dataspace-protocol-http",
        "state": "FINALIZED",
        "counterPartyId": "did:web:provider-identityhub%3A7083:provider",
        "counterPartyAddress": "http://provider-qna-controlplane:8082/api/dsp",
        "callbackAddresses": [],
        "createdAt": 1737304019738,
        "contractAgreementId": "59b8c0b1-a9b1-4b83-b85d-715758941595",
        "@context": {
            "@vocab": "https://w3id.org/edc/v0.0.1/ns/",
            "edc": "https://w3id.org/edc/v0.0.1/ns/",
            "odrl": "http://www.w3.org/ns/odrl/2/"
        }
    }
]

上記からcontractAgreementId がわかる。59b8c0b1-a9b1-4b83-b85d-715758941595である。 このあとのデータ転送において利用する。

トランスファーの初期化

Initiate Transferを実行するが、その際のリクエストボディは以下の通り。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
{
    "@context": [
        "https://w3id.org/edc/connector/management/v0.0.1"
    ],
    "assetId": "asset-1",
    "counterPartyAddress":  "{{PROVIDER_DSP_URL}}/api/dsp",
    "connectorId": "{{PROVIDER_ID}}",
    "contractId": "{{CONTRACT_AGREEMENT_ID}}",
    "dataDestination": {
        "type": "HttpProxy"
    },
    "protocol": "dataspace-protocol-http",
    "transferType": "HttpData-PULL"
}

上記の、CONTRACT_AGREEMENT_IDに渡す値を先ほど控えた値に書き換えて、Initiate Transferを実行する。 先程控えておいた値にする。各自の値を使用すること。

環境

戻りは以下のような内容。

1
2
3
4
5
6
7
8
9
10
{
    "@type": "IdResponse",
    "@id": "0278e81e-5dea-4ab7-876f-60cd8a202e09",
    "createdAt": 1737304134741,
    "@context": {
        "@vocab": "https://w3id.org/edc/v0.0.1/ns/",
        "edc": "https://w3id.org/edc/v0.0.1/ns/",
        "odrl": "http://www.w3.org/ns/odrl/2/"
    }
}

これでトランスファーの処理が開始された。ただし、実際のデータ転送が始まったわけではない。 今回は、HttpData-PULLプロトコルを用いることになっており、そのためには実際のデータを取得するためのエンドポイントとアクセスキーを取得しないとならない。

EDR（EndpointDataReference）取得

Get cached EDRsを実行する。特に変数設定などは不要。

環境 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
[
    {
        "@id": "0278e81e-5dea-4ab7-876f-60cd8a202e09",
        "@type": "EndpointDataReferenceEntry",
        "providerId": "did:web:provider-identityhub%3A7083:provider",
        "assetId": "asset-1",
        "agreementId": "59b8c0b1-a9b1-4b83-b85d-715758941595",
        "transferProcessId": "0278e81e-5dea-4ab7-876f-60cd8a202e09",
        "createdAt": 1737304136114,
        "contractNegotiationId": "378b9249-b869-426f-b224-7879d358d2a1",
        "@context": {
            "@vocab": "https://w3id.org/edc/v0.0.1/ns/",
            "edc": "https://w3id.org/edc/v0.0.1/ns/",
            "odrl": "http://www.w3.org/ns/odrl/2/"
        }
    }
]

今回は有効なEDRが1個なので上記の通り。 EDRのIDがわかる。0278e81e-5dea-4ab7-876f-60cd8a202e09

アクセストークンの取得

先程確認したEDRのIDを用いて、EDRを取得する。

環境 
1
2
3
4
5
6
7
8
9
10
11
12
13
{
    "@type": "DataAddress",
    "type": "https://w3id.org/idsa/v4.1/HTTP",
    "endpoint": "http://provider-qna-dataplane:11002/api/public",
    "authType": "bearer",
    "endpointType": "https://w3id.org/idsa/v4.1/HTTP",
    "authorization": "eyJraWQiOiJkaWQ6d2ViOnByb3ZpZGVyLWlkZW50aXR5aHViJTNBNzA4Mzpwcm92aWRlciNrZXktMSIsImFsZyI6IkVTMjU2In0.eyJpc3MiOiJkaWQ6d2ViOnByb3ZpZGVyLWlkZW50aXR5aHViJTNBNzA4Mzpwcm92aWRlciIsImF1ZCI6ImRpZDp3ZWI6Y29uc3VtZXItaWRlbnRpdHlodWIlM0E3MDgzOmNvbnN1bWVyIiwic3ViIjoiZGlkOndlYjpwcm92aWRlci1pZGVudGl0eWh1YiUzQTcwODM6cHJvdmlkZXIiLCJpYXQiOjE3MzczMDQxMzU3OTQsImp0aSI6IjI3Y2Y0ODFlLTQ5YWYtNDI0YS1iNjc5LTk2YzQ4MmY4ODAyNyJ9.whzgJzBy9ydxontusqowd_wG33KjSfzjxqXxb600csDUdrGHFl45CEQtbRdOfSvffjQTaincEKZpAovS9b2gqg",
    "@context": {
        "@vocab": "https://w3id.org/edc/v0.0.1/ns/",
        "edc": "https://w3id.org/edc/v0.0.1/ns/",
        "odrl": "http://www.w3.org/ns/odrl/2/"
    }
}

上記の通り、エンドポイント情報とアクセストークが得られた。

1
2
3
4
5
(snip)
    "endpoint": "http://provider-qna-dataplane:11002/api/public",
(snip)
    "authorization": "eyJraWQiOiJkaWQ6d2ViOnByb3ZpZGVyLWlkZW50aXR5aHViJTNBNzA4Mzpwcm92aWRlciNrZXktMSIsImFsZyI6IkVTMjU2In0.eyJpc3MiOiJkaWQ6d2ViOnByb3ZpZGVyLWlkZW50aXR5aHViJTNBNzA4Mzpwcm92aWRlciIsImF1ZCI6ImRpZDp3ZWI6Y29uc3VtZXItaWRlbnRpdHlodWIlM0E3MDgzOmNvbnN1bWVyIiwic3ViIjoiZGlkOndlYjpwcm92aWRlci1pZGVudGl0eWh1YiUzQTcwODM6cHJvdmlkZXIiLCJpYXQiOjE3MzczMDQxMzU3OTQsImp0aSI6IjI3Y2Y0ODFlLTQ5YWYtNDI0YS1iNjc5LTk2YzQ4MmY4ODAyNyJ9.whzgJzBy9ydxontusqowd_wG33KjSfzjxqXxb600csDUdrGHFl45CEQtbRdOfSvffjQTaincEKZpAovS9b2gqg",
(snip)

データの取得

先程確認したトークンを用いてデータを取得する。

環境 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
[
    {
        "userId": 1,
        "id": 1,
        "title": "delectus aut autem",
        "completed": false
    },
    {
        "userId": 1,
        "id": 2,
        "title": "quis ut nam facilis et officia qui",
        "completed": false
    },
    {
        "userId": 1,
        "id": 3,
        "title": "fugiat veniam minus",
        "completed": false
    },
    {
(snip)

(wip)

参考

共有

Data Governance part of Global Digital Compact

Knowledge ManagementData Governance
Data Governance, Data Spaces

メモ

Global Digital Compact (United Nation) に掲載されている国連のGlobal Digital Compact資料のうち、データガバナンスに関する箇所を軽く解説。

参考

共有

Trouble using Docker Desktop and docker

Knowledge ManagementDocker
Docker

メモ

Ubuunu22で、Docker Desktopとディストリ向けパッケージのDockerを混在させたときにトラブったので備忘録。 ひとまず、Contextの指定を忘れないように。（自分向けメモ）

1
2
3
4
# コンテキストの確認
docker context ls
# コンテキスト切り替え
docker context use <任意のコンテキスト>

なお、DOCKER_HOSTの環境変数にも注意。 うっかり、なにかの名残で指定していることがあるので。

参考

共有