Skip to content

Application of Tr3 in Content Ownership Management

Application of Tr3 in Content Ownership Management

The following sections describe how to use the Tr3 system in a content ownership management scenario in a metaverse space.

Reference Scenario Overview

An entertainment agency produces real japanese idols in a virtual reality space and operates a metaverse space for holding events and selling related goods. A japanese idol belonging to the entertainment agency issues content data (images) in his/her possession as ALHT. Assume a world where the issued ALHT is traded among the japanese idol's fans in the metaverse space. The following figure illustrates the characters (users) and system overview of this scenario.

シナリオ概要

In this scenario, a metaverse system (also referred to as a Tr3 client) that provides a metaverse space as a service, An app (Apps and web browsers installed on smartphones, PCs, VR devices, etc.) for users to access the metaverse space and Tr3 systems exist. The content data handled in the metaverse space is converted to ALHT by the Tr3 system, and ALHT is traded between fans in the metaverse space.

ALHT distribution consists of multiple ALHT transactions, such as ALHT issuance and ALHT transfer. Each ALHT transaction has a predefined workflow. The ALHT transaction is completed when the user approves in order according to the workflow and all approvals are completed.

In this scenario, Entertainment Agency A, Japanese Idol B, Fan C, and Fan D appear as users. Each user has the following roles:

User Role Description
Entertainment Agency A The operator of the metaverse space and the final approver of the workflow.
Japanese Idol B Japanese Idol B belong to Entertainment Agency A. Japanese Idol B uploads its copyrighted data available in the metaverse space operated by Entertainment Agency Aand issues an ALHT defining the licensing terms for the data.
Fan C, Fan D Fans are free to trade within the licenses defined in their ALHT. For example, one fan can resell the ALHT ownership to another.

Examples of specific workflows for this scenario (not exhaustive) include:

  1. ALHT issued: Idle B -> Entertainment Agency A (Idle B issues ALHT)
  2. ALHT Transfer: Fan C -> Japanese Idle B -> Entertainment Agency A (Fan C purchases ALHT from Japanese Idle B)
  3. ALHT Transfer: Fan D -> Fan C -> Entertainment Agency A (Fan D purchases ALHT from Fan C)

Each user configured in the workflow sequentially approves according to the workflow, and the ALHT transaction is completed when all approvals are completed. Each approval process grants an ALH individual signature to ALHT. When all approvals of the workflow are completed, the ALH aggregation signature is granted by aggregating all ALH individual signatures granted in the workflow.

In addition, ALHT can be verified at any time, such as before the start of ALHT transactions. The ASiC-E signature ensures the authenticity of ALHT content data and ALHT metadata, while the ALH aggregate signature ensures the authenticity of ALHT's embedded past workflow, ensuring historical ALHT transaction history.

The following discussion describes the use cases in which Fan C verifies the authenticity (The issuance of the ALHT was indeed done by Japanese Idle B and approved by Entertainment Agency A.) of the ALHT when it purchases the ALHT issued by Japanese Idle B before proceeding with the purchase.

Responsibilities of the Tr3 client and the Tr3 system

In order to perform ALHT transactions in the scenario described above, the Tr3 client must call the API of the Tr3 system to perform key generation, ALHT transactions, and ALHT verification processing. For each of these operations, the Tr3 client must be responsible for workflow generation, workflow state management, and ALHT management.

The Tr3 client should have the following features:

  • User management features
    • The Tr3 system identifies the user with a unique user ID (tr3UserId) that is separate from the Tr3 client.
    • The Tr3 system provided with the Fujitsu Research Portal treats Fujitsu Research Portal user IDs (the sub value of the API access token) as tr3UserId.
  • Workflow Generator
    • The Tr3 client must generate a workflow when initiating an ALHT transaction.
    • The Tr3 client generates the corresponding workflow based on the user's attributes and roles and the type of ALHT transaction.
    • The Tr3 system proves that it was approved according to the workflow in the signers list (signers) consisting of tr3UserId, but the Tr3 client must be responsible for the correctness of each approver and approval path included in the workflow.
  • Workflow State Management
    • In order to proceed with the approval according to the workflow, it is necessary to manage how far the approval has progressed in the workflow, which is managed by the Tr3 client.
    • To achieve this functionality, the following examples show how to manage a table with workflow states (workflow state management table).
  • ALHT ownership management function
    • The Tr3 client must manage information about users with ALHT ownership and content data.
    • To achieve this functionality, the following examples illustrate how content can be managed in a table that contains the state of the content, including ownership holders.

These features are described in more detail in the following sections. (In the following command example, replace the parts enclosed by < > as appropriate.)

ALHT issuance

This section describes the ALHT issuing process in which a person who wishes to register content data as ALHT (Content data registrants) registers content data such as images as ALHT. The ALHT issuing process is performed by first approving the registration of content data by the content data registrant, and then assigning the signature according to the workflow in which the content administrator (Final approver of the workflow, who has permission to manage content data registrations) finally approves the registration of the content data.

To grant a signature according to a workflow, you run two APIs provided by the Tr3 system.

  • /workflows: The API that the first signer of the workflow calls to sign. Register the workflow with ALHT and give ALHT the signature of the first signer.
  • /sign: The API that the second and subsequent signers of the workflow call to sign. Attaches the signer's signature to ALHT.

In the ALHT issuing process, the Tr3 client must first send a request to /workflows on the Tr3 system when the content data registrant signs, and then send a request to/sign when the content administrator signs.

In the following, an example of ALHT issuing will be described based on a scenario in which Japanese Idle B registers content data such as images. The sequence diagram for this scenario is shown below. In this scenario, the content data registrant corresponds to Japanees Idle B and the content administrator corresponds to Entertainment Agency A.

Sequence diagram of the ALHT issuance scenario

sequenceDiagram
    autonumber
    actor Japanese Idle B
    actor Entertainment Agency A
    participant Apps

    participant tr3Client as Tr3 Client<br>（Metaverse service）
    participant Tr3 System
    #Japanese Idle B->>Apps: Content data登録（ALHT発行）ボタンを押下
    #Apps->>Tr3 Client: ALHT発行を依頼

    # workflow登録 & Japanese Idle Bの署名

    Japanese Idle B->>Apps: Request image registration (issuance ALHT)
    Apps->>tr3Client: Request ALHT issuing
    tr3Client->>Tr3 System: Create ALHT issuing Workflow （POST /workflows）
    Note left of Tr3 System: Content data
    Note left of Tr3 System: Workflow<br/>（idolB -> adminA）
    Note left of Tr3 System: idolB's tr3UserId
    Tr3 System-->>tr3Client: Return signed ASiC-E file<br/>
    Note right of tr3Client: ASiC-E file<br/>（idolB' ALH Individual Signature, ASiC-E Signed）

    # Entertainment Agency Aの確認・承認 & Entertainment Agency Aの署名

    tr3Client-->>Apps: Request approval to issue ALHT
    Apps-->>Entertainment Agency A: Request approval to issue ALHT
    Entertainment Agency A->>Apps: Request ALHT Issue Request Details
    Apps-->>Entertainment Agency A: Return ALHT Issue Request Details
    Entertainment Agency A->>Apps: Approve the issuance of ALHT
    Apps->>tr3Client: Request ALHT issuance processing
    tr3Client->>Tr3 System: Run ALHT issuing Workflow with approval from adminA（POST /sign）
    Note left of Tr3 System: ASiC-E file<br/>（idolB's ALH Individual Signature, ASiC-E Signed）
    Note left of Tr3 System: adminA's tr3UserId
    Tr3 System-->>tr3Client: Return signed ASiC-E file<br/>
    Note right of tr3Client: ASiC-E file<br/>（idolB's and adminA's ALH Individual Signature, ALH Aggregation Signature, ASiC-E Signed）
    tr3Client-->>Apps: Notification of completion of ALHT issuance
    Apps-->>Japanese Idle B: Notification of completion of ALHT issuance

The following describes an example in which the Japanese Idle B registers data (data.json) as Content data.

First, the data prepared by the Japanese Idle B is uploaded to Tr3Client via Apps, and an ALHT issue is requested. In order for Tr3 Client to receive requests from the Japanese Idle B and proceed with the ALHT issuance process, it is necessary to create a workflow, manage its status, and manage ALHT ownership holders using the features described in Scenario Overview. The following are examples of data structures that enable these features: the Workflow State Management Table, which manages workflow states, and the Content Management Table, which manages ALHT, authors, ownership recipients, and so on.

The Workflow Status Management Table manages Transaction ID, Ordered Approver List, Next Approver, which indicates who is to approve (sign), and Content ID, which is a unique ID for Content data. Use the workflow generation feature to generate Ordered Approver List. In the example scenario, the workflow (Ordered Approver List) for Japanese Idle B -> Administrator A (idolB -> adminA) is generated because Japanese Idle B requires the issuance of ALHT.

Workflow Status Management Table

transaction ID Ordered Approver List Next Approver Content ID
1 idolB -> adminA idolB 0

The Content Management Table manages Content ID, file name of the content data, data representing a Base 64 encoded string of the content data, copyright holder of the content data, and owner representing who acquired the ALHT ownership.

Content Management Table

Content ID File name 　　 Data 　　　 Copyright holder Owner
0 data.json <Base 64 encoded string of data.json> 　 idolB idolB

For example, the Base 64 encoded string of data.json can be obtained by running the following command:

$ base64 data.json

When Tr3 Client receives a request to issue ALHT from a Japanese Idle B, it sends a POST request to /workflows in Tr3 System to register the workflow and attach the signature of the Japanese Idle B. The following is an example of executing a POST request using the curl command:

$ 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": "<Base 64 encoded string of `data.json`>"
    }
  ],
  "signers": [
    "<idolB's tr3UserId>",
    "<adminA's tr3UserId>"
  ]
}'

When Tr3 System receives a POST request for /workflows, it generates an ALHT containing the Content data specified in adddedFiles. In addition, register a workflow based on signers in ALHT and verify that tr3UserId (the first signer of the workflow) posted is indeed tr3UserId from the Japanese Idle B. If the result we confirmed is correct, we will grant ALH Individual Signature and ASiC-E signature of Japanese Idle B to ALHT.

The Tr3 system returns the generated ALHT (the ALHT returned here is called ALHT1) to the Tr3 client in the following response format:

{
  "files": [
    {
      "name": "<File name of ALHT1>",
      "data": "<Base 64 encoded string of ALHT1>"
    }
  ]
}

name returns the File name of ALHT1. The ALHT File name is given a unique name for the workflow registered in ALHT. data is returned as a Base 64 encoded string of ALHT1. ALHT1 is an ASiC-E format file.

The Tr3Client takes the ALHT1 from the Tr3System and proceeds to the Entertainment Agency A signing process. Update Next Approver in the Workflow Status Management Table to Entertainment Agency A (adminA).

Workflow Status Management Table

transaction ID Ordered Approver List Next Approver Content ID
1 idolB -> adminA adminA 0

Also, update the File name, Data in the Content Management Table with the value of ALHT1 returned from the Tr3 System.

Content Management Table

Content ID File name Data Copyright holder Owner
0 <File name of ALHT1> <Base 64 encoded string of ALHT1> idolB idolB

Next, the Tr3 Client should notify the Entertainment Agency A that the Japanese Idle B has registered Content data and started the ALHT workflow. Entertainment Agency A will approve the issuance of ALHT if there is no problem with the registered Content data.

The Tr3 Client accepts an approval request from Entertainment Agency A and asks the Tr3 System to sign Entertainment Agency A. In other words, the Tr3 Client sends a POST request to /sign on the Tr3 System. The following is an example of executing a POST request using the curl command:

$ 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": "<File name of ALHT1>",
    "data": "<Base 64 encoded string of ALHT1>"
  }
}'

When Tr3 System receives a POST request to /sign, it verifies that the posted tr3UserId (the next signer of the workflow) is the correct Entertainment Agency A tr3UserId. If the result is correct, we will assign Entertainment Agency A's ALH Individual Signature to the posted ALHT1. Since this POST request is the signature request of the final approver of the workflow, add an ALH aggregate signature and add an ASiC-E signature at the end.

The Tr3 System returns the generated ALHT (the ALHT returned here is called ALHT2) to the Tr3Client in the following response format:

{
   "files": [
     {
       "name": "<File name of ALHT2>",
       "data": "<Base 64 encoded string of ALHT2>"
     }
   ]
 }

After Tr3 Client gets ALHT2, change Next Approver to None in the Workflow Status Management Table to indicate the completion of ALHT-issued workflow.

Workflow Status Management Table

transaction ID Ordered Approver List Next Approver Content ID
1 idolB -> adminA None 0

Also, update the File name and Data in the Content Management Table with the information in ALHT2.

Content Management Table

Content ID File name Data Copyright holder Owner
0 <File name of ALHT2> <Base 64 encoded string of ALHT2> idolB idolB

After updating each table, Tr3Client should notify Japanese Idle B that ALHT has been issued. After receiving an ALHT issuance completion notification, the Japanese Idle B can access Tr3Client through Apps to confirm that Content data has been registered and issued as ALHT.

This completes the ALHT issuance process.

ALHT transfer

This section describes the process in which the Owner who has taken ownership of ALHT issued by the Tr3 System transfers ownership of ALHT to another party. Similar to the ALHT issuance process, the ALHT transfer process is performed by the parties involved in the ALHT transaction who sign in order according to the workflow. In the ALHT transfer process, the workflow is as follows: first, the person who wants to take ownership of ALHT (Content Buyers) approves, then the person who wants to transfer ownership of ALHT (following content sellers) approves, and finally the content manager approves.

ALHT transfer can be handled by sending a request to the workflow API (/workflows) and signature API (/sign) provided by Tr3System. First, when the content buyer signs, the Tr3Client sends a request to /workflows on the Tr3System, and then when the content seller and the content manager sign sequentially, send a request to/sign.

In the following, we will explain an example of ALHT transfer in accordance with a scenario in which ALHT of a Japanese Idle B (content seller) managed by Entertainment Agency A (content manager) is sold from a Japanese Idle B to a fan C (content buyer) and the ownership are transferred. Shown below is the Transfer Scenario Sequence Diagram.

Transfer Scenario Sequence Diagram

sequenceDiagram
    autonumber
    actor Fan C
    actor Japanese Idle B
    actor Entertainment Agency A
    participant Apps
    participant tr3Client as Tr3 Client<br>(Metaverse service)
    participant Tr3 System

    # workflow登録 & Fan Cの署名

    Fan C->>Apps: Request ALHT Purchase
    Apps->>tr3Client: Request ALHT Purchase
    tr3Client->>Tr3 System: Create ALHT transfer workflow（POST /workflows）
    Note left of Tr3 System: ASiC-E file
    Note left of Tr3 System: Ordered Approver List<br/>（fanC -> idolB -> adminA）
    Note left of Tr3 System: fanC's tr3UserId
    Tr3 System-->>tr3Client: Return signed ASiC-E file<br/>
    Note right of tr3Client: ASiC-E file<br/>（fanC's ALH Individual Signature, ASiC-E Signed）

    # Japanese Idle Bの確認・承認 & Japanese Idle Bの署名

    tr3Client-->>Apps: Request approval to transfer ALHT
    Apps-->>Japanese Idle B: Request approval to transfer ALHT
    Japanese Idle B->>Apps: Request ALHT transfer Request Details
    Apps-->>Japanese Idle B: Return ALHT transfer Request Details
    Japanese Idle B->>Apps: Approve the transfer of ALHT
    Apps->>tr3Client: Request ALHT transfer processing
    tr3Client->>Tr3 System: Run ALHT transfer workflow with approval from idolB（POST /sign）
    Note left of Tr3 System: ASiC-E file<br/>（fanC's ALH Individual Signature, ASiC-E Signed）
    Note left of Tr3 System: idolB's tr3UserId
    Tr3 System-->>tr3Client: Return signed ASiC-E file<br/>
    Note right of tr3Client: ASiC-E file<br/>（fanC's and idolB's ALH Individual Signature, ASiC-E Signed）

    # Entertainment Agency Aの確認 & Entertainment Agency Aの署名 & ALH Aggregation Signature

    tr3Client-->>Apps: Request approval to transfer ALHT
    Apps-->>Entertainment Agency A: Request approval to transfer ALHT
    Entertainment Agency A->>Apps: Request ALHT transfer Request Details
    Apps-->>Entertainment Agency A: Return ALHT transfer Request Details
    Entertainment Agency A->>Apps: Approve the transfer of ALHT
    Apps->>tr3Client: Request ALHT transfer processing
    tr3Client->>Tr3 System: Run ALHT transfer workflow with approval from Entertainment Agency A（POST /sign）
    Note left of Tr3 System: ASiC-E file<br/>（Fan C's and Japanese Idle B's ALH Individual Signature, ASiC-E Signed）
    Note left of Tr3 System: Entertainment Agency A's tr3UserId
    Tr3 System-->>tr3Client: Return signed ASiC-E file<br/>
    Note right of tr3Client: ASiC-E file<br/>（Fan C's and Japanese Idle B's and Entertainment Agency A's ALH Individual Signature, <br/>ALH Aggregation Signature, ASiC-E Signed）
    tr3Client-->>Apps: Notify ALHT transfer complete
    Apps-->>Fan C: Notify ALHT transfer complete

In advance, the Japanese Idle B will announce on Tr3Client that it wishes to sell ALHT, which it owns. Fan C who wishes to purchase the said ALHT purchases Request ALHT from the Apps screen. When Tr3Client receives an ALHT purchase request from Fan C, use the workflow generation function to generate a workflow for ALHT transfer processing. In the example scenario, Fan C has asked the Japanese Idle B to perform the ALHT transfer, so it generates a workflow (Ordered Approver List) called Fan C -> Japanese Idle B -> Entertainment Agency A (fanC -> idolB -> adminA).

Then update the Workflow Status Management Table. Set transaction ID to a new ID2, register Ordered Approver List (fanC -> idolB -> adminA), Next Approver to Fan C (fanC), and Content ID to the Content ID 0 of the relevant ALHT.

Workflow Status Management Table (Timing of starting the ALHT transfer process)

transaction ID Ordered Approver List Next Approver Content ID
2 fanC -> idolB -> adminA fanC 0

After updating the Workflow Status Management Table, the Tr3 Client should send a POST request to /workflows on the Tr3 System. The following is an example of a POST request with the curl command:

$ 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": "<File name of ALHT2>",
    "data": "<Base 64 encoded string of ALHT2>"
  },
  "signers": [
    "<fanCのtr3UserId>",
    "<idolBのtr3UserId>",
    "<adminAのtr3UserId>"
  ]
}'

When Tr3 System receives a POST request to /workflows, it receives an ALHT (ALHT2 generated by the ALHT issue) to perform the move with asiceFile. Then, in ALHT2, register a workflow based on signers and add Fan C's ALH Individual Signature and ASiC-E signature.

The Tr3 System returns the signed ALHT (The ALHT returned here is called ALHT3.) to the Tr3 Client in the following response format:

{
  "files": [
    {
      "name": "<File name of ALHT3>",
      "data": "<Base 64 encoded string of ALHT3>"
    }
  ]
}

When Tr3Client gets ALHT3, update the value of Next Approver in the Workflow Status Management Table to the Japanese Idle B (idolB) who is a user of the next ordered approver list.

Workflow Status Management Table (Timing of signature completion by Fan C)

transaction ID Ordered Approver List Next Approver Content ID
2 fanC->idolB->adminA idolB 0

Also, update the File name and Data in the Content Management Table to the ALHT3 information.

Content Management Table (Timing of signature completion by Fan C)

Content ID File name Data Copyright holder Owner
0 <File name of ALHT3> <Base 64 encoded string of ALHT3> idolB idolB

After updating each table, Tr3 Client should notify Japanese Idle B to approve ALHT transfer. When Japanese Idle B approves the request, it runs the ALHT transfer workflow.

After Tr3 Client receives approval from the Japanese Idle B, send a POST request to /sign on the Tr3 System. The following is an example of a POST request using the curl command:

$ 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": "<File name of ALHT3>",
    "data": "<Base 64 encoded string of ALHT3>"
  }
}'

Tr3 System verifies that the posted tr3UserId (the next signer of the workflow) is correctly tr3UserId in the Japanese Idle B. If the result is correct, we will give the Japanese Idle B ALH Individual Signature and ASiC-E signature to the POSTed ALHT3.

Tr3 System returns the ALHT (The returned ALHT is called ALHT4) to Tr3 Client in the following response format.

{
  "files": [
    {
      "name": "<File name of ALHT4>",
      "data": "<Base 64 encoded string of ALHT4>"
    }
  ]
}

After Tr3Client acquires ALHT4, update each table.

Update Next Approver to adminA in the Workflow Status Management Table.

Workflow Status Management Table (Timing of signature completion by Japanese Idle B)

transaction ID Ordered Approver List Next Approver Content ID
2 fanC -> idolB-> adminA adminA 0

Update the Content Management Table File name, Data to the ALHT4 information.

Content Management Table (Timing of signature completion by Japanese Idle B)

Content ID File name Data Copyright holder Owner
0 <File name of ALHT4> <Base 64 encoded string of ALHT4> idolB idolB

After updating each table, Tr3 Client should notify Entertainment Agency A to approve ALHT transfer. When Entertainment Agency A approves the request, it runs the ALHT transfer workflow.After the Tr3 Client receives the Entertainment Agency A approval request, it sends a POST request to the Tr3 System /sign. The following is an example of a POST request using the curl command:

$ 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": "<File name of ALHT4>",
    "data": "<Base 64 encoded string of ALHT4>"
  }
}'

Tr3 System verifies that the posted tr3UserId (the last approver for the workflow) is correctly tr3UserId for Entertainment Agency A. If the result is correct, add the Entertainment Agency A ALH Individual Signature to the posted ALHT4. In addition, the ALH Aggregation Signature is given because it is the request of the final approver of the workflow, and finally the ASiC-E signature is added.

The Tr3 System returns the signed ALHT (the ALHT returned here is called ALHT5) to the Tr3 Client in the following response format.

{
  "files": [
    {
      "name": "<ALHT5のFile name>",
      "data": "<ALHT5のBase 64 encoded string>"
    }
  ]
}

After Tr3 Client receives ALHT5, update each table.

In the Workflow Status Management Table, update Next Approver to None to indicate the completion of the ALHT transfer workflow.

Workflow Status Management Table (Timing of signature completion by Entertainment Agency)

transaction ID Ordered Approver List Next Approver Content ID
2 fanC -> idolB -> adminA None 0

Update File name and Data in the Content Management Table to ALHT5 information, and update Owner to fanC to indicate that Fan C is now Owner.

Content Management Table (Timing of signature completion by Entertainment Agency)

itemID File name Data Copyright holder Owner
0 <File name of ALHT5> <Base 64 encoded string of ALHT5> idolB fanC

After Tr3Client updates each table, Notify ALHT transfer to Fan C.

This completes the transfer process.

Verification

Verification allows you to verify the authenticity of each signer's signature embedded in ALHT and the order in which it was generated, as well as the authenticity of the original. By verifying the transaction history of the issued ALHT before the transaction is made by the purchaser of the issued ALHT, it is possible to confirm whether the workflow related to the issuance and transfer of the ALHT is appropriate.

To verify ALHT, send a POST request to /verify on the Tr3System. In the request, you must specify values for two parameters, name and data.

  • name: File name of the target ALHT
  • data: Base 64 encoded string of the target ALHT

/ verify allows you to select a verification scope using mode. There are three types of Verification scopes: latest, all, and tr3only, and the default (unless mode is specified) is latest.

  • latest: Verifies the authenticity of the ASiC-E file and the authenticity of the most recent workflow
  • all: Verifies the authenticity of the ASiC-E file and all previous workflows
  • tr3only: Verifies the authenticity of ASiC-E files and the number of workflows

latest, all cannot verify an ASiC-E file that has not completed a workflow, but tr3only can verify an ASiC-E file that has not completed a workflow.

The POST request response to / verify returns the authenticity of the ASiC-EVerification and ALH signature verification results. The result is true if the Verification result for both ASiC-E and ALH signatures is true, otherwise false.

The following is an example of signature verification along the scenario.

When Fan C purchases ALHT, it verifies that the ALHT was issued by the correct workflow included in the workflow by the Japanese Idle B and Entertainment Agency A. The Tr3Client sends a POST request to / verify on the Tr3System, including its ALHT.

In this example, mode is selected as latest to verify the most recent transaction. The following is an example of executing a POST request using the curl command:

$ 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": "<File name of the target ALHT>",
  "data": "<Base 64 encoded string of the target ALHT>"
}'

An example of a response to a Verification result is shown below.

{
  "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's tr3UserId>",
      "signingTime": "2022-09-02T15:40:03Z"
    },
    {
      "uri": "META-INF/ALH1/audit2.json",
      "signer": "<idleB's tr3UserId>",
      "signingTime": "2022-09-02T16:30:57Z"
    }
  ]
}

The values in each field in the above Verification results represent the following:.

  • result: true if the ASiC-E signature and ALH Aggregation Signature are valid, indicating that the signer and history information contained in the ASiC-E file has not been tampered with.
  • asice.result: true if ASiC-E signature verification result is valid
  • signature.result: true if the ALH Aggregation Signature is legal
  • process[].signer: The signer's tr3UserId, and the user management feature of Tr3Client allows Tr3Client to provide the user with the signer's information
  • process[].signingTime: Time at which the signing occurred

From the above, the following contents of this ALHT can be verified.

  • The workflow signature order is Entertainment Agency A -> Japanese Idle B, and the ALH signature is correctly assigned according to the workflow.
  • No ALH signatures or tampering with Content data

The following is an example of a response when ASiC-E's Verification result is false.

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

In the above example, the verification result of the ASiC-E file is false, which indicates that the content data contained in the ASiC-E file has been tampered with or the ALH signature has been tampered with, and the authenticity of the workflow signature information is suspected.

The following is an example response when ASiC-E verification result is true and ALH signature verification result is 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"
      }
    ]
  }
}

In the above example, the verification of the ALH signature (ALH1) of the workflow when ALHT was issued becomes false, indicating that ALHT was incorrectly signed somewhere in the workflow.

Preventing double-spending

The problem of multiple executions of a workflow on the same ASiC-E file is called double-spending. If the ALHT Owner grants a signature agreeing to the transfer of ownership to one user and at the same time grants a signature agreeing to the transfer of ownership from the same ALHT to another user, there will be multiple owners for one ALHT at the same time.

To prevent this, the Tr3 System includes a Preventing double-spending feature that prevents multiple workflows from starting simultaneously for a single ALHT. Here is the Scenarios for Verifying the Preventing Double-spending Feature in the Tr3 System:

Preventing double-spendingシナリオ

Fan D (fanD) tries to purchase ALHT from Fan C (fanC), and Fan E (fanE) immediately tries to purchase the same ALHT from Fan C. First, register the workflow Fan D -> Fan C -> Entertainment Agency A using the ASiC-E file (ALHT5) owned by Fan C. Next, using the same ALHT5, register the workflow Fan E -> Fan C -> Entertainment Agency A as follows:

$ 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": "<File name of ALH5>",
    "data": "<Base 64 encoded string of ALHT5>"
  },
  "signers": [
    "<fanE's tr3UserId>",
    "<fanC's tr3UserId>",
    "<adminA's tr3UserId>"
  ]
}'

Since more than one workflow registration is requested for the same ASiC-E file, the following error is returned:

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

You can see that the same ASiC-E file is already registered as a workflow, and that Preventing double-spending is working.

Try the Technology

Try the Technology