Protocol

Overview

Clearing Payment provides an interface that records, reconciles, and settles/charges data transaction results through third-party electronic payment applications (not including the functionality of clearing, billing, or payment processing itself). This protocol is one of the Complementary Protocols and provides supplementary functionality necessary to realize Open Dataspaces.

This layer covers the following domains:

• Clearing

  Records transactions between Data Providers and Data Consumers in data exchanges and performs clearing processing based on usage volume and pricing models. Recorded transactions are verified as clearing targets by comparing them with transaction records of data exchanges collected through the logging function.

• Payment

  Provides information necessary for payment processing. The actual execution of payment processing is out of scope.

Abstract Normative Specification

Concepts and Roles

The following concepts are required for this protocol:

Concept	Description
Data Provider	An entity that sends data stored in a data store to a Data Consumer.
Data Consumer	An entity that receives data from a Data Provider.
Payment Service	An entity selected by the Data Provider outside this protocol to perform payment processing.

Scope

• Clearing for processes conducted within an Open Dataspaces

• Payment for processes conducted within an Open Dataspaces

Normative Requirements

Clearing

• Clearing functionality SHALL determine clearing target transactions by reconciling multiple pieces of evidence. The evidence SHALL include at least (a) evidence from Dataspace Fundamental Services (DFS), (b) provider declarations, and (c) consumer declarations.

  • Rationale: Depending on the dataspace configuration (federated or distributed), the legitimacy of clearing targets cannot be ensured using a single source of information.

• As a principle, transactions SHOULD be treated as clearing targets only when all evidence sources—(a) DFS evidence, (b) provider declarations, and (c) consumer declarations—are consistent.

  • Rationale: If inconsistencies exist among evidence sources, the clearing function must not automatically determine the clearing target.

• Information from Industry Services (IS) MAY be used as necessary.

  • Rationale: To allow flexible implementation according to business requirements.

• The state of clearing results MAY be defined and managed as necessary.

  • Rationale: To allow implementation of state management when reconciling multiple evidence sources to determine clearing targets.

• If stored data is encrypted, standard cryptographic techniques, including those recommended by CRYPTREC, MAY be referenced and adopted as necessary.

  • Rationale: To allow consideration of encryption technologies in accordance with operational requirements.

Payment

• As a principle, the payment method SHOULD be selected by the Data Consumer from among the payment methods presented by the Data Provider and agreed upon in advance.

  • Rationale: To follow general commercial practices.

• Information required for payment processing SHOULD be based on the results of clearing processing.

  • Rationale: To follow general commercial practices.

• Payment processing functions MAY utilize external payment services. When an external payment service is selected, integration methods and necessary controls with that service SHOULD, as a principle, be customized within the Clearing and Payment function.

  • Rationale: To allow flexible implementation according to business requirements and to absorb differences among payment services while ensuring consistent provision of Clearing and Payment functionality.

• If stored data is encrypted, standard cryptographic techniques, including those recommended by CRYPTREC, MAY be referenced and adopted as necessary.

  • Rationale: To allow consideration of encryption technologies in accordance with operational requirements.

Non-functional / Cross-layer Requirements

• This function is assumed to be used via Transaction（L2）.

• This function is assumed to use tokens issued by the Identity & Trust（L3）.

• Each transaction between a Data Provider and a Data Consumer in data exchange SHALL be uniquely identifiable by X-TrackingID.

Message Types

Type	Sender ⇒ Receiver	Description
Request	Client (Transaction（L2）) ⇒ Server (Clearing and Payment)	A message sent by the client to execute Clearing and Payment functions. Includes authentication information and request parameters.
Response	Server (Clearing and Payment) ⇒ Client (Transaction（L2）ｓ)	A message sent by the server in response to a request. Includes processing results and error information.

Protocol Flow

The message exchange sequence when using Clearing and Payment is shown below.

Error Handling

This section describes the error handling used in this protocol.

Error Type	Description	Handling
Invalid Request	Returned when parameters are invalid or required fields are missing.	Verify input values, correct them, and resend the request.
Token-related Error	Returned when the access token is not set or is invalid.	Reacquire and reset the access token (re-login or token refresh if necessary) and resend the request.
Insufficient Authorization	Returned when required permissions are lacking.	Notify that the operation is not permitted. Do not resend, as it will not succeed.
Resource Not Found	Returned when the specified resource does not exist.	Notify that the resource does not exist. Do not resend, as it will not succeed.
Data Inconsistency Error	Returned in cases such as duplicate data or concurrency control conflicts.	Retrieve the latest data, resolve conflicts, and resend the request.
Invalid Request Format	Returned when an unsupported request format is specified.	Set the correct Content-Type and resend the request.
System Error	Returned when an internal server error occurs.	If it occurs continuously, notify the system administrator. Whether to resend depends on the operation performed.

References

• CRYPTREC Cryptographic List: https://www.cryptrec.go.jp/list/cryptrec-ls-0001-2022r1.pdf