CDB was originally developed to support training and mission rehearsal systems. These systems have constraints on both the CDB response time and response volume. It is important that:

1. we understand what constraints those requirements place on our attempts to update the CDB data model.
2. we develop a standard high-performance interface to serve these clients.
   The Octree approach explored in the Testbed 12 Streaming LIDAR Engineering Report is a good candidate for the interface.

Complete Shapechange so that it can generate XML, JSON, and JSON-LD from UML. Specifically from the NAS UML model generate GML, and geo-enabled JSON and JSON-LD.
This requires that we decide what we want geo-enabled JSON and JSON-LD to look like.

Explore alternative encodings of Vector Tiles

Expand the forms of authentication supported by TeamEngine. At a minimum support HTTP Basic and digest, TLS client certificates, and all forms of OAuth 2 authentication.

Security has finally become a common element in OGC Innovation initiatives. However, generating PKI certificates and creating the CA validation chain has proven difficult. Hours are spend working on infrastructure which should be spent on Innovation.

Establish a permanent OGC PKI infrastructure to support Innovation initiatives and Compliance testing.

TEAM Engine uses an old Saxon Library that is not longer maintain. A new version or alternative should be used.

opengeospatial/teamengine#32

WFS 3.0 for 'GeoEnabled JSON-LD' Extension (working from the work done by NGA SOM/OBP, aligning and proposing back to OGC)
Related to #12

There is no compliance test for the DGIWG Metadata Foundation (DMF). This has impacted other DGIWG compliance tests.

Maturing GeoPackage Processing (relates to D-DIL), specifically defining a practical upper limit of the GeoPackage and a structured mechanism to communicate the size of the package so that it can be managed in a work-flow to disseminate to D-DIL constrained environments. DISA, on behalf of the Joint C2 Portfolio is working an action to define the technical parameters for each of the D-DIL types and is also working with the Joint Staff to develop an authoritative definition for D-DIL to be put into Joint Pub 1-02. The current authoritative definition comes from the IS-CDD (the one for GCCS-JE) and we will be augmenting the 'denied' definition to include Cyber denial of service.

Translation: There is no single DDIL environment. DISA is attempting to identify categories of DDIL (similar to the work done on the SIF). For each category of DDIL, what are the constraints that must be put on GeoPackage in order for it to work in that environment? Deliverable could be a guidance document on deployment and use of GeoPackage.

WMTS 1.0 test was develop outside OGC. Some refracting of the test has taken place, but it still required investigation of how well matches the requirements and conformance classes in the specification.

Also to make the test available for OGC Web Map Tile Service Simple Profile.

https://github.com/opengeospatial/ets-wmts10

There are GeoPackage tests activities develop outside OGC. They need to be organize in conformance classes and package the code properly to be able to run the test in TEAM Engine.
Repository: https://github.com/opengeospatial/ets-geopackage10
Issue: https://github.com/opengeospatial/ets-geopackage10/issues/2

Improve the test so it doesn’t requires human interaction.
https://github.com/opengeospatial/cite/issues/27

With the migration to JSON, Cross Domain Guards can no-longer rely on applying rules against XML documents to make go-nogo decisions. Another approach is required.

Proposal: Leverage digital signatures to bind security markings to payloads. The signature validates the binding and identifies the entity which applied the binding. The CDG now only has to:

1. validate the signature,
2. validate that the originating entity can be trusted to apply markings to this level of data,
3. check current policy to see if data with these markings are authorized to pass (build on XACML)

There are cases where an additional level of protection may be needed. Due to on-going operations, data over a specific area during a specific time period may be protected. The CDG should be able to detect data which would violate that restriction. This would require extracting the bounding box and temporal extent of the data for evaluation against the current security policy.

It is often the case that only a small part of a data set is sensitive. Re-do the Alcatraz scenario, extending the CDG to redact sensitive areas of imagery.

More information here:
opengeospatial/teamengine#117