OGC Testbed-14: Next Generation Web APIs - WFS 3.0 Engineering Report

The motivation behind this ER resides in the need to secure the next generation open geospatial APIs, and ease transition from legacy services to geospatial enterprise architectures aligned with current Web architecture and Spatial Data on the Web Best Practices.

Therefore, the requirements addressed by this ER were:

Technology Integration Experiments conducted during Testbed-14 were informed by activity in the OGC Vector Tiles Pilot (VTP) which began in August 2018. The objective of the VTP was to extend WFS 3.0 and other OGC standards to deliver Vector Tiles.

Results of Testbed-14 indicate the simple core of WFS 3.0 specified as OpenAPI can be implemented rapidly by software developers, and deliver geospatial feature resources secured by OpenID Connect and OAuth 2.0. In addition, findings indicated feasible methods to ease transition to next-generation APIs are available through WFS versioning and facades.

Prior to Testbed-14 WFS 3.0 development has focused mainly on revising OGC’s Web Feature Service standard for querying geospatial information on the web, concentrating on a simple core specified as reusable OpenAPI components with responses in JSON and Hypertext Markup Language (HTML). A key element of OpenAPI is the ability to provide standard, language-agnostic description for APIs and support to modern tools such as Swagger.

OpenAPI and Swagger allow both humans and computers to discover and understand the capabilities of an API without access to source code, documentation or through network traffic inspection. In addition, OpenAPI documents can be used by code generation tools to generate servers and clients in various programming languages.

Security discussions prior to Testbed-14 addressed a variety of approaches, but lacked an industry framework for integrating security controls into next generation APIs.

On the integration of OGC standards and definition of best practices for integration, the OGC® Web Services Security specification was published on the 28th January 2019 as an OGC Implementation Standard. The standard has been developed by the OGC Web Services (OWS) Common Security Standards Working Group (SWG) with the aim being to standardize the security aspects of current Web Services Standards while providing backward compatibility and interoperability.

On the other hand security discussions prior to this Testbed include concerns regarding Federated Identity Management, but these are not specifically addressed in enough detail.

This situation highlights the need for a general approach to security architectures that utilize the current state-of-the-art standards.

As a result of activities performed during this Testbed, the implementations documented in this Engineering Report serve as an initial step towards a complete high-level architecture to simplify and secure access to geospatial feature resources - including definition of security requirements objects aligned with OpenAPI. Documented implementations also indicate the potential of WFS 3.0 extensions to support Vector Tiles, maps and other innovations.

As a result of the activities performed during this Testbed, several future work points have been identified:

All questions regarding this document should be directed to the editor or the contributors:

Contacts

The content of this ER will be reviewed by the following OGC standards working groups:

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium shall not be held responsible for identifying any or all such patent rights.

Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation.

Some of the more frequently used abbreviated terms in this document include:

The foundation of WFS 3.0 is a set of interfaces which define the 'core' of the specification. The core provides a simple API to access geospatial feature resources as 'collections'. For example, this path -

lists the collections on the server that can be queried. GeoJSON is a recommended encoding for collections provided by WFS 3.0, along with HTML. The core specification supports several basic filters such as the familiar bbox, the ability to get geographic features and time. For example, this path -

returns a geospatial feature collection - which is something in real-world terrain (i.e. buildings or roads). Feature collections are typically described by geometries plus other properties. This approach provides a resource-oriented way to access geospatial features.

In this approach, the feature resource is accessed using HTTP verbs the same way they are used in HTTP itself. Unique operations like GetFeature or Update are no longer used to access or modify feature resources. Instead, we use HTTP methods like GET, POST, PUT, DELETE - which can make things easier for API and client application developers.

HTTP status codes are used to handle error situations, describe specific security schemes and other functions.

The WFS 3.0 approach is consistent with emerging OGC Web API Guidelines. It is also consistent with the resource-oriented approach described in the Testbed-12 OGC REST Users Guide summarized below.

Advanced functionality is separated into WFS 3.0 extensions. For example, vector tile delivery, transactions for updates and generalization of features at different resolutions are provided as WFS 3.0 extensions.

Each WFS 3.0 also deploys a landing page which provides easy-to-consume blocks of content describing the API, supported conformance classes and feature resources (collections) [1]. An example of Testbed-14 WFS 3.0 landing pages for the dataset over Daraa, Syria is shown below.

The landing page is available at the 'root' path of a WFS 3.0. For example, it is simply this path -

WFS 3.0 minimizes the use of WFS-specific components as much as possible and instead uses industry standards that are commonly used by developers. The most important example of this is the use of OpenAPI documents instead of OGC-specific "Capabilities" documents. Accordingly, a key element of the initiative was an assessment of the ability of OpenAPI to provide a simple, language-agnostic description of the APIs. Testbed-14 also included TIEs to assess the ability of WFS 3.0 to support modern API specifications and tools such as Swagger.

An example of one of the Testbed-14 WFS 3.0 OpenAPI documents accessed in the Swagger UI is shown below.

The OpenAPI document is available at the 'root' path of the API. For example, it is simply this path -

OpenAPI and Swagger allow both humans and computers to understand the capabilities of the API without access to source code, documentation or through network traffic inspection. In addition, OpenAPI documents can be used by code generation tools to generate servers and clients in various programming languages.

OpenAPI on WFS 3.0 supports multiple security frameworks. For Testbed-14, OpenID Connect and OAuth 2.0 were assessed. OpenID Connect is an authentication layer on top of OAuth 2.0, an authorization framework. OpenID Connect specifies a RESTful API using JSON as a data format. This section provides background information on OpenID Connect and OAuth 2.0 and an introduction to key technologies tested.

OAuth 2.0 provides a standard protocol for authorization. OAuth 2.0 supersedes the work done on the original OAuth protocol created in 2006. OAuth 2.0 focuses on client developer simplicity while providing specific authorization flows for web applications, desktop applications, mobile phones, and living room devices.

OpenID Connect (OIDC) provides a simple identity layer on top of the OAuth 2.0 protocol. It allows Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner. OpenID Connect allows clients of all types, including Web-based, mobile, and JavaScript clients, to request and receive information about authenticated sessions and end-users. The specification suite is extensible, allowing participants to use optional features such as encryption of identity data, discovery of OpenID Providers, and session management, when it makes sense for them.