This protocol is a Complementary Protocol corresponding to the DCS "Heuristic Contracting" of ODS-RAM, and is responsible for "an interface that supports the definition and agreement of terms of use and contractual conditions through third-party electronic contract applications (not including the contracts themselves)."
The "Heuristic Contracting" Protocol Specification is scheduled for public release in fiscal year 2026.
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.
The following concepts are required for this protocol:
Clearing for processes conducted within an Open Dataspaces
Payment for processes conducted within an Open Dataspaces
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.
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.
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.
The message exchange sequence when using Clearing and Payment is shown below.
This section describes the error handling used in this protocol.
CRYPTREC Cryptographic List:
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.
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.
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.
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.
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.
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.
This section describes a concrete communication binding (e.g., HTTPS, file transfer, WebSocket). All content in this section is non-normative and provided as an example implementation.
This protocol uses HTTPS (TLS 1.2 or higher) and communicates via RESTful HTTP request/response.
Endpoints: HTTP methods (GET, POST, PUT, DELETE) are used against specified URIs.
Data Format: Request and response bodies use JSON format.
Authentication and Authorization: OAuth 2.0-based token authentication is used.
Security Requirements: TLS 1.2 or higher is required to ensure encrypted communication.
For each field used in this binding, the following information is provided:
Field Name: Name used within this binding
Type: Data type (e.g., integer, string)
Requirement: Usage condition of the field
Since the Request and Response fields differ for each function of this protocol, refer to the .
For detailed implementations such as Sent by, Resulting state(s), Request, Response, Examples, Error lists, and API-specific field definitions, refer to the .
The purchase confirmation process is executed in accordance with the timing of log output from the Logging component.
A transaction is treated as eligible for planned billing and planned payment amounts when the data exchange status from the Data Consumer is “completed,” the data exchange status from the Data Provider is “completed,” and the data exchange log status is “successful.”
The Data Provider retrieves transaction information with a specified Data Consumer, filtered by time period and clearing/payment status.
C = Conditional
O = Optional
Request: Used in request messages
Response: Used in response messages
Description: Meaning and usage of the field
Specifies the API key issued per client application. ODS-specific field.
Authorization
String
R
✔
Specifies the access token. Example: Bearer .
Content-Type
String
R
✔
✔
Specifies the request format.
User-Agent
String
R
✔
Specifies the client user agent.
Accept-Language
String
O
✔
Specifies the client’s preferred language.
X-TrackingID
String
R
✔
✔
Specifies a unique ID used for request tracing. ODS-specific field.
Content-Security-Policy
String
R
✔
Specifies content loading and execution policies and controls allowed script and resource origins.
X-Content-Type-Options
String
R
✔
Prevents MIME-type sniffing by browsers and enforces the declared Content-Type.
Strict-Transport-Security
String
R
✔
Enforces HTTPS connections for a specified period and prevents downgrade to HTTP.
Cache-Control
String
R
✔
Specifies cache control mechanisms.
ETag
String
C
✔
Specifies a resource version identifier. Mandatory in responses to GET requests.
Last-Modified
String
C
✔
Specifies the last modified date and time of the resource. Mandatory in responses to GET requests.
Verifies whether a transaction is permitted for service usage. A transaction ID is issued when checking eligibility, and subsequent transaction information is managed using this ID.
(Reference URL)
Transaction Information
Register / Update Data Exchange Status
Registers transaction status (success/failure) from Data Consumers and Data Providers.
(Reference URL)
Transaction Information
Retrieve Payment Status
Allows a Data Provider to check the payment status associated with transaction information.
(Reference URL)
Billing / Payment
Retrieve Planned Billing Amount
Retrieves the planned billing amount for a Data Provider.
(Reference URL)
Billing / Payment
Retrieve Planned Payment Amount
Retrieves the planned payment amount for a Data Consumer.
(Reference URL)
x-payment-api-key
String
R
✔
Usage Fee Model
Register / Retrieve / Update / Delete Usage Fee Model
Performs operations related to usage fee models that define pricing information for service usage. Usage fee models are defined per Data Provider, Data Consumer, and exchange target data.
(Reference URL)
Transaction Information
Transaction Eligibility Check