Interoperable Interfaces: Enabling Machine-to-Machine Access
The CEOS Interoperability Handbook provides a shared framework for achieving interoperability across global Earth observation (EO) systems. It describes five core factors of interoperability: Vocabulary, Architecture, Quality, Interface and Policy, which together enable the discovery, access, visualisation, and processing of data from multiple sources.
Within this framework, the Interface factor serves as the practical execution layer. Interface refers to the search and data retrieval process, ensuring both human and machine users can transition smoothly from data discovery to access and processing. As the volume and complexity of EO data continue to grow, users rely more and more on automated systems, cloud-based platforms, and artificial intelligence tools to discover and process information. Without common interface standards, data providers may use different approaches for searching, accessing, and retrieving data, creating barriers to interoperability. Interface interoperability ensures that users and machines can interact with EO data in a consistent and predictable way, regardless of the originating data provider. This enables more efficient data integration, reduces the need for custom solutions and supports scalable processing workflows.
The handbook groups interface interoperability recommendations into three main pillars:
Data Discovery: Standardised discovery interfaces and metadata frameworks enable consistent and machine-readable access across providers. To support usability and automation, metadata should provide direct access links, previews where appropriate, and clearly indicate any authentication requirements. A key recommendation is the adoption of common discovery frameworks, such as STAC (Spatio Temporal Asset Catalog), which supports machine-to-machine access by allowing discovery systems to query datasets using standardised metadata, including information such as spatial and temporal coverage, dataset properties, and available data access links. The CEOS STAC Collection and Granule Discovery Best Practices provide recommendations for implementing STAC-based discovery interfaces for EO collections and granules, and aim to improve consistency in how EO datasets are described, searched, and accessed across different data providers.
Data Access: Once a dataset has been identified, a user should be able to efficiently access and retrieve the dataset, without requiring complex processing workflows or unnecessary bulk downloads. The handbook recommends direct file-level access via standard web protocols, support for partial and sub-file retrieval using mechanisms such as HTTP Range Requests, and individual access to all components of multi-asset granules. Access interfaces should be standardised across providers using common web-based protocols, ensuring consistent and machine-readable access mechanisms that support interoperability and reduce fragmentation across systems.
Authentication and Authorisation: Whenever authorisation is required, it should operate seamlessly at the individual file level for both humans and machine-to-machine integrations. Rather than relying on custom security implementation, authentication mechanisms should consistently adopt established open standards such as the OpenID Connect protocol and utilise specifications detailed in OpenAPI 3.0.
Details of the recommendations for Data Discovery, Data Access and Authentication and Authorisation can be found below. The community is invited to review and provide feedback on GitHub.
Data Discovery
| ID | Recommendations |
|---|---|
| DISC#1 | Collection and granule discovery interfaces should comply with the CEOS STAC Collection and Granule Discovery Best Practices (preferred) or CEOS OpenSearch Best Practices. |
| DISC#2 | Service and tool discovery interfaces should comply with CEOS ServiceDiscovery Best Practice. |
| DISC#3 | Collection and granule metadata obtained via the discovery interfaces should advertise the existence of the corresponding file-level online data access and subfile or pixel-based access services and endpoints (e.g., OGC WCS, WMTS, WCPS, OGC API Maps, OGC API Tiles, etc.) |
DISC#4 | Granule metadata obtained via the discovery interfaces should include the online data access URL to the granule (in full resolution) and to a low resolution representation (i.e., quicklook or thumbnail). The low resolution representation should be provided in Web-friendly format, e.g. JPEG or PNG, and may be a static file or an OGC WMS/WMTS or API Maps/Tiles response. |
| DISC#5 | Discovery interfaces should be accessible and return responses without requiring authentication. |
| DISC#6 | Collection and granule metadata obtained via the discovery interfaces should advertise the existence of the corresponding authentication endpoint for human and machine access to the data (if required). |
| DISC#7 | Resource metadata including keywords should link each keyword to its URI and to the appropriate thesaurus (i.e., controlled vocabularies). |
| DISC#8 | Resource metadata should contain the persistent identifier (e.g., DOI) of the corresponding resource |
| DISC#9 | Collection metadata should refer to the level of maturity with respect to the WGISS Data Management and Stewardship Maturity Matrix. |
| DISC#10 | For facilitating discovery and access, data shall be organised in collections according to the principles outlined in the Shared Collection Lifecycle Management Principles for Earth Observation Data. |
Data Access
| ID | Recommendations |
|---|---|
| DACC#1 | Granule data stored in the cloud should be accessible directly via a web-based protocol, for example the S3 (Simple Storage Service) and HTTP(S). |
| DACC#2 | Data access should support file-level access and subfile or pixel-based access. Data download interfaces over HTTPS should support “Range Requests” to allow clients to request a portion of a file. Typical use case: access to a portion of a Cloud-Optimized GeoTIFF (COG) file. |
| DACC#3 | In case a granule consists of many individual assets (files), it shall be possible to access each asset individually and it is recommended to provide access to all sub-components of a granule with a single request. |
Authentication and Authorisation
| ID | Recommendations |
|---|---|
| AUTH#1 | Authorisation should be available at a file level for both human and machine-to-machine access. |
| AUTH#2 | Authentication interfaces should comply with open standards, such as the OpenID Connect protocol. |
| AUTH#3 | HTTPS requests for data access that require authorisation will support well known methods for both human and machine-to-machine interface, such as those specified in the OpenAPI 3.0. |