[データ駆動型社会を支える「データスペース」の実像─ハンズオンで理解するその価値と可能性]

2024年10月30日(水)角井 健太郎、土橋 昌、八木 拓馬、渡邊 凜太郎（NTTデータグループ 技術革新統括本部）

リスト

　第8回では、データスペース構築フレームワークの1つ「Eclipse Dataspace Components（EDC）」のサンプルプロジェクト「EDC Samples」を用いて、データ交換を行うための環境構築を行いました。

　第9回となる本稿以降では、「契約締結」と「データ転送」の2つに分けて、EDCを用いたデータ転送のための契約交渉の一連の流れをハンズオン形式で解説します。なお、手順の解説にあたり、第8回と同様、データ提供側を「Provider」、データ利用側を「Consumer」と呼ぶこととします。

　本稿では契約締結について解説します（図1）。今回扱う契約締結は、大まかに「データ交換を行うためのデータ利用者・提供者の合意形成」を指し、以下の6つの手順で行います。

1. アセットの作成：共有するデータをコネクタに登録する
2. ポリシーの作成：契約条件を策定する
3. コントラクト定義の作成：データと契約条件を紐づける
4. カタログの共有：データ利用者にデータと契約条件を共有する
5. 契約交渉の開始：利用規約に基づいて契約交渉を実施する
6. 契約交渉状況の確認：契約交渉の状況を確認する

図1：契約締結のイメージ
拡大画像表示

　以降の作業では、第8回と同様にProvider側とConsumer側のそれぞれのコマンド実行用WSL2ウィンドウ（ターミナル）も起動していることを前提に進めます。第8回の手順後に実行環境を終了した場合は、再度、解説に従ってProvider側とConsumer側のWSL2ウィンドウ（ターミナル）上にそれぞれのコネクタを起動させるようにしてください。図2のようにウィンドウを配置すると、コネクタのログと実行結果をそれぞれProvider側とConsumer側で見比べながら進められます。

図2：WSL2ウィンドウ（ターミナル）の配置
拡大画像表示

　また、コマンド実行用WSL2ウィンドウ（ターミナル）で、カレントディレクトリをクローンしたEDC Sampleプロジェクトのトップディレクトリに移動してください。以降のコマンド実行時には当該ディレクトリに移動してあることを前提にパスを記載しています。

データの場所を示す「アセット」の作成

　ProviderとConsumerとの間でやり取りされるのはデータの実体ではなく、「アセット」と呼ばれるオブジェクトです（※1）。アセットにはデータの場所が登録されており、参照することでそのデータにアクセスできるようになります。

　ここでは、Providerのコネクタでアセットを作成する方法を解説します（図3）。Provider側のコマンド実行用WSL2ウィンドウ（ターミナル）で作業します。

図3：アセット作成のイメージ
拡大画像表示

　今回は、HTTPを用いてアクセスできるデータのURLをアセットに指定します。プロジェクトに含まれている以下のJSONファイルは、今回登録するassetIdというIDのアセットの情報を示しています。dataAddress内にはデータの場所が記載されています。baseUrlにはデータのURL、typeはデータのアクセス方法を指しています。HttpDataはSHTTPリクエストを通じてデータを取得することを示しています。

cat transfer/transfer-01-negotiation/resources/create-asset.json

Providerコネクタのコマンド例

{
  "@context": {
    "@vocab": "https://w3id.org/edc/v0.0.1/ns/"
  },
  "@id": "assetId",
  "properties": {
    "name": "product description",
    "contenttype": "application/json"
  },
  "dataAddress": {
    "type": "HttpData",
    "name": "Test asset",
    "baseUrl": "https://jsonplaceholder.typicode.com/users",
    "proxyPath": "true"
  }
}

実行結果例

　以上のJSONファイルを、Provider側コネクタの/management/v3/assetsというパスのエンドポイントに送信します。これにより、新しいアセットがProvider上に作成されます。実行結果からassetIdというIDのアセットが作成されたことを確認できます。

curl -d @transfer/transfer-01-negotiation/resources/create-asset.json -H 'content-type: application/json'  http://localhost:19193/management/v3/assets -s | jq

Providerコネクタのコマンド例

{
  "@type": "IdResponse",
  "@id": "assetId",
  "createdAt": 1723089292961,
  "@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/"
  }
}

実行結果例

契約の条件を定める「ポリシー」の設定

　次に、作成したアセットに対応するポリシーを作成します。ポリシーとは、本稿において契約を締結するConsumerのように、何らかのアクションを行うもの（EDCの開発者ドキュメントでは“subject”）が満たさなくてはいけない必要条件です（※2）。

　ポリシーにはさまざまな条件を定義できます。EDCの開発者ドキュメントでは、「契約を結ぶ際にはその組織のヘッドクォーターがある地域になくてはならない」というような例を挙げています。

図4：ポリシー作成
拡大画像表示

　ここでは、aPolicyというIDのポリシーを作成します。引き続きProvider側のコマンド実行用WS2ウィンドウ（ターミナル）で作業してください。

　プロジェクトに含まれている以下のJSONファイルを用います。permission列に許可、prohibition列に禁止事項、obligation列に義務が記載されます。今回は例のため、いずれも空にします。そのためaPolicyは、だれに対しても特別な条件なくすべてアクセスを許可するポリシーになります。

　なお、以下の例ではpermission列は空になっているため何も許可していないように見えますが、permission列が空の場合はすべて許可する実装になっています（後述のポイント①を参照）。

cat transfer/transfer-01-negotiation/resources/create-policy.json -s | jq

Providerコネクタのコマンド例

{
  "@context": {
    "@vocab": "https://w3id.org/edc/v0.0.1/ns/",
    "odrl": "http://www.w3.org/ns/odrl/2/"
  },
  "@id": "aPolicy",
  "policy": {
    "@context": "http://www.w3.org/ns/odrl.jsonld",
    "@type": "Set",
    "permission": [],
    "prohibition": [],
    "obligation": []
  }
}

実行結果例

　次に、Providerコネクタの/management/v3/policydefinitionsのパスのエンドポイントに上記のJSONを送信します。これでポリシーの作成は完了です。

curl -d @transfer/transfer-01-negotiation/resources/create-policy.json -H 'content-type: application/json' http://localhost:19193/management/v3/policydefinitions -s | jq

Providerコネクタのコマンド例

{
"@type": "IdResponse", 
"@id": "aPolicy", 
"createdAt": 1723089737840, 
"@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/”
 　　} 
}

実行結果例

ポイント①：実装におけるポリシーの評価について

　本稿のサンプルで用いるEDC Connectorの実装では、ポリシーを評価するためにorg.eclipse.edc.policy.evaluator.PolicyEvaluatorのvisitPolicyメソッドを呼び出します。その実装は以下のとおりですが、もしpermissionなどに与えた値が空の場合は、ruleProblems.isEmpty()の戻り値が真になります。結果として、本稿のケースではConsumerがどのアセットでも利用可能となります（※3）。

    public Boolean visitPolicy(Policy policy) {
        policy.getPermissions().forEach(permission -> permission.accept(this));
        policy.getProhibitions().forEach(prohibition -> prohibition.accept(this));
        policy.getObligations().forEach(duty -> duty.accept(this));
        return ruleProblems.isEmpty();

アセットとポリシーを紐づける「コントラクト定義」

　ここでは「コントラクト定義」を作成します（図5）。コントラクト定義とは、大まかには、先の手順で作成したアセットとポリシーとを紐づけたものを指します。どのポリシーがどのアセットに対して有効かを定義するものともいえます（※4）。

図5：コントラクト定義作成のイメージ
拡大画像表示

　コントラクト定義には、以下の3つの要素が含まれます。

●アクセスポリシー：”誰に（どのようなConsumerに）” アセット提供を許可するかを規定します。例えば、地理的な制約を設けて、特定の地域内のConsumerだけがアセットにアクセスできるようにし、地域外のConsumerのカタログに表示されないようにする、といった条件を設定できます。

●コントラクトポリシー：”どのような条件で”契約交渉を開始できるかを規定します。例えば、データにアクセスする場合はその使用ログを提出する必要がある、といった条件を設定できます。

●アセットセレクタ：クエリ表現（※5）を使って定義され、対象とするアセットを選択できます。これにより、特定の条件を満たすアセットに対し、アクセスポリシー及びコントラクトポリシーの下で条件判定できるようになります（後述のポイント②を参照）。

　本稿で作成するコントラクト定義は、以下のJSONに記載されている内容です。今回の例では、assetSelectorで特にフィルタ条件を指定せず、accessPolicyとcontractPolicyではに先の手順で作成したaPolicyというIDのアセットを指定しています。

cat transfer/transfer-01-negotiation/resources/create-contract-definition.json -s | jq 

Providerコネクタのコマンド例

{ "@context": { 
"@vocab": https://w3id.org/edc/v0.0.1/ns/
 }, 
"@id": "1", 
"accessPolicyId": "aPolicy", 
"contractPolicyId": "aPolicy", 
"assetsSelector": [] 
}

実行結果例

　Providerコネクタの/management/v3/contractdefinitionsというパスのエンドポイントに上記のJSONを送信します。これにより、aPolicyに記載されたアクセス許可をすべてのアセットに付与したコントラクト定義を作成できます。

curl -d @transfer/transfer-01-negotiation/resources/create-contract-definition.json -H 'content-type: application/json' http://localhost:19193/management/v3/contractdefinitions -s | jq

Providerコネクタのコマンド例

{ 
　"@type": "IdResponse", 
　"@id": "1", 
　"createdAt": 1723091052360, 
　"@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/" 
　} 
}

実行結果例

　以上でコントラクト定義の作成は完了です。これで、Consumer側から契約交渉を申し込むための準備が整いました。

ポイント②：assetSelectorについて

　EDCの開発者ドキュメントには、以下のような例が載っています。edc:assetsSelectorに値が含まれていますが、ここではfoo=barというプロパティをもつアセットが対象になる、ということを表しています。このようなクライテリアを用いた選択はやや複雑ですが便利です。詳しくは上述のドキュメントを参照ください。

{
  "@context": {
    "edc": "https://w3id.org/edc/v0.0.1/ns/"
  },
  "@type": "https://w3id.org/edc/v0.0.1/ns/ContractDefinition",
  "@id": "test-id",
  "edc:accessPolicyId": "access-policy-1234",
  "edc:contractPolicyId": "contract-policy-5678",
  "edc:assetsSelector": [
    {
      "@type": "https://w3id.org/edc/v0.0.1/ns/Criterion",
      "edc:operandLeft": "foo",
      "edc:operator": "=",
      "edc:operandRight": "bar"
    }
  ]
}

[参考文献]
※1：Assets, EDC docs Developer's Handbook, Eclipse Foundation（https://github.com/eclipse-edc/docs/blob/main/developer/handbook.md#assets）
※2：Policies, EDC docs Developer's Handbook, Eclipse Foundation（https://github.com/eclipse-edc/docs/blob/main/developer/handbook.md#policies ）
※3：EDC Connector v0.8.1 PolicyEvaluator.java, Eclipse Foundation（https://github.com/eclipse-edc/Connector/blob/v0.8.1/core/common/lib/policy-evaluator-lib/src/main/java/org/eclipse/edc/policy/evaluator/PolicyEvaluator.java#L71）
※4：Contract definitions, EDC docs Developer's Handbook, Eclipse Foundation（https://github.com/eclipse-edc/docs/blob/main/developer/handbook.md#contract-definitions）
※5：Expressing queries with a Criterion, EDC docs Developer's Handbook, Eclipse Foundation（https://github.com/eclipse-edc/docs/blob/main/developer/handbook.md#expressing-queries-with-a-criterion）

●Next：安全なデータ共有を実現する契約の仕組み