Protocol
Overview
This protocol defines the logging function within ODS-RAM.
Based on three categories—communication logs, service logs, and processing logs, the logging function aims to enable comprehensive recording and analysis of the system’s communication status, processing results of individual services, and overall monitoring and operational conditions. Each log category is designed and operated according to different retention requirements, security requirements, and intended purposes.
Abstract Normative Specification
The logging function SHALL consistently provide the capability to record events that occur within the components of Open Dataspaces and that require recording, by attaching 5W1H information based on the requirements of each event.
When recording logs, mechanisms SHOULD be incorporated to appropriately protect information. In particular, for highly confidential information, mechanisms SHOULD be provided to implement measures such as tamper prevention.
Access to logs SHOULD be provided through standardized interfaces to ensure consistent access methods.
Concepts and Roles
In this protocol, the logging function classifies roles into System Administrator, Security Administrator, Developer, and Auditor, and classifies logs into communication logs, processing logs, and service logs. For each category, roles and target information are defined to provide guidelines that address diverse system operation and monitoring needs.
The following concepts are required for this protocol:
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.
Logs are classified into the following three categories:
Communication Log: Records messages (e.g., requests and responses) passing through the ODS and header information. The purpose is to monitor traffic and connection status and to detect anomalies.
Processing Log: Through real-time dashboards and operational monitoring tools, aims to monitor and improve operations by tracking the overall processing status of the system, error conditions, resource utilization, and related information.
Service Log: Records the processing results of individual integrated services or APIs. Service logs may include user processing details or confidential information, and appropriate protection may be required for certain information.
The expected use of each log is as follows：
Communication Log
Monitoring traffic and connection status
Checking abnormal communications
Troubleshooting
Verifying records for regulatory compliance
Processing Log
Monitoring overall system processing status
Error detection and countermeasures
Performance analysis
Verifying compliance with internal operational rules
Service Log
Understanding operational status of integrated services
Confirming appropriate protection of confidential information
Analyzing processing results of APIs and services
Confirming evidence of processing activities
Scope
The logging function covers the following information for each category. Communication logs and service logs may contain users’ personal information or processing details and therefore may require appropriate protection.
Communication Information Processed by the ODS System (Communication Logs):
Requests and responses of messages passing through the ODS.
In addition to message bodies, metadata (e.g., HTTP methods, HTTP headers, status codes).
Operational Information within the ODS System (Processing Logs):
Overall system status and the results of each processing operation.
As specific information varies depending on the requirements and form of the target system, information SHALL be selected in consideration of system availability and operability.
Each piece of information SHALL be recorded in a format that enables aggregated monitoring.
Information of Services Integrated with ODS (Service Logs):
Information related to various functions and processing results of each integrated service.
As services may include highly confidential information, appropriate protection is required.
Normative Requirements
Common
All types of logs SHALL be recorded in a standard format (e.g., JSON, XML, CSV).
All types of logs SHALL include chronological information related to the originating event.
Highly confidential information contained in logs SHOULD be processed appropriately at the time of recording, such as through anonymization, according to service requirements.
Among logs, those whose reliability is directly related to service quality SHOULD be subject to tamper prevention measures. Examples of tamper prevention approaches include detection (e.g., hashing or digital signatures) and persistence (e.g., immutable storage or WORM (Write Once Read Many) media).
Log retention periods SHOULD be determined based on system requirements. This period may be constrained by audit or traceability requirements.
All types of logs MAY be stored in either centralized or distributed storage systems or databases, provided that consistent access mechanisms are ensured.
Log rotation mechanisms MAY be implemented to prevent excessive growth of log storage capacity by deleting past logs.
Communication Logs
Communication logs SHOULD include the following key metadata:
Timestamp
Client IP address
Request address
Access method (e.g., HTTP GET, POST)
Status code (e.g., HTTP 200 OK)
Request/response headers (excluding confidential information)
Identifier for communication log tracing (e.g., X-TrackingID)
Processing Logs
Processing logs SHOULD include the following:
Resource utilization status (CPU, memory, disk capacity, etc.)
Type and content of errors that occurred
Mechanisms to integrate processing logs with external services SHOULD be provided.
Service Logs
Service logs SHOULD include the following:
Processing results of each service (success/failure)
Service identifiers for tracing each service
Last updated