This protocol defines the monitoring function within ODS-RAM.
The monitoring function continuously tracks the operational status of data transactions and provides functionality for the early detection of anomalies and failures. Based on data collected and aggregated through the logging function, this function enables real-time status awareness, system visualization, and early detection of anomalies.
Abstract Normative Specification
The system SHALL provide the capability to calculate metrics from data collected by the logging function.
Rationale: To enable appropriate monitoring of various conditions.
The system SHOULD provide dashboards for the visualization of metrics.
Rationale: To improve visibility of system status and usability.
The system MAY provide functionality to notify users or intervene in the system when metrics meet user-specified conditions.
The following concepts are required for this protocol:
Concept
Description
The scope of monitoring covers each module that composes Open Dataspaces.
The primary targets of this monitoring function are as follows. As Open Dataspaces handles sensitive data, in addition to general data persistence functions, evidence and trace information are also included as monitoring targets.
Communication Status of Integrated Services and APIs: Monitors traffic volume, error rates, response times, and related metrics based on communication data passing through the system and its communication history. Also manages the number of requests, success rates, types of failures, and processing times for each integrated service or API.
System Resource Status: Monitors resources such as CPU, memory, disk capacity, and network bandwidth. If thresholds defined by the system or services are exceeded, anomalies are detected and alerts are issued. Based on collected data, periodic reports and trend forecasts may be generated to support operational improvement activities.
Security Status and Audit: Through monitoring system components such as networks and processes, as well as the behavior of individual functions, detects behavior that deviates from normal behavior from a security perspective at an early stage. Also provides functionality for audit evidence purposes.
External interfaces SHOULD be provided through APIs with consideration for integration with other operational management tools and AI-based analysis services.
The system SHOULD provide dashboards for visualizing metrics. Users MAY be allowed to customize dashboards.
When monitoring metrics and detecting anomalies, the system SHOULD notify the System Administrator. The purpose of anomaly detection includes not only monitoring service operation status but also monitoring system security status. Thresholds MAY be set for various metrics as a means of anomaly detection.
Examples of metrics include:
Service downtime
Response time and error rates in requests or service processing
System resources
Communication volume from specific IP addresses
Examples of notification methods include:
Email
Instant messaging
System integration using webhooks
When anomalies are detected, the system MAY provide functionality to automatically intervene in the system by operating system resources or processes. However, the target systems and scope of intervention MUST be defined in advance. Security policies and permission scopes configured by the System Administrator MUST be complied with. Details of interventions MUST be recorded in logs for audit purposes and MUST be traceable as response history.
Rationale: To maintain service continuity at the time of anomaly detection while minimizing unnecessary intervention and potential security risks.
Metrics MAY be stored separately from logging data. In such cases, traceability with logging information SHOULD be ensured using timestamps and trace IDs.
Rationale: To improve the efficiency of metric management while maintaining consistency with logging information, thereby enhancing data traceability and analytical accuracy.
The system MAY provide functionality to generate reports for external audits based on the collection and processing of service-specific logs.
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.
Concepts and Roles
Scope
Normative Requirements
Discovery and Search (L4)
Logging
Monitoring
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.
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:
Concept
Description
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
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.
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.
Communication logs SHOULD include the following key metadata:
Timestamp
Client IP address
Processing logs SHOULD include the following:
Resource utilization status (CPU, memory, disk capacity, etc.)
Type and content of errors that occurred
Service logs SHOULD include the following:
Processing results of each service (success/failure)
Service identifiers for tracing each service
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
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.
Identifier for communication log tracing (e.g., X-TrackingID)
Mechanisms to integrate processing logs with external services SHOULD be provided.
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.
Concepts and Roles
Scope
Normative Requirements
Common
Communication Logs
Processing Logs
Service Logs
Common Functionalities
Metadata Exchange (L4)
Binding
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.
Protocol
The Notifier provides functionality for delivering notifications containing information to be shared between data providers and consumers regarding updates and receipt status related to data transactions.
This layer covers the following domains:
Notification Destination List Management Provides functionality for managing notification destination lists required when a Data Provider notifies Data Consumers of the registration, update, or deletion of provided data.
Notification Management Provides functionality for managing notifications issued by Data Providers and for enabling Data Consumers to review notification information.
Binding
This section describes definitions when mapped to an actual communication method (e.g., HTTPS, file transfer, WebSocket). All content described below is non-normative (examples).
Communication protocol: HTTPS (TLS 1.2 or higher)
Message format: JSON-LD
Encoding: UTF-8
Data Trust Assessment (L1)
Protocol
Overview
This protocol is a Fundamental Protocol corresponding to the L1 "Data Trust Assessment" of ODS-RAM, and is responsible for "an interface that enables the assessment and calculation of data integrity and non-tamperability (not including the functionality of the assessment and calculation of integrity and non-tamperability itself)."
The "Data Trust Assessment" Protocol Specification is scheduled for public release in fiscal year 2026.
Identity and Trust (L3)
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
R = Required
C = Conditional
O = Optional
Request: Used in request messages
Response: Used in response messages
Description: Meaning and usage of the field
Field Name
Type
Required
Request
Response
Description
x-notifier-api-key
String
R
✔
Since the Request and Response fields differ for each function of this protocol, refer to the API Specification.
For detailed implementations such as Sent by, Resulting state(s), Request, Response, Examples, Error lists, and API-specific field definitions, refer to the API Specification.
Category
Function
Description
API Specification
Notification Destination List
Register / Retrieve / Update / Delete Notification Destination List
Performs operations related to notification destination lists required when a Data Provider notifies Data Consumers.
(Reference URL)
Notification Management
Concrete Specification
Prerequisites
Field Definitions
Header Field Definitions
Payload Field Definitions
Functional Description
Sequence Diagrams
Notification Destination List Create / Update / Retrieve / Delete
Notification Review and Confirmation Status Update
Data Receipt and Receipt Status Update
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.
Management of notification destination lists related to data provision within Open Dataspaces
Management of notifications related to data provision within Open Dataspaces
Notification destination lists SHALL be managed per Data Provider, and SHALL NOT be shared or mixed between different Data Providers.
Rationale: To ensure independence and security of notification configurations for each Data Provider.
The system MAY provide functionality to register, update, or delete multiple notification destinations in bulk, as necessary.
Rationale: To reduce operational burden and improve administrative efficiency.
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.
Notification management SHOULD be performed based on authentication and authorization using identity information of Data Providers and Data Consumers derived from authentication credentials.
Rationale: To ensure consistency with the requirements of the L2 and L3 layers and to enforce access control for notification information.
The system MAY provide functionality to register, update, or delete multiple notifications in bulk, as necessary.
Rationale: To reduce operational burden and improve administrative efficiency.
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.
This function is assumed to be used via Transaction（L2）.
This function is assumed to use tokens issued by the Identity & Trust（L3）t.
Type
Sender ⇒ Receiver
Description
Request
Client (Transaction（L2）) ⇒ Server (Notifier)
A message sent by the client to execute functions of the Notifier. Includes authentication information and request parameters.
Response
Server (Notifier) ⇒ Client (Transaction（L2）)
A message sent by the server in response to a request. Includes processing results and error information.
The message exchange sequence when using the Notifier is shown below.
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.
Service definition method: SAMM (Semantic Aspect Metamodel)
<base> indicates the connector base URL
For each field used in this binding, the following information is provided:
Method
Endpoint
Description
POST
/v1/api/query
Issue a SPARQL query
The request body is as follows.
Parameter
Required
Type
Description
query
✔
string
SPARQL query string
target
A sample is as follows.
An example of metadata in a drone route domain is shown below.
Aircraft
Entity Overview
Item
Content
RDF Type
Aircraft
Vocabulary
ID Format (Example)
Main Properties
Property
Type
Description
Example
aircraftId
string
Aircraft ID
DDDD2222-...0004
aircraftName
Geometry
Sample Data
Entity Overview
Item
Content
RDF Type
DronePort
Vocabulary
Main Properties
Property
Type
Description
Example Value
dronePortId
string
Port ID
DDDD2222-...0004
dronePortName
Sample Data
Entity Overview
Item
Content
RDF Type
Uasl
Vocabulary
Route Entity
Property
Type
Description
uaslId
string
Route ID
uaslName
string
Route name
Sample Data
RDF Patch update notifications from a domain application are received via AMQP.
At-least-once delivery
Arrival order is not guaranteed (ordering is controlled on the distributed catalog side)
Field
Description
id
Update sequence identifier (version ID)
prev
ID of the previous patch (used for ordering control)
RDF Patch body
Patch in Apache Jena/Fuseki format
Header Name
Description
domain_app_id
Domain application identifier (a default value is used if not specified)
Element
Description
H
Header (id, prev, etc.)
TX / TC / TA
Transaction boundaries
PA / PD
Add/remove prefixes
For concrete implementations such as Sent by, Resulting state(s), Request, Response, Examples, Error lists, and API-specific field definitions, refer to the API specification.
H id <uuid:...>
H prev <uuid:...>
TX
PA ex: <http://example.org/>
A ex:subject ex:predicate "object" .
D ex:subject ex:oldPredicate "oldObject" .
TC
Field Definitions
Issuing a SPARQL Query
Resource Metadata
Show sample data
Drone Port (DronePort)
Show sample data
Route (UASL)
Show sample data
RDF Patch Notification
Delivery Semantics
Message Format
AMQP Headers (Optional)
RDF Patch Format (Apache Jena/Fuseki)
Functional Description
Sequence Diagram
Issuing a SPARQL Query
Protocol
Overview
Identity & Trust (L3) provides functionality that identifies participating entities and establishes the trust foundation ensuring that data exchange occurs only between legitimate entities and with authorized access to legitimate resources.
This protocol covers the following domains:
Authentication
Identifies and authenticates both natural persons (Human) and systems (Machine) as subjects, and enables authentication appropriate to the operational context.
Authorization
Performs policy-based dynamic authorization on a per-request basis.
Token and Credential Management
Issues access tokens and refresh tokens, and attaches business-context claims such as operator identifiers (e.g., operator_id) as token claims.
Federation & Trust
Establishes mutual trust across different operating organizations and across different Open Dataspaces.
Concept
Description
This protocol defines requirements for the following functional areas:
The Identity & Trust（L3）SHALL provide mechanisms capable of distinguishing and authenticating both natural persons and systems.
Rationale: ODS operational requirements involve both human interaction and system-to-system communication. These must be clearly distinguished to ensure proper security and accountability.
Authentication and authorization mechanisms SHALL use OAuth 2.0 and OpenID Connect. Authentication of natural persons SHALL use OpenID Connect (Authorization Code Flow). Authentication of systems SHALL use OAuth 2.0 (Client Credentials Flow).
Authorization decisions SHALL NOT depend solely on network boundaries (e.g., firewall or DMZ).
Rationale: This aligns with Zero Trust architecture principles and prevents implicit trust based on network location.
The subject identifier used for authorization decisions SHALL be based on verified claims contained in the access token.
Access tokens SHOULD be signed JWTs.
Rationale: Signed JWTs provide interoperability, lightweight validation, and compatibility with existing ecosystem tooling.
Access tokens SHOULD have short lifetimes limited to the minimum necessary duration.
Identity Federation across different Open Dataspaces operating organizations SHOULD be supported.
Rationale: Future interoperability is necessary.
In a federated environment, the subject identifier SHOULD be in a format that enables identification of the issuing authority.
The following message types are handled by this protocol.
Type
Direction
Description
The following sequence illustrates a representative authentication scenario using the Authorization Code Flow for a natural person.
redirect_uri: URI to redirect after authentication
This section describes the states handled by this protocol.
State
Description
This section describes the error handling used in this protocol.
Error Type
Description
Handling
Protocol
Overview
This protocol is a fundamental protocol that corresponds to ODS-RAM L4 Discovery and Search and is responsible for the advancement of discovery and search based on metadata, and performs resource discovery and endpoint resolution using information published on the Metadata Exchange.
Abstract Normative Specification
Concepts and Roles
Role
Description
Business Domain
A specific business domain. Common services such as a Discovery Service may be constructed per business domain.
Note that the "Discovery Service" described in "" is a concept that encompasses both the "Discovery Finder" (discovery of Discovery Services) and the "Discovery Service" (discovery of destination endpoints) as defined in this protocol specification.
Discovery Service resolution
Resource search
Endpoint retrieval
Discovery Service SHALL provide an API (register) to register searchable resources.
Rationale: Discovery assumes that service providers or data holders actively register their data or services to be searchable. Unlike passive indexing such as web search engines, the Discovery Service performs active indexing initiated by the site.
Discovery Service SHALL provide an API (find) that returns metadata including endpoints, using attributes as keys, in order for clients to resolve endpoints necessary to access data or services.
Type
Sender ⇒ Receiver
Description
When information about a data/service provider is registered in the Discovery Service, its lifecycle is managed according to the following state transitions.
State
Description
Event
Description
This section describes the error handling used in this protocol.
Error Type
Description
Handling
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.
Performs operations related to notification content issued by Data Providers.
(Reference URL)
Notification Management
Update Notification Confirmation Status
Allows a Data Consumer to update the confirmation status of a notification.
(Reference URL)
Notification Management
Update Data Receipt Status
Allows a Data Consumer to update the receipt status of data.
(Reference URL)
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.
Rationale: In distributed data management, data and services may exist at arbitrary global locations, enabling data usage control. However, discovery becomes a technical challenge for clients; therefore, it is necessary to enable access to endpoints based on searchable attributes.
Discovery Service SHALL return metadata including resource endpoints as search results.
Rationale: Since the Discovery Service is used to identify the location of data or services, it must return metadata containing endpoints.
Discovery Service SHOULD support keyword search. It SHOULD provide an API (find) that returns metadata including endpoints using string-based keys.
Rationale: An index that returns metadata for data or services associated with keyword matches is broadly useful.
Metadata registration in the Discovery Service SHOULD become invalid after a certain period (TTL). To remain searchable, a keep-alive instruction is required.
Rationale: To minimize the existence of stale metadata when the underlying data/service no longer exists (cf. soft-state management in distributed systems).
Discovery Service MAY support geospatial search. It provide an API (find) that returns metadata including endpoints using geospatial attributes as keys.
Rationale: An index that returns metadata for data or services associated with real-world latitude and longitude can be useful depending on the use case.
Consistency requirements for metadata management in the Discovery Service MAY be eventual consistency.
Rationale: Scalability and fault tolerance are important in distributed systems. Consistency between metadata stored in the Discovery Service and that of the original provider can typically be verified when accessing the actual data/service.
Metadata of the Discovery Service itself MAY be managed using the same format and method (e.g., service definitions using SAMM).
Rationale: Enables uniform access from clients.
Construction of a Discovery Service in each domain MAY be facilitated by defining indexable attributes in metadata (e.g., via SAMM service definitions), allowing necessary components to be generated.
Rationale: Building a Discovery Service requires database setup and message handling, much of which is common and can be automated. Some domain-specific logic remains for developers, so generation is provided up to a template level.
Discovery Finder SHALL provide an API that returns metadata including the endpoint of a Discovery Service, based on the Discovery Service name or domain name, in order to resolve the endpoint required for clients to access a Discovery Service.
Rationale: Since multiple Discovery Services may exist per domain, endpoint resolution itself is required.
Clients SHOULD statically maintain metadata such as the endpoint and API information of the Discovery Finder.
Rationale: It is assumed that only one or a limited number of Discovery Finders exist within Open Dataspaces, and the frequency of retrieving domain-specific Discovery Services is relatively low.
keep alive
Instruction to maintain searchable status
System Error
Internal failure
Notify administrator
Provider
Provides data or services related to the business domain and may manage multiple resources.
Consumer
Uses data or services provided by a Provider.
Metadata Server
Publishes metadata as RDF. Accepts external retrieval requests at a Metadata Endpoint. Retrieves static data from a Metadata Store and dynamic data from an Application Server as needed.
Metadata Store
Stores metadata as RDF and primarily handles static data.
Metadata Client
Retrieves metadata, for example through a JavaScript library in a browser.
Metadata Endpoint
RDF retrieval endpoint in a Metadata Server, including a SPARQL endpoint.
Discovery Finder
A service that determines which Discovery Service to use. It provides metadata including the endpoint of a Discovery Service.
Discovery Service
Searches metadata based on resource attributes (e.g., latitude/longitude, strings). The returned metadata includes not only the target resource but also the semantic definitions and endpoints of the related data/service provider interfaces. Endpoints include the Metadata Endpoint as well as service-specific endpoints (e.g., reservation APIs).
findDiscoveryService
Metadata Client ⇒ Discovery Finder
Search for a Discovery Service
findResource
Metadata Client ⇒ Discovery Service
Search for a resource
Initial
State before being registered in the Discovery Service
Active
Registered in the Discovery Service and searchable
Terminated
Not registered in the Discovery Service or invalidated
create
Registration of provider information in the Discovery Service
delete
Deletion of provider information from the Discovery Service
timeout
Invalidation after a certain period following creation/update
This protocol is a Fundamental Protocol corresponding to the L1 "Data Trustworthiness and Quality Assessment" of ODS-RAM, and is responsible for "an interface that enables the assessment and calculation of data quality and trustworthiness (not including the functionality of the assessment and calculation of quality and trustworthiness itself)."
The "Data Trustworthiness and Quality Assessment" Protocol Specification is scheduled for public release in fiscal year 2026.
Resource Owner
An entity that grants authorization to a Client to access a Resource Server (API Server) on its behalf.
Service Provider
The organization operating the Identity & Trust（L3）.
Operator
An organization that receives delegated authority from the Service Provider and operates systems within the dataspace.
PAP
Policy Administration Point responsible for defining and managing authorization policies.
PDP
Policy Decision Point that receives authorization requests from the PEP, evaluates policies defined by the PAP together with request context, and determines whether access shall be permitted or denied.
PEP
Policy Enforcement Point that receives requests from a Client and, where necessary, requests an authorization decision from the PDP.
Rationale: OAuth 2.0 and OpenID Connect are internationally adopted standards that ensure interoperability across heterogeneous systems and dataspaces.
User authentication SHOULD use Authorization Code Flow with PKCE.
Additional credentials (e.g., Verifiable Credentials) MAY be used.
Rationale: This enables extensibility and future interoperability with other Open Dataspace and trust frameworks.
Phishing-resistant multi-factor authentication MAY be used.
Rationale: Multi-factor authentication reduces risks associated with credential theft and replay attacks.
Note (Future revisions): MAY consider phishing-resistant authentication methods such as FIDO2-based passkeys.
Rationale: This ensures logical linkage between authentication and authorization and prevents impersonation or identity inconsistencies.
Authorization SHOULD adopt a two-layer structure consisting of coarse-grained access control at the API Gateway level and fine-grained access control at the application or resource level.
Rationale: Separation between infrastructure-level and business-level authorization preserves scalability and architectural flexibility.
PAP, PDP, and PEP SHOULD be logically separated.
Rationale: Separation of policy administration, decision logic, and enforcement improves maintainability, security isolation, and performance optimization.
Communication between PEP and PDP SHOULD align with the AuthZEN model or an equivalent standardized authorization interaction model.
Rationale: Alignment with standardized authorization interaction models improves consistency and supports interoperable policy evaluation mechanisms.
PAP and PDP SHOULD, logically, be integrated with the Identity & Trust（L3）.
Rationale: To ensure consistency of the authorization model and evaluation logic and prevent complexity caused by distributed policy management.
The authorization model SHOULD adopt Relationship-based Access Control (ReBAC). When ReBAC is adopted, the authorization model SHALL be capable of explicitly representing at least subject, object, and relation.
Rationale: It naturally represents delegation and sharing relationships as graphs and provides superior readability and extensibility.
Rationale: Short-lived tokens minimize impact in case of leakage or compromise.
Business claims such as operator_id and system_id SHOULD be included where applicable.
Rationale: Identification of business entities within Open Dataspaces is essential.
expires_in: Access token expiration time (seconds)
token_type: Access token type
not_before_policy: Access token validity start time
scope: Client scope
refresh_token: Refresh token obtained from the IDP
refresh_expires_in: Refresh token expiration time (seconds)
id_token: ID token
TOKEN_EXPIRED
The access token has expired. Token refresh using a refresh token or re-authentication is required.
TERMINATED
The session or token has been invalidated (e.g., logout, revocation, or refresh failure) and re-authentication is required.
Insufficient Permission Error
Returned when required permissions are insufficient.
Notify that the operation is not permitted. Since resending will not succeed, do not resend the request.
Resource Not Found Error
Returned when the target resource does not exist.
Notify that the resource does not exist. Since resending will not succeed, do not resend the request.
Data Inconsistency Error
Returned in cases such as duplicate data or concurrency control conflicts.
Retrieve the latest data, resolve the conflict, and resend the request.
Request Format Error
Returned when an unsupported request format is specified.
Set the correct Content-Type and resend the request.
System Error
Returned when an abnormality occurs inside the server.
If the error continues to occur, notify the system administrator. Whether to resend depends on the operation performed.
External System Error
Returned when an abnormality occurs outside the server.
Retry (resend) at fixed intervals. If the issue is not resolved, notify the user to retry after some time and notify the system administrator.
Identity & Trust（L3）
A generic term for an entity that provides identity-related functions. It performs authentication of users and systems, manages authorization (delegation of authority), and provides identity information. Depending on the architecture, including federated configurations, these roles MAY be performed by separate entities.
Client
An entity that accesses APIs provided by a Resource Server under delegated authorization granted by a Resource Owner.
Resource Server
An entity that provides functions or data via APIs. It provides resources to a Client according to the scope of authority delegated by the Resource Owner.
Request
Client ⇒ Identity & Trust（L3）
A message sent by the Client to request authentication or authorization. It includes authentication information and request parameters.
Response
Identity & Trust（L3） ⇒ Client
A message sent by the Identity & Trust（L3） in response to a request. It may include authentication results, tokens, or error information.
UNAUTHENTICATED
No token exists. Before authentication.
AUTHENTICATING
Authentication is in progress at the IdP (authentication via the /auth/token and /auth/token/client endpoints).
AUTHENTICATED
The access token is valid. Normal API calls are possible.
Invalid Request
Returned when parameters are invalid or required fields are missing.
Reconfirm the input content, set the correct values, and resend the request.
Token Configuration Error
Returned when the access token is not set or is invalid.
Reacquire and reset the access token (re-login or refresh the token as necessary), and resend the request.
This protocol is responsible for endpoint and process control as well as data transfer, and provides functionality that enables transactions to be established as the nexus connecting each layer.
The core component group of this protocol, referred to as the Transaction Component, serves as the junction point among protocols defined in ODP. It communicates with each layer and perspective (Common Functionalities, Fundamental Protocols, and Complementary Protocols).
This protocol defines the following transaction management.
Data transfer
Provides functionality to transfer data from a data store endpoint in response to requests from a Data Consumer.
To support data transfers across different data structures (structured / unstructured) and processing modes (synchronous / asynchronous), the data plane modules are logically classified into the following four types:
Web API Transfer Module
A data plane module specialized for transferring synchronous structured data (e.g., Web APIs).
Stream Transfer Module
A data plane module specialized for transferring asynchronous structured data (streaming data).
Authentication and Authorization Integration
Provides request-level authentication and authorization control in coordination with a credential issuance service and the Identity & Trust（L3）.
Logging Records historical information and information required for clearing and payment (DCS) in coordination with Logging (Common Functionalities).
The following concepts are required for this protocol:
Concept
Description
This specification defines the Web API Transfer Module as a minimum implementation example.
Data transfer within Open Dataspaces SHALL be performed through a data plane module.
Rationale: To ensure reliability and interoperability within Open Dataspaces.
The architecture SHOULD maintain extensibility to support multiple data structures and transfer methods.
The module SHOULD integrate with the Identity & Trust（L3) to perform request-level authentication and authorization control.
Rationale: To ensure consistent access control, security, and interoperability across Open Dataspaces.
The module SHOULD be capable of recording the minimum data required by Dataspace Complementary Services (DCS).
The protocol handles the following types of messages:
Type
Sender ⇒ Receiver
Description
Messages exchanged in this protocol consist of the following elements:
Element
Description
No.
Name
Sender
Receiver
Field
Description
This section describes the states handled by this protocol.
State
Description
This section describes the error handling used in this protocol.
Error Type
Description
Occurrence Timing
Handling
Binding
This section describes definitions when mapped to an actual communication method (e.g., HTTPS, file transfer, WebSocket). All content described below is non-normative (examples).
Concrete Specification (Implementation Example)
Prerequisites
HTTPS communication
RDF
JSON-LD
UTF-8
SAMM
dcterms
For each field used in this binding, the following information is provided:
Discovery Finder and Discovery Service return "service instance" data. A service instance is expressed in JSON-LD format and consists of the following main elements:
Field Name: Name used within this binding
Type: Data type (e.g., integer, string)
Requirement: Usage condition of the field
Field Name
Type
Mandatory
Request
Response
Description
Resolves application endpoints related to resources in a business domain based on resource information (data/services).
Allows users to search domain data using various search keys and resolves both the data and the metadata of the domain application required to obtain that data.
When constructing a Discovery Service for a custom business domain, the message processing and database components are auto-generated. Only the integration logic connecting them needs to be implemented.
Used to resolve the endpoint required for users to access a Discovery Service.
Registers Discovery Service endpoints.
Can register under an existing keyword or create a new keyword.
Binding
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.
Binding
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.
For each field used in this binding, the following information is provided:
Protocol
This protocol is a fundamental protocol that corresponds to ODS-RAM L4 Metadata Exchange and facilitates the exchange of metadata relating to the location and semantics of data, enabling data discoverability and semantic interpretation in distributed environments.
RDF (Resource Description Framework) is adopted as the information model for metadata, and JSON-LD and Turtle are adopted as data model formats. By publishing this metadata, providers of data and services enable easier discovery, interpretation, and utilization of data and services. Furthermore, by using higher-level protocols such as Discovery and Search on top of this foundational protocol, even if data and services are distributed across a network, the entire Open Dataspaces can function transparently as a single system. This metadata is primarily intended to associate real-world entities such as mobility and supply chains with access to data and services in the cloud; however, the former is not mandatory.
Through the mandatory metadata concerning services and access, the external specifications of services are grounded in a globally resolvable manner, and the necessary information for access, including destination information, becomes explicit.
These metadata components are constructed on the side of general web application servers and clients. A metadata server statically or dynamically retrieves metadata from an application server.
File / Bulk Transfer Module
A data plane module specialized for transferring synchronous unstructured data (large files or bulk data).
Media Stream Transfer Module
A data plane module specialized for transferring asynchronous unstructured data (real-time streaming data such as video or audio).
Rationale: Data distribution in Open Dataspaces involves diverse use cases, including structured / unstructured and synchronous / asynchronous patterns, and a single method cannot ensure interoperability and implementation flexibility.
A data plane module MAY be used directly without employing the Control Plane Orchestrator.
Rationale: To enable ease of adoption and phased deployment, and to preserve flexibility in implementation and operation.
Rationale: To enable information linkage with DCS.
A message sent by the Data Consumer to the Web API Transfer Module to request a specific operation or information. Includes authentication information and request parameters.
2
Authentication and Authorization Request
Web API Transfer Module
Identity & Trust（L3）
Request fields depend on the Identity & Trust（L3）specification. Refer to the Identity & Trust（L3）specification.
A message sent by the Web API Transfer Module to the Identity & Trust（L3）to request authentication and authorization. Includes authentication information and request parameters.
3
Authentication and Authorization Response
Identity & Trust（L3）
Web API Transfer Module
Response fields depend on the Identity & Trust（L3）specification. Refer to the Identity & Trust（L3）specification.
A result message sent by the Identity & Trust（L3）to the Web API Transfer Module in response to a request. Includes authentication and authorization results, tokens, or error information.
4
Transfer Request
Web API Transfer Module
Data Provider
Request fields depend on the target system specification. Refer to the specification published by the Data Provider.
A message sent by the Web API Transfer Module to the Data Provider to request a specific operation or information. Includes authentication information (e.g., API key) and request parameters.
5
Provider Response
Data Provider
Web API Transfer Module
Receives either a successful response or an error response returned by the Data Provider. Refer to the specification published by the Data Provider.
A result message sent by the Data Provider to the Web API Transfer Module in response to a request. Includes API execution results or error information.
6
Consumer Response
Web API Transfer Module
Data Consumer
The successful response or error response returned by the Data Provider is, in principle, passed through as-is. Refer to the specification published by the Data Provider.
A result message sent by the Web API Transfer Module to the Data Consumer in response to a request. Includes API execution results or error information.
Authorizing
Performing authorization
Processing
Routing or proxying to the upstream system
Rejecting
Generating an error due to authentication or authorization failure
Responding
Returning a response (success or error) to the client
Data Consumer ⇒ Web API Transfer Module
The request is validated and an error response is generated and returned if invalid.
API Key Error
API key validation failure
Data Consumer ⇒ Web API Transfer Module
The API key is validated within the module and an error response is generated and returned if invalid.
API Key Error (L3 Side)
API key validation failure at the Identity & Trust（L3）
Web API Transfer Module ⇒ Identity & Trust（L3）
The response from the Identity & Trust（L3）is returned as is.
Token-related Error (Authentication)
Access token invalid or expired
Web API Transfer Module ⇒ Identity & Trust（L3）
Based on the token validation result, an error response is returned as is if invalid or expired.
Insufficient Authorization
Access denied by authorization decision
Web API Transfer Module ⇒ Identity & Trust（L3）
Based on the authorization decision result, an authorization error response is returned as is.
Routing or Endpoint Error
Destination cannot be determined due to unregistered route or path/method mismatch
Web API Transfer Module
An error response is generated and returned.
External Connection Error
Failure to connect to L3 or external system, or invalid response received
Web API Transfer Module ⇒ Identity & Trust（L3）/ External System
Upon detecting connection failure or invalid response, an error response is generated and returned.
Timeout
No response received from L3 or external system within the defined time
Web API Transfer Module ⇒ Identity & Trust（L3）/ External System
Upon detecting timeout, an error response is generated and returned.
Internal Processing Failure
Processing cannot be completed due to internal exception
Web API Transfer Module
The exception is handled and an error response is generated and returned.
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
Request
Data Consumer ⇒ Web API Transfer Module; Web API Transfer Module ⇒ L3 Identity Component; Web API Transfer Module ⇒ Data Provider
A message sent to request data operations or authentication and authorization. It includes required header information and request parameters.
Response
Identity & Trust（L3）⇒ Web API Transfer Module; Data Provider ⇒ Web API Transfer Module; Web API Transfer Module ⇒ Data Consumer
A message sent in response to a request. It includes operation results, authentication or authorization validation results, tokens, or error information.
Header
Located at the beginning of the message and contains metadata required for communication control.
Payload
Located in the body of the message and contains the business data.
1
Consumer Request
Data Consumer
Web API Transfer Module
Idle
Waiting for a request
Receiving
Receiving a request
Authenticating
Performing authentication
External System Error (Transparent)
Errors returned by an external system (4xx / 5xx specific to the external service)
Web API Transfer Module ⇒ External System
The external system response is returned as is.
Invalid Request
Abstract Normative Specification
Concepts and Roles
Scope
Normative Requirements
Non-functional / Cross-layer Requirements
Message Types
Message Format
Protocol Flow
Communication Flow
Detailed Description of Each Communication
State Machine
States
State Machine Diagram
Error Handling
Request fields depend on the target system specification. Refer to the specification published by the relevant Data Provider.
Request cannot be processed due to missing required headers or invalid values
R = Required
C = Conditional
O = Optional
Request: Used in request messages
Response: Used in response messages
Description: Meaning and usage of the field
Definition of JSON-LD namespaces. Binds prefixes (e.g., dcterms, ods, service) to URIs.
@graph
array
R
✔
Array containing the service instance data.
ods:Connector
object
R
✔
Definition of the Discovery Service or domain application, including provided endpoints and service provider name.
ods:ConnectorEndpoint
object
R
✔
Definition of individual API endpoints held by the Discovery Service or domain application. Specifies the URI of each endpoint.
ods:BaseEndpoint
object
R
✔
Base URL of the Discovery Service or domain application.
ods:SparqlEndpoint
object
R
✔
URL of the SPARQL endpoint of the RDF server provided by the domain application.
Search results: metadata of service instances
Database Generation
Creates RDB tables for index management from interface definitions.
Searches Discovery Service endpoints (access URLs).
Search keys:
Discovery Service keyword (e.g., UAS Lines)
Business domain keyword (e.g., drone, drone route, port)
@context
string
R
Spatial Index
Enables high-speed geospatial search by managing nearby data based on latitude and longitude. Supports bounding box and radius-based queries.
String Index
Enables search for resources sharing the same keyword.
Message Processing Generator
Generates message processing programs from interface definitions.
Field Definitions
Example of Service Instance Returned by a Discovery Service (e.g. Aviation Industry)
Example of Service Instance Returned by a Discovery Finder (e.g. Aviation Industry)
Authentication and Authorization: OAuth 2.0 and OpenID Connect are used.
For authentication involving natural persons, OpenID Connect (Authorization Code Flow) is used. For system-level access control, OAuth 2.0 (Client Credentials Flow) is used.
Policy-based authorization control is also provided.
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:
The definitions of the fields used in this protocol are described below. For detailed field definitions of each API, refer to the separately published API Specification.
Each field includes the following information:
Field Name: Name used within the protocol
Type: Data type (e.g., integer, string)
Requirement:
R = Required
C = Conditional
O = Optional
Request: Used in request messages
Response: Used in response messages
Description: Meaning and usage of the field
Field Name
Type
Required
Request
Response
Description
API-Key
String
R
✔
Field Name
Type
Required
Request
Response
Description
type
String
R
Refer to the API Specification for detailed implementations such as Request, Response, Examples, Error lists, and API-specific field definitions.
Category
Function
Description
Authentication
User Identity Verification
Performs user authentication based on the OIDC authorization flow.
Authentication
Client System Authentication
Authenticates a client using the Client Credentials Flow with a client ID and a client secret.
This protocol provides the following two authentication flows.
Authentication Flow
Description
Authorization Code Flow
Used in authentication scenarios involving a user. The client redirects the user to the Identity & Trust（L3）’s authentication screen, and after authentication, obtains an access token using the issued authorization code.
Client Credentials Flow
Used in non-interactive authentication scenarios without a user. The client accesses the Identity & Trust（L3）’s client system authentication endpoint using a client ID and a client secret to obtain an access token.
The main authentication information used in this protocol is as follows.
Authentication Information
Applicable Flow
Description
login_user_id
Authorization Code Flow
Identifier entered by the user on the login screen in the Authorization Code Flow involving user authentication.
password
Authorization Code Flow
This protocol attaches the following two types of custom claims to issued access tokens for business identification purposes.
operator_id (Operator Identifier)
Information used to identify the operator to which the user or client belongs. This claim is attached to the access token in the following flows.
Authorization Code Flow The operator specified at the time of user issuance is attached.
Client Credentials Flow The operator specified at the time of client_id issuance is attached.
open_system_id (System Identifier)
Information used to identify the system to which the client belongs. This claim is attached to the access token only in the following flow.
Client Credentials Flow
It is not attached in the Authorization Code Flow (flow involving a user).
During communication, the following header fields are required from the client. Any headers not listed below are optional and are not processed by the Web API Transfer Module.
Field Name
Type
Required
ODS-specific
Request
Response
Description
API-Key
String
C
The Web API Transfer Module adopts a transparent API gateway approach. Since the payload structure depends on the API specification provided by the Data Provider, refer to the relevant Data Provider system specification for detailed payload definitions.
For error responses, the following JSON payload is returned:
Field Name
Type
Format
Description
code
String
[prefix] {Error Status}
Error code including a prefix. Prefix values are as follows:
- dataspace: Error occurred within the Web API Transfer Module
- auth: Authentication or authorization-related error
message
Example:
The Web API Transfer Module adopts a transparent API gateway approach and is limited to routing functionality. It does not provide payload parsing or model transformation capabilities. The Web API Transfer Module intermediates communication between Data Consumer applications and Data Provider systems and provides Policy Enforcement Point (PEP) functionality for token validation and authorization control in coordination with the Identity Component.
The Transaction Layer provides the following functions:
Category
Overview
Description
Routing
Provides routing functionality as a transparent API gateway.
Routing rules are registered as "routes" to mediate between Data Consumers and Data Providers. Each route forwards requests to the target system API based on request conditions (path, method, headers, etc.). By modifying route configurations, destinations and conditions can be dynamically added or updated. During routing, the Web API Transfer Module performs necessary processing (e.g., generating a UUID if X-TrackingID is not included in the request header, rewriting headers, etc.).
Authentication Control
Performs client authentication.
Two authentication mechanisms are supported:
- API Key Authentication: Validates the "API-Key" request header within the Web API Transfer Module.
- OAuth 2.0 / OpenID Connect Token Introspection: Validates the access token in the "Authorization" request header in coordination with the Identity & Trust（L3）. If validation fails or the token is expired, the module returns an HTTP 401 Unauthorized response with a JSON error payload. By separating authentication control from business logic, responsibilities are clearly defined, maintainability is improved, and changes to authentication mechanisms have minimal impact on the gateway.
Seq No.
Description
1
The client (Data Consumer) sends an HTTP request to the Web API Transfer Module to execute a Data Provider API.
2
The Web API Transfer Module validates the API key. If valid, it sends an HTTP request to the token introspection endpoint of the Identity Component to verify the access token. If X-TrackingID is not included in the request header, a new UUID is generated.
3
The Identity Component validates the token and returns the validation result (e.g., validity, scope).
A metadata client provides metadata to an application client. As a design approach, while conventional web application systems are database-oriented and required to satisfy system requirements such as transactions, real-time processing, and high throughput, metadata-related systems shall prioritize the discovery of necessary data from a wide variety of data across broad-scale environments, and as a trade-off for this, consistency of data and similar properties shall initially be sacrificed and added as needed. It is assumed that use cases requiring strict consistency management of metadata are limited, since diverse real-world data and existing application server data are transformed and replicated into a unified metadata format.
concept 3
Role
Description
Business Domain
A specific business domain. Common services such as Discovery Service may be constructed per business domain.
Provider
Provides data or services related to the business domain and may manage multiple resources.
Consumer
Uses data or services provided by a Provider.
RDF metadata publication
RDF Patch synchronization
SPARQL retrieval
Metadata SHALL be represented in RDF.
Rationale: To unify semantic representation and ensure interoperability.
Metadata SHALL include globally resolvable semantic definitions of interfaces related to data exchange or service provision, for example SAMM.
Rationale: Ambiguous interface semantics may lead to unintended usage.
Metadata SHALL include destination information of interfaces held by data or service providers.
Rationale: To enable transparent access to distributed services within a unified Open Dataspace under appropriate access control.
Metadata SHOULD be transmitted and received in JSON-LD format.
Rationale: High compatibility with web-based implementations and extensive track record of adoption.
If a provider is associated with a physical or logical entity in the real world, this SHOULD be included as metadata.
Rationale: Enables association of real-world entities with network services.
If such entities are related to entities of other providers, these reference relationships SHOULD be included as metadata.
Rationale: Following reference relationships enables discovery of other providers and enhances overall interoperability.
A mechanism for managing metadata differences MAY be provided, such as RDF Patch. Eventual consistency is assumed. Lineage, timestamps, and version control SHOULD be used to manage differences when necessary.
Rationale: While strong consistency is not required, metadata freshness may be important.
It SHALL be capable of integrating with Identity & Trust（L3）.
If access control is required for metadata itself, it SHALL integrate with Identity & Trust（L3） and authorization management SHALL be applied.
The RDF model SHALL conform to the ODS semantics policy.
Metadata is provided from systems that offer data or services to a Metadata Server and is then published. It becomes referable from other systems by referencing metadata of other service providers or by being published to a Discovery Service.
Metadata consists of service metadata related to semantic definitions and destination information of data and services, and resource metadata corresponding to real-world entities. Service metadata consists of descriptions of the service specification itself and the deployed state (instance) of that specification in a given environment. The description of the service specification itself may be stored in another Metadata Server and expressed by referencing it. Specifications unique to a particular service may be stored in the corresponding Metadata Server. Service metadata may be referenced from resource metadata. Service specifications are described as Aspect Models using SAMM or similar approaches.
Service metadata consists of two parts:
Item
Type
Required
Description
@context
object
Yes
Namespace definitions
@graph
@context defines the mapping between prefixes used in metadata and their corresponding namespaces.
Namespace defining the Aspect Model, for example: @prefix uasl: <urn:samm:com.foo.uasl:0.5.3#> .
Namespace used by the domain application API definition file, for example: @prefix api: <https://uasl.foo.com/0.5.3/api#> .
Namespace for the domain application (explicit company namespace), for example: @prefix inst: <http://www.example.com/uasl/instance#> .
The default prefix is not used; the prefix inst is explicitly used.
Domain application instances are defined as type ods:DomainApp.
dcterms:conformsTo is used to explicitly link to the Aspect Model and API definition.
Properties defined in the Aspect Model for the domain application are assigned actual values.
ods:hasBaseEndpoint indicates the base endpoint of the API.
The API base endpoint is defined as class ods:BaseEndpoint (a subclass of ods:DomainAppEndpoint).
ods:hasSparqlEndpoint indicates the SPARQL endpoint.
The SPARQL endpoint is defined as class ods:SparqlEndpoint (a subclass of ods:DomainAppEndpoint).
ods:hasEndpoint indicates endpoints for each API.
Each API endpoint is defined as class ods:DomainAppEndpoint (a subclass of ods:DomainAppEndpoint).
ods:accessURL specifies the URL of each endpoint.
Key
Type
Description
dcterms
string (URI)
Dublin Core Terms
rdf
string (URI)
RDF namespace
@graph consists of multiple objects:
DomainApp: Represents the entire domain application.
DomainAppEndpoint: Represents URI information of endpoints defined by SAMM.
BaseEndpoint: Represents the common URI part of REST API endpoints.
SparqlEndpoint: Represents endpoint information for SPARQL.
DomainApp represents the entire domain application.
Structure
DomainAppEndpoint represents URI information of endpoints defined by SAMM.
Common Structure
BaseEndpoint represents the common URI part of REST API endpoints.
SparqlEndpoint represents endpoint information for SPARQL.
Resource metadata represents domain data generated and managed by applications, expressed in RDF and given meaning using a shared vocabulary. Since it is domain-dependent, concrete examples are provided in binding.md.
(1) Basic Structure
Data is expressed in RDF using JSON-LD.
Each file follows the basic structure below:
Element
Description
@context
Namespace and vocabulary definitions
@graph
Array of RDF resources
ID Representation
Each entity is uniquely identified by @id.
HTTP URI format is adopted.
Example:
Data Types
Literal values are explicitly expressed using @value and @type.
Typical types:
xsd:string
xsd:integer
xsd:double
xsd:boolean
xsd:dateTime
Type
Sender ⇒ Receiver
Description
sparqlQuery
Metadata Client ⇒ Metadata Endpoint
RDF retrieval
patchNotify
Metadata Endpoint ⇒ Metadata Client
Differential notification
This section describes the error handling used in this protocol.
Error Type
Description
Handling
RDF format error
Invalid JSON-LD
Correct input
Endpoint unreachable
Network issue
Retry
Michael Franklin, Alon Halevy, David Maier, "From Databases to Dataspaces: A New Abstraction for Information Management", SIGMOD Record, Vol. 34, N
Specifies the API key issued per client application. ODS-specific field
Authorization
String
C
✔
Specifies the access token. Example: Bearer < token >. Not required for authentication flow-related APIs (except password change).
Content-Type
String
R
✔
✔
Specifies the request format.
User-Agent
String
O
✔
Specifies the client user agent.
Accept-Language
String
O
✔
Specifies the client’s preferred language.
X-TrackingID
String
O
✔
✔
Specifies a unique ID used for request tracing. ODS-specific field
Content-Security-Policy
String
O
✔
Specifies content loading and execution policies and controls allowed script and resource origins.
X-Content-Type-Options
String
O
✔
Prevents MIME-type sniffing by browsers and enforces the declared Content-Type.
Strict-Transport-Security
String
O
✔
Enforces HTTPS connections for a specified period and prevents downgrade to HTTP.
Access-Control-Allow-Origin
String
O
✔
CORS header. Specifies permitted origins for cross-origin access.
Access-Control-Allow-Methods
String
O
✔
CORS header. Specifies allowed HTTP methods for cross-origin requests.
Access-Control-Allow-Headers
String
O
✔
CORS header. Specifies allowed request headers for cross-origin requests.
Access-Control-Allow-Credentials
String
O
✔
CORS header. Specifies whether credentials may be included in cross-origin requests.
✔
Sets the URI that identifies the type of execution result.
title
String
R
✔
Sets a description of the execution result.
status
Integer
R
✔
Sets the HTTP status code.
detail
String
R
✔
Sets information required by the ODS operating entity for investigation (e.g., timestamp of error occurrence).
data
String
C
✔
Business data object for successful execution results. Not required in case of error.
Token Validation / Renewal
Token Introspection
Validates an access token and retrieves its validity and associated information.
Token Validation / Renewal
Access Token Renewal
Reacquires an access token using a refresh token.
Password Management
Password Change
Changes the password of the user corresponding to the ID included in the request.
API Key Validation
API Key Validation
Validates the API key included in the request body.
Authorization
Authorization Model Registration / Retrieval
Registers or retrieves the authorization model used for authorization. Registration is restricted to authorized users only.
Authorization
Authorization Tuple Registration / Retrieval
Registers or retrieves authorization tuples. Registration is restricted to authorized users only.
Authorization
Authorization Decision
Performs authorization evaluation. The API definition conforms to the AuthZEN evaluation endpoint specification.
User / Client Registration
User Registration
Creates a new user.
User / Client Registration
Client Registration
Registers a client and issues a client secret.
Operator Information Management
Operator Information Registration / Retrieval / Update
Performs operations related to operator information.
Office Information Management
Office Information Registration / Retrieval / Update
Performs operations related to office information associated with an operator.
Secret information corresponding to the login user ID.
client_id
Authorization Code Flow / Client Credentials Flow
Identifier that identifies the client (application) in this protocol.
client_secret
Authorization Code Flow / Client Credentials Flow
Secret used by the client to authenticate itself to the Identity & Trust（L3）.
✔
✔
Specifies the API key issued per client application.
Authorization
String
R
✔
Specifies the access token. Example: Bearer
X-TrackingID
String
C
✔
✔
✔
Specifies a unique ID used for request tracing. If not provided by the client, the Web API Transfer Module automatically generates a UUID. Depending on the integrated function, this field may become mandatory (e.g., when integrating with clearing and payment services).
X-ODS-xxx
String
O
✔
✔
Extension header used for internal ODS control. For example, it may be used for log-based consistency verification in a clearing and payment service (a type of Dataspace Complementary Service, DCS). Replace "xxx" with an arbitrary identifier (e.g., X-ODS-UserId).
String
{Error Message}
Detailed error message
detail
String
{Timestamp}
Timestamp in ISO 8601 UTC format
Authorization Control
Operates as a Policy Enforcement Point (PEP).
As a PEP, it coordinates with the Identity & Trust（L3） acting as the Policy Decision Point (PDP) to perform authorization control. Integration with the authorization function (OpenFGA) is achieved via the AuthZEN API. Since authorization requirements vary by use case, authorization control can be enabled or disabled by configuration.
Logging
Outputs logs required for ODS platform operation and maintenance.
Logs include routing information, traffic information, and data required for integration with Dataspace Complementary Services (DCS). Logged information includes:
Request phase: request source information, request destination information, API information, request received time, request sent time, X-TrackingID, X-ODS-xxx headers.
Response phase: response received time, response sent time, X-TrackingID, status code.
Route Persistence
Persists route information required for routing.
- Persist route information in a database to prevent loss upon restart. Persisted routes are loaded when the Web API Transfer Module starts.
- Manage route information per use case. When multiple use cases share a single database instance, routes are separated using database schemas. The Web API Transfer Module specifies the schema in the database connection configuration to retrieve the appropriate route information.
File Transfer
Supports file transmission through the Web API Transfer Module.
- File Retrieval: Retrieves file-based data (typically several MB in size) from a connected system via the Web API Transfer Module.
- File Transmission: Transfers file-based data (typically several MB in size) to a connected system via the Web API Transfer Module.
Portability
Operates on a container platform.
Designed to run on container infrastructure and does not depend on specific cloud services.
4
The Web API Transfer Module sends an HTTP request to the authorization check endpoint to verify whether the requested operation is permitted.
5
The Identity Component evaluates access rights based on policy and returns the authorization result.
6
If authentication and authorization succeed, the Web API Transfer Module forwards the HTTP request to the Data Provider API endpoint.
7
The Data Provider processes the request and returns the result to the Web API Transfer Module.
8
The Web API Transfer Module transparently returns the API result to the client.
Resource
Information managed on Open Dataspaces that corresponds to physical or logical entities in the real world. Examples include physical entities such as drones, logical entities such as routes, and inter-company commercial relationships. Resources are searchable targets of the Discovery Service within Open Dataspaces.
Metadata Server
Publishes metadata as RDF. Accepts external retrieval requests at a Metadata Endpoint. Retrieves static data from a Metadata Store and dynamic data from an Application Server as needed.
Metadata Store
Stores metadata as RDF and mainly handles static data.
Metadata Client
Retrieves metadata, for example through a JavaScript library in a browser.
Metadata Endpoint
RDF retrieval endpoint in a Metadata Server. Includes a SPARQL endpoint.
Application Server
Business application server of a Provider. Includes general application servers.
Application Client
Client that uses business applications, such as dedicated software or a browser.
array
Yes
Metadata contents related to data/service providers
