コンテンツにスキップ

適用例（コンテンツ権利管理）

コンテンツ権利管理への適用例

以下では、メタバース空間におけるコンテンツ権利管理のシナリオに沿って、Tr3システムの利用方法を説明します。

シナリオの概要

ある芸能事務所が、実在するアイドルを仮想現実空間の中でもプロデュースし、イベント開催及び関連グッズ販売を行うためのメタバース空間を運営しています。 その芸能事務所に所属するアイドルが、所持しているコンテンツデータ（画像）をALHTとして発行し、 発行されたALHTがメタバース空間内において、そのアイドルのファン同士で売買される世界を想定します。 以下の図は、本シナリオの登場人物（ユーザ）及びシステム概要を図示したものです。

シナリオ概要

本シナリオでは、メタバース空間をサービスとして提供するメタバースシステム（Tr3クライアントとも呼ぶ）、 ユーザがメタバース空間にアクセスするためのアプリ（スマートフォン、PC、VRデバイスなどにインストールされているアプリやWebブラウザ） 及びTr3システムが存在します。 メタバース空間内で扱われるコンテンツデータはTr3システムでALHTに変換され、ALHTがメタバース空間内においてファン同士で売買され流通します。

ALHTの流通は、ALHT発行やALHT移転といった複数のALHT取引により構成されます。 各ALHT取引は、ワークフローがあらかじめ定義されています。 そのワークフローに従ってユーザが順番に承認し、全承認が完了するとALHT取引が成立します。

本シナリオでは、事務所A、アイドルB、ファンC、ファンDがユーザとして登場します。 各ユーザの役割は以下の通りです。

ユーザ 説明
事務所A メタバース空間の運営者で、ワークフローの最終承認者。
アイドルB 事務所Aに所属しており、事務所Aが運営するメタバース空間に、自身が所持しているデータをアップロードし、自身が権利を取得したALHTとして発行します。
ファンC、ファンD ALHTを自由に購入できます。また、自身が権利を保有しているALHTを他のファンに転売できます。

今回のシナリオでは、ワークフローの具体例として以下が考えられます。

  1. ALHT発行：アイドルB -> 事務所A（アイドルBがALHTを発行）
  2. ALHT移転：ファンC -> アイドルB -> 事務所A（ファンCがアイドルBからALHTを購入）
  3. ALHT移転：ファンD -> ファンC -> 事務所A（ファンDがファンCからALHTを購入）

ワークフローに設定された各ユーザが、ワークフローに従い順番に承認し、全承認が完了するとALHT取引が成立します。 各承認処理ではALH個別署名がALHTに付与されます。そしてワークフローの全承認が完了すると、そのワークフロー中に付与された全てのALH個別署名を集約することでALH集約署名が付与されます。

また、ALHTの検証は、ALHT取引開始前など任意のタイミングで可能です。 ALHTのコンテンツデータやALHTのメタデータの真正性を保証するASiC-E署名によって、ALHTの非改ざん性を保証し、さらに、ALHTに埋め込まれた過去のワークフローの真正性を保証するALH集約署名によって、過去のALHT取引履歴を保証します。

以降の説明では、アイドルBにより発行されたALHTをファンCが購入する際に、ファンCが検証によりALHTの真正性（ALHTの発行が確かにアイドルBにより行われ、事務所Aが承認したものであること）を確認してから購入に進むユースケースを説明します。

Tr3クライアントとTr3システムの責任範囲

上記のシナリオに沿ってALHT取引を行うために、Tr3クライアントは、Tr3システムのAPIを呼び出して、鍵生成、ALHT取引、検証の処理を実行する必要があります。 この各処理において、Tr3クライアントは、ワークフローの生成・状態管理、ALHTの管理の責任を持つ必要があります。

Tr3クライアントが持つべき機能は以下のものがあります。

  • ユーザ管理機能
    • Tr3システムではTr3クライアントとは別の独自ユーザID（tr3UserId）でユーザを識別します。
    • Fujitsu Research Portalで提供されるTr3システムでは、Fujitsu Research PortalのユーザID（APIアクセストークンのsubの値）をtr3UserIdとして扱います。
  • ワークフロー生成機能
    • Tr3クライアントは、ALHT取引の開始時に、ワークフローを生成する必要があります。
    • Tr3クライアントは、ユーザの属性・役割とALHT取引の種類に基づいて、対応するワークフローを生成します。
    • Tr3システムはtr3UserIdで構成された署名者リスト（signers）のワークフローに従って承認されたことを証明しますが、Tr3クライアントはワークフローに含まれる各承認者や承認経路の正しさに責任を持つ必要があります。
  • ワークフロー状態管理機能
    • ワークフローに従って承認を進めるためには、ワークフローのどこまで承認が進んだか管理する必要がありますが、この管理はTr3クライアントが行います。
    • この機能を実現するために、ワークフローの状態をもつテーブル（ワークフロー状態管理テーブル）で管理する例を以降で説明します。
  • ALHT権利所持者管理機能
    • ALHT権利の保有ユーザやコンテンツデータの情報管理は、Tr3クライアントが行う必要があります。
    • この機能を実現するために、権利所持者を含めたコンテンツの状態をもつテーブル（コンテンツ状態管理テーブル）で管理する例を以降で説明します。

これらの機能の詳細は、以降の説明を参照ください。（以降、コマンド例の<>で囲っている箇所は、適宜書き換えてください。）

ALHT発行

コンテンツデータをALHTとして登録したい人物（以下、コンテンツデータ登録者）が、画像などのコンテンツデータをALHTとして登録するALHT発行処理について説明します。ALHT発行処理は、最初にコンテンツデータ登録者がコンテンツデータを登録することを承認した後、コンテンツ管理者（ワークフローの最終承認者で、コンテンツデータの登録を管理する権限を持つ者）がコンテンツデータの登録を最終承認する、というワークフローに従って署名を付与することで実行します。

ワークフローに従って署名を付与するには、Tr3システムが提供する2つのAPIを実行します。

  • /workflows：ワークフローの最初の署名者が署名を付与する際に実行します。ワークフローをALHTに登録し、最初の署名者の署名をALHTに付与します。
  • /sign：ワークフローの2番目以降の署名者が署名を付与する際に実行します。署名者の署名をALHTに付与します。

ALHT発行処理では、まずコンテンツデータ登録者が署名を行う際に、Tr3クライアントはTr3システムの/workflowsに対してリクエストを送信し、次にコンテンツ管理者が署名を行う際に/signに対してリクエストを送信してください。

以下、アイドルBが画像などのコンテンツデータを登録するというシナリオに沿ってALHT発行の例を説明します。 本シナリオのシーケンス図を以下に示します。 本シナリオでは、コンテンツデータ登録者はアイドルB、コンテンツ管理者は事務所Aに対応します。

ALHT発行シナリオのシーケンス図

sequenceDiagram
    autonumber
    actor アイドルB
    actor 事務所A
    participant アプリ

    participant tr3Client as Tr3クライアント<br>（メタバースサービス）
    participant Tr3システム
    #アイドルB->>アプリ: コンテンツデータ登録（ALHT発行）ボタンを押下
    #アプリ->>Tr3クライアント: ALHT発行を依頼

    # workflow登録 & アイドルBの署名

    アイドルB->>アプリ: 画像登録（ALHT発行）を依頼
    アプリ->>tr3Client: ALHT発行を依頼
    tr3Client->>Tr3システム: ALHT発行ワークフローを作成（POST /workflows）
    Note left of Tr3システム: コンテンツデータ
    Note left of Tr3システム: 承認経路<br/>（idolB -> adminA）
    Note left of Tr3システム: idolBのtr3UserId
    Tr3システム-->>tr3Client: 署名済ASiC-Eファイルを返却<br/>
    Note right of tr3Client: ASiC-Eファイル<br/>（idolBのALH個別署名、ASiC-E署名済）

    # 事務所Aの確認・承認 & 事務所Aの署名

    tr3Client-->>アプリ: ALHT発行承認を依頼
    アプリ-->>事務所A: ALHT発行承認を依頼
    事務所A->>アプリ: ALHT発行内容を確認
    アプリ-->>事務所A: ALHT発行内容を表示
    事務所A->>アプリ: ALHT発行承認ボタンを押下
    アプリ->>tr3Client: ALHT発行承認処理を依頼
    tr3Client->>Tr3システム: adminAのALHT発行承認処理を実施（POST /sign）
    Note left of Tr3システム: ASiC-Eファイル<br/>（idolBのALH個別署名、ASiC-E署名済）
    Note left of Tr3システム: adminAのtr3UserId
    Tr3システム-->>tr3Client: 署名済ASiC-Eファイルを返却<br/>
    Note right of tr3Client: ASiC-Eファイル<br/>（idolB・adminAのALH個別署名、ASiC-E署名済）
    tr3Client-->>アプリ: ALHT発行完了を通知
    アプリ-->>アイドルB: ALHT発行完了を通知

以下、アイドルBがデータ（data.json）をコンテンツデータとして登録する例を説明します。

まず、アイドルBが準備したデータをアプリ経由でTr3クライアントにアップロードし、ALHT発行を依頼します。 Tr3クライアントはアイドルBの依頼を受け付けて、ALHT発行処理を進めるために、シナリオの概要で説明した機能を用いてワークフローの生成・状態管理とALHT権利所持者管理を行う必要があります。 これらの機能を実現するためのデータ構造の例として、ワークフローの状態を管理するワークフロー状態管理テーブルとALHT、作成者、権利取得者などを管理するコンテンツ管理テーブルを以下で説明します。

ワークフロー状態管理テーブルは、取引ID、承認経路、次に承認（署名）を行う人を示す次署名者、コンテンツデータに対する一意なIDであるコンテンツIDを管理します。承認経路は、ワークフロー生成機能によって生成してください。シナリオの例では、アイドルBがALHTの発行を要求しているため、アイドルB -> 管理者A（idolB -> adminA）のワークフロー（承認経路）が生成されます。

ワークフロー状態管理テーブル

取引ID 承認経路 次署名者 コンテンツID
1 idolB -> adminA idolB 0

コンテンツ管理テーブルは、コンテンツID、アイテムのファイル名、アイテムをBase64エンコードした文字列を示すデータ、アイテムを登録した作成者、ALHTの権利の取得者を示す権利取得者を管理します。

コンテンツ管理テーブル

コンテンツID ファイル名 　　 データ 　　　 作成者 権利取得者
0 data.json <data.jsonをBase64エンコードした文字列> 　 idolB idolB

ここで、Base64エンコードした文字列は、例えば以下のコマンドで得られる文字列です。

$ base64 data.json

Tr3クライアントは、アイドルBからALHT発行の要求を受け付けると、ワークフローを登録しアイドルBの署名を付与するために、Tr3システムの/workflowsにPOSTリクエストを送信します。curlコマンドによるPOSTリクエスト実行例を以下に示します。

$ curl -X 'POST' \
  'https://apigateway.research.global.fujitsu.com/tr3/workflows' \
  -H 'accept: application/json' \
  -H 'Authorization: Bearer <ACCESS_TOKEN>'\
  -H 'Content-Type: application/json' \
  -d '
{
  "addedFiles": [
    {
      "name": "data.json",
      "data": "<data.jsonをBase64エンコードした文字列>"
    }
  ],
  "signers": [
    "<idolBのtr3UserId>",
    "<adminAのtr3UserId>"
  ]
}'

Tr3システムは、/workflowsへのPOSTリクエストを受信すると、addedFilesに指定されたコンテンツデータを格納するALHTを生成します。さらに、ALHTにsignersに基づくワークフローを登録し、POSTされたtr3UserId（ワークフローの最初の署名者）が、確かにアイドルBのtr3UserIdであることを確認します。確認した結果が正しければ、ALHTに対してアイドルBのALH個別署名とASiC-E署名を付与します。

Tr3システムは、生成したALHTを以下のレスポンス形式でTr3クライアントに返却します。以下、ここで返却されたALHTをALHT1と呼びます。

{
  "files": [
    {
      "name": "<ALHT1のファイル名>",
      "data": "<ALHT1をBase64エンコードした文字列>"
    }
  ]
}

nameにはALHT1のファイル名が返却されます。ALHTのファイル名には、ALHTに登録されたワークフローに対して一意の名前が付与されます。dataにはALHT1をBase64エンコードした文字列が返却されます。ALHT1はASiC-E形式のファイルです。

Tr3クライアントは、Tr3システムからALHT1を取得すると、事務所Aの署名処理に進んでください。ワークフロー状態管理テーブルの次署名者を事務所A（adminA）に更新してください。

ワークフロー状態管理テーブル

取引ID 承認経路 次署名者 コンテンツID
1 idolB -> adminA adminA 0

また、コンテンツ管理テーブルのファイル名、データをTr3システムから返却されたALHT1の値に更新してください。

コンテンツ管理テーブル

コンテンツID ファイル名 データ 作成者 権利取得者
0 <ALHT1のファイル名> <ALHT1をBase64エンコードした文字列> idolB idolB

次に、Tr3クライアントは、アイドルBがコンテンツデータを登録してALHT発行のワークフローを開始したことを、事務所Aに通知してください。事務所Aは、登録されたコンテンツデータに問題なければ、ALHT発行の承認を行います。

Tr3クライアントは事務所Aの承認リクエストを受け付けて、Tr3システムに事務所Aの署名を依頼します。つまり、Tr3クライアントは、Tr3システムの/signに対してPOSTリクエストを送信してください。curlコマンドによるPOSTリクエスト実行例を以下に示します。

$ curl -X 'POST' \
  'https://apigateway.research.global.fujitsu.com/tr3/sign' \
  -H 'accept: application/json' \
  -H 'Authorization: Bearer <ACCESS_TOKEN>'\
  -H 'Content-Type: application/json' \
  -d '
{
  "asiceFile": {
    "name": "<ALHT1のファイル名>",
    "data": "<ALHT1をBase64エンコードした文字列>"
  }
}'

Tr3システムは、/signへのPOSTリクエストを受け付けると、POSTされたtr3UserId（ワークフローの次の署名者）が、正しく事務所Aのtr3UserIdになっていることを確認します。確認した結果が正しければ、POSTされたALHT1に対して事務所AのALH個別署名を付与します。このPOSTリクエストは、ワークフローの最終承認者の署名依頼であるため、さらにALH集約署名を付与し、最後にASiC-E署名を追加します。

Tr3システムは、生成したALHTを以下のレスポンス形式でTr3クライアントに返却します。以下、ここで返却されたALHTをALHT2と呼びます。

{
   "files": [
     {
       "name": "<ALHT2のファイル名>",
       "data": "<ALHT2をBase64エンコードした文字列>"
     }
   ]
 }

Tr3クライアントはALHT2を取得すると、ALHT発行のワークフロー完了を示すために、ワークフロー状態管理テーブル の次署名者をNoneに変更してください。

ワークフロー状態管理テーブル

取引ID 承認経路 次署名者 コンテンツID
1 idolB -> adminA None 0

また、コンテンツ管理テーブルのファイル名とデータをALHT2の情報に更新してください。

コンテンツ管理テーブル

コンテンツID ファイル名 データ 作成者 権利取得者
0 <ALHT2のファイル名> <ALHT2をBase64エンコードした文字列> idolB idolB

各テーブルを更新した後、Tr3クライアントはALHTの発行が完了したことをアイドルBに通知してください。アイドルBはALHT発行完了通知を受信した後に、アプリでTr3クライアントにアクセスすることで、コンテンツデータが登録され、ALHTとして発行されたことを確認できます。

以上でALHT発行処理が完了します。

ALHT移転

Tr3システムから発行されたALHTの権利を取得した権利取得者が、他者にALHTの権利を移転する処理について説明します。ALHT移転処理はALHT発行処理と同様に、ALHT取引に関連する関係者がワークフローに従って順に署名を付与することで実施します。ALHT移転処理では、まず、ALHTの権利を取得したい人物（以下、コンテンツ希望者）が承認し、次にALHTの権利を譲渡したい人物（以下、コンテンツ譲渡者）が承認、最後にコンテンツ管理者が承認するというワークフローになります。

ALHT移転処理は、Tr3システムが提供するワークフローAPI（/workflows）と署名API（/sign）に対してリクエストを送信することで実行できます。まず、コンテンツ希望者が署名を行う際に、Tr3クライアントはTr3システムの/workflowsに対してリクエストを送信し、次に、コンテンツ譲渡者とコンテンツ管理者が順に署名を行う際は、/signに対してリクエストを送信してください。

以下、事務所A（コンテンツ管理者）が管理するアイドルB（コンテンツ譲渡者）のALHTを、アイドルBからファンC（コンテンツ希望者）に売却すると同時に、その権利を移転するシナリオに沿ってALHT移転の例を説明します。移転シナリオのシーケンス図を以下に示します。

移転シナリオのシーケンス図

sequenceDiagram
    autonumber
    actor ファンC
    actor アイドルB
    actor 事務所A
    participant アプリ
    participant tr3Client as Tr3クライアント<br>（メタバースサービス）
    participant Tr3システム

    # workflow登録 & ファンCの署名

    ファンC->>アプリ: ALHT購入を要求
    アプリ->>tr3Client: ALHT購入を依頼
    tr3Client->>Tr3システム: ALHT移転ワークフローを作成（POST /workflows）
    Note left of Tr3システム: ASiC-Eファイル
    Note left of Tr3システム: 承認経路<br/>（fanC -> idolB -> adminA）
    Note left of Tr3システム: fanCのtr3UserId
    Tr3システム-->>tr3Client: 署名済ASiC-Eファイルを返却<br/>
    Note right of tr3Client: ASiC-Eファイル<br/>（fanCのALH個別署名、ASiC-E署名済）

    # アイドルBの確認・承認 & アイドルBの署名

    tr3Client-->>アプリ: ALHT移転承認を依頼
    アプリ-->>アイドルB: ALHT移転承認を依頼
    アイドルB->>アプリ: ALHT移転内容を確認
    アプリ-->>アイドルB: 移転希望のALHTや移転条件を表示
    アイドルB->>アプリ: ALHT移転承認ボタンを押下
    アプリ->>tr3Client: ALHT移転承認処理を依頼
    tr3Client->>Tr3システム: idolBのALHT移転承認処理を実施（POST /sign）
    Note left of Tr3システム: ASiC-Eファイル<br/>（fanCのALH個別署名、ASiC-E署名済）
    Note left of Tr3システム: idolBのtr3UserId
    Tr3システム-->>tr3Client: 署名済ASiC-Eファイルを返却<br/>
    Note right of tr3Client: ASiC-Eファイル<br/>（fanC・idolBのALH個別署名、ASiC-E署名済）

    # 事務所Aの確認 & 事務所Aの署名 & ALH集約署名

    tr3Client-->>アプリ: ALHT移転承認を依頼
    アプリ-->>事務所A: ALHT移転承認を依頼
    事務所A->>アプリ: ALHT移転内容を確認
    アプリ-->>事務所A: 移転希望のALHTや移転条件を表示
    事務所A->>アプリ: ALHT移転承認ボタンを押下
    アプリ->>tr3Client: ALHT承認処理を依頼
    tr3Client->>Tr3システム: 事務所AのALHT移転承認処理を実施（POST /sign）
    Note left of Tr3システム: ASiC-Eファイル<br/>（ファンC・アイドルBのALH個別署名、ASiC-E署名済）
    Note left of Tr3システム: 事務所Aのtr3UserId
    Tr3システム-->>tr3Client: 署名済ASiC-Eファイルを返却<br/>
    Note right of tr3Client: ASiC-Eファイル<br/>（ファンC・アイドルB・事務所AのALH個別署名、<br/>ALH集約署名、ASiC-E署名済）
    tr3Client-->>アプリ: ALHT移転完了を通知
    アプリ-->>ファンC: ALHT移転完了を通知

事前に、アイドルBは自身が権利を所有するALHTの売却を希望する旨をTr3クライアント上で公表します。当該ALHTの購入を希望するファンCは、アプリ画面からALHT購入を要求します。Tr3クライアントは、ファンCからのALHT購入要求を受け付けると、ALHT移転処理のためのワークフローをワークフロー生成機能によって生成してください。シナリオの例では、ファンCがアイドルBに対してALHT移転を依頼しているため、ファンC -> アイドルB -> 事務所A（fanC -> idolB -> adminA）というワークフロー（承認経路）を生成します。

次にワークフロー状態管理テーブルを更新してください。取引IDとして新しいID2を設定し、承認経路を（fanC -> idolB -> adminA）、次署名者をファンC（fanC）、コンテンツIDに当該ALHTのコンテンツID0を登録します。

ワークフロー状態管理テーブル（移転処理開始時点）

取引ID 承認経路 次署名者 コンテンツID
2 fanC -> idolB -> adminA fanC 0

ワークフロー状態管理テーブルを更新後、Tr3クライアントはTr3システムの/workflowsに対してPOSTリクエストを送信してください。curlコマンドによるPOSTリクエスト実施例を以下に示します。

$ curl -X 'POST' \
  'https://apigateway.research.global.fujitsu.com/tr3/workflows' \
  -H 'accept: application/json' \
  -H 'Authorization: Bearer <ACCESS_TOKEN>'\
  -H 'Content-Type: application/json' \
  -d '
{
  "asiceFile": {
    "name": "<ALHT2のファイル名>",
    "data": "<ALHT2をBase64エンコードした文字列>"
  },
  "signers": [
    "<fanCのtr3UserId>",
    "<idolBのtr3UserId>",
    "<adminAのtr3UserId>"
  ]
}'

Tr3システムは/workflowsへのPOSTリクエストを受信すると、asiceFileで移転処理を行うALHT（ALHT発行で生成されたALHT2）を受け取ります。そして、ALHT2に、signersに基づくワークフローを登録し、ファンCのALH個別署名とASiC-E署名を付与します。

Tr3システムは、署名済みALHTを以下のレスポンス形式でTr3クライアントに返却します。以下、ここで返却されたALHTをALHT3と呼びます。

{
  "files": [
    {
      "name": "<ALHT3のファイル名>",
      "data": "<ALHT3をBase64エンコードした文字列>"
    }
  ]
}

Tr3クライアントがALHT3を取得すると、ワークフロー状態管理テーブルの次署名者の値を次の承認経路のユーザであるアイドルB（idolB）に更新してください。

ワークフロー状態管理テーブル（ファンC署名完了時点）

取引ID 承認経路 次署名者 コンテンツID
2 fanC->idolB->adminA idolB 0

また、コンテンツ管理テーブルのファイル名とデータをALHT3の情報に更新してください。

コンテンツ管理テーブル（ファンC署名完了時点）

コンテンツID ファイル名 データ 作成者 権利取得者
0 <ALHT3のファイル名> <ALHT3をBase64エンコードした文字列> idolB idolB

各テーブルを更新後、Tr3クライアントはALHT移転の承認依頼をアイドルBに通知してください。アイドルBは、ALHTの移転を許可する場合はALHT移転の承認を行います。

Tr3クライアントはアイドルBの承認リクエストを受け取った後、Tr3システムの/signに対してPOSTリクエストを送信してください。curlコマンドによるPOSTリクエスト実施例を以下に示します。

$ curl -X 'POST' \
  'https://apigateway.research.global.fujitsu.com/tr3/sign' \
  -H 'accept: application/json' \
  -H 'Authorization: Bearer <ACCESS_TOKEN>'\
  -H 'Content-Type: application/json' \
  -d '
{
  "asiceFile": {
    "name": "<ALHT3のファイル名>",
    "data": "<ALHT3をBase64エンコードした文字列>"
  }
}'

Tr3システムは、POSTされたtr3UserId（ワークフローの次の署名者）が正しくアイドルBのtr3UserIdになっていることを確認します。確認した結果が正しければ、POSTされたALHT3に対してアイドルBのALH個別署名とASiC-E署名を付与します。

Tr3システムは、署名付与したALHTを以下のレスポンス形式でTr3クライアントに返却します。以下、ここで返却されたALHTをALHT4と呼びます。

{
  "files": [
    {
      "name": "<ALHT4のファイル名>",
      "data": "<ALHT4をBase64エンコードした文字列>"
    }
  ]
}

Tr3クライアントはALHT4を取得後、各テーブルを更新してください。

ワークフロー状態管理テーブルの次署名者をadminAに更新します。

ワークフロー状態管理テーブル（アイドルB署名完了時点）

取引ID 承認経路 次署名者 コンテンツID
2 fanC -> idolB-> adminA adminA 0

コンテンツ管理テーブル（テーブル例）のファイル名、データをALHT4の情報に更新します。

コンテンツ管理テーブル（アイドルB署名完了時点）

コンテンツID ファイル名 データ 作成者 権利取得者
0 <ALHT4のファイル名> <ALHT4をBase64エンコードした文字列> idolB idolB

各テーブルを更新後、Tr3クライアントはALHT移転の承認依頼を事務所Aに通知してください。事務所Aは確認後、ALHT移転の承認を行います。Tr3クライアントは、事務所Aの承認リクエストを受け取った後、Tr3システムの/signに対してPOSTリクエストを送信してください。curlコマンドによるPOSTリクエスト実施例を以下に示します。

$ curl -X 'POST' \
  'https://apigateway.research.global.fujitsu.com/tr3/sign' \
  -H 'accept: application/json' \
  -H 'Authorization: Bearer <ACCESS_TOKEN>'\
  -H 'Content-Type: application/json' \
  -d '
{
  "asiceFile": {
    "name": "<ALHT4のファイル名>",
    "data": "<ALHT4をBase64エンコードした文字列>"
  }
}'

Tr3システムは、POSTされたtr3UserId（ワークフローの最後の承認者）が、正しく事務所Aのtr3UserIdになっていることを確認します。確認した結果が正しければ、POSTされたALHT4に事務所AのALH個別署名を付与します。さらに、ワークフローの最終承認者の依頼であるためALH集約署名を付与し、最後にASiC-E署名を追加します。

Tr3システムは、署名完了したALHTを以下のレスポンス形式でTr3クライアントに返却します。以下、ここで返却されたALHTをALHT5と呼びます。

{
  "files": [
    {
      "name": "<ALHT5のファイル名>",
      "data": "<ALHT5のBase64エンコードした文字列>"
    }
  ]
}

Tr3クライアントはALHT5を受信した後、各テーブルを更新してください。

ワークフロー状態管理テーブルでは、ALHT移転のワークフロー完了を示すために、次署名者をNoneに更新します。

ワークフロー状態管理テーブル（事務所A署名完了時点）

取引ID 承認経路 次署名者 コンテンツID
2 fanC -> idolB -> adminA None 0

コンテンツ管理テーブルのファイル名とデータをALHT5の情報に更新し、ファンCが権利取得者になったことを示すため、権利取得者をfanCに更新します。

コンテンツ管理テーブル（事務所A署名完了時点）

itemID ファイル名 データ 作成者 権利取得者
0 <ALHT5のファイル名> <ALHT5をBase64エンコードした文字列> idolB fanC

Tr3クライアントは各テーブルを更新後、ファンCにALHT移転完了を通知してください。

以上で、移転処理は完了です。

検証

検証では、ALHTに埋め込まれた各署名者の署名とその生成順序の真正性、原本としての非改ざん性を確認することが可能です。 発行されたALHTの購入希望者が取引前にそのALHTの取引履歴を検証することで、ALHTの発行者や発行・移転に関わるワークフローが適切であるかを確認することができます。

ALHTを検証するには、Tr3システムの/verifyに対してPOSTリクエストを送信します。リクエストの際、nameとdataの2つのパラメータの値を指定する必要があります。

  • name: 対象ALHTのASiC-Eファイル名
  • data: 対象ALHTのASiC-EファイルのデータをBase64エンコードした文字列

/verifyでは、modeにより検証範囲を選択できます。検証範囲にはlatestとall、tr3onlyの3種類があり、デフォルト（mode未指定の場合）はlatestになります。

  • latest: ASiC-Eファイルの真正性と直近のワークフローの真正性を検証
  • all: ASiC-Eファイルの真正性と過去のすべてのワークフローの真正性を検証
  • tr3only: ASiC-Eファイルの真正性とワークフローの数を検証

latest, allはワークフローが完了していないASiC-Eファイルに対しては検証できませんが、tr3onlyではワークフローが完了していないASiC-Eファイルに対しても検証可能です。

/verifyへのPOSTリクエストのレスポンスとして、ASiC-E検証結果およびALH署名検証結果の真偽が返却されます。結果の真偽は、ASiC-EとALH署名の両方の検証結果がtrueの場合はtrue、それ以外の場合はfalseとなります。

以下では、シナリオに沿って署名検証の例を記載します。

ファンCがALHTを購入する際に、そのALHTがアイドルBと事務所Aがワークフローに含まれた正しいワークフローによって発行されたALHTであるかを検証します。Tr3クライアントは、そのALHTを含めてTr3システムの/verifyに対してPOSTリクエストを送信してください。

この例では、最新の取引の検証をするためにmodeとしてlatestを選択してします。curlコマンドによるPOSTリクエスト実行例を以下に示します。

$ curl -X 'POST' \
  'https://apigateway.research.global.fujitsu.com/tr3/verify?mode=latest' \
  -H 'accept: application/json' \
  -H 'Authorization: Bearer <ACCESS_TOKEN>'\
  -H 'Content-Type: application/json' \
  -d '
{
  "name": "<ASiC-Eファイルのファイル名>",
  "data": "<ASiC-EファイルをBase64エンコードした文字列>"
}'

検証結果のレスポンスの例は以下の通りです。

{
  "result": true,
  "currentFlowId": "cedc4233-3e31-4864-b4f7-24f16d77f868",
  "currentIndex": 1,
  "nextFlowId": "ca8890ff-7362-4442-abba-203f22a96ec0",
  "asice": {
    "result": true,
    "message": "ASiC-E verification succeeded"
  },
  "signature": {
    "result": true,
    "details": [
      {
        "uri": "META-INF/ALH1",
        "result": true,
        "message": "ALH verification succeeded"
      }
    ]
  },
  "process": [
    {
      "uri": "META-INF/ALH1/audit1.json",
      "signer": "<adminAのtr3UserId>",
      "signingTime": "2022-09-02T15:40:03Z"
    },
    {
      "uri": "META-INF/ALH1/audit2.json",
      "signer": "<idleBのtr3UserId>",
      "signingTime": "2022-09-02T16:30:57Z"
    }
  ]
}

上記の検証結果における、それぞれのフィールドの値が表している内容は以下の通りです。

  • result: ASiC-E署名とALH集約署名が正当なものであればtrueとなり、ASiC-Eファイルに含まれる署名者情報や履歴情報が改ざんされていないことを表す
  • asice.result: ASiC-E署名の検証結果が正当なものであればtrue
  • signature.result: ALH集約署名が正当なものであればtrue
  • process[].signer: 署名者のtr3UserIdで、Tr3クライアントのユーザ管理機能により、Tr3クライアントは署名者の情報をユーザに提供できる
  • process[].signingTime: 署名処理が行われた時刻

上記より、このALHTの以下の内容が検証できます。

  • ワークフローの署名順序が管理者A -> アイドルBとなっており、ワークフローに沿って正しくALH署名が付与されていること
  • ALH署名やコンテンツデータの改ざんがないこと

以下は、ASiC-Eの検証結果がfalseの場合のレスポンス例です。

{
  "result": false,
  "asice": {
    "result": false,
    "message": "ASiC-E verification failed"
  },
  "currentFlowId": null,
  "currentIndex": null,
  "nextFlowId": null
}

上記では、ASiC-Eファイルの検証結果がfalseであり、ASiC-Eファイルに含まれるコンテンツデータの改ざんや、ALH署名の改ざんによりワークフローの署名情報の真正性が疑われるALHTであることが分かります。

以下は、ASiC-Eの検証結果がtrue、ALH署名の検証結果がfalseの場合のレスポンス例です。

{
  "result": false,
  "currentFlowId": "cedc4233-3e31-4864-b4f7-24f16d77f868",
  "currentIndex": 1,
  "nextFlowId": "ca8890ff-7362-4442-abba-203f22a96ec0",
  "asice": {
    "result": true,
    "message": "ASiC-E verification succeeded"
  },
  "signature": {
    "result": false,
    "details": [
      {
        "uri": "META-INF/ALH1",
        "result": false,
        "message": "ALH verification failed"
      }
    ]
  }
}

上記では、ALHT発行時のワークフローのALH署名（ALH1）の検証がfalseとなり、ワークフローのどこかで不正な署名が行われたALHTであることが分かります。

ダブルスペンディング防止

同一のASiC-Eファイルに対して、ワークフローが複数回実行されてしまうという問題を、ダブルスペンディングと言います。ALHT権利取得者が、あるユーザへの権利移転に同意する署名を付与し、同時に、同じALHTを別のユーザへ権利移転することに同意する署名を付与すると、1つのALHTに対して同時に複数の権利取得者が存在してしまいます。

それを防ぐため、Tr3システムは、1つのALHTに対して同時に複数のワークフローを開始することを防止するダブルスペンディング防止機能を備えています。以下に、Tr3システムのダブルスペンディング防止機能を確認するシナリオを記載します。

ダブルスペンディング防止シナリオ

ファンD（fanD）がファンC（fanC）からALHTを購入しようとし、直後にファンE（fanE）がファンCから同じALHTを購入しようとしたとします。はじめに、ファンCが権利取得済みのASiC-Eファイル（ALHT5）を用いて、ファンD -> ファンC -> 事務所Aというワークフローを登録しておきます。次に、同じALHT5を用いて、ファンE -> ファンC -> 事務所Aというワークフローを以下のように登録します。

$ curl -X 'POST' \
  'https://apigateway.research.global.fujitsu.com/tr3/workflows' \
  -H 'accept: application/json' \
  -H 'Authorization: Bearer <ACCESS_TOKEN>'\
  -H 'Content-Type: application/json' \
  -d '
{
  "asiceFile": {
    "name": "<ALHT5のファイル名>",
    "data": "<ALHT5をBase64エンコードした文字列>"
  },
  "signers": [
    "<fanEのtr3UserId>",
    "<fanCのtr3UserId>",
    "<adminAのtr3UserId>"
  ]
}'

同一のASiC-Eファイルに対して複数のワークフロー登録がリクエストされたため、以下のようなエラーが返答されます。すでに同一のASiC-Eファイルがワークフロー登録されていることがわかり、ダブルスペンディング防止が機能していることが確認できます。

{
  "code": "ctrl-03-002",
  "message": "ASiC-E file is already signed by another signer"
}

技術のお試し

API(v2)のお試しはこちら

API(v3)のお試しはこちら