The idea of a reference implementation supporting an offline verification workflow was entertained. Looking at the OMSDK I feel like a possible path would be to create an example or reference VerificationClient (see page 53 of https://s3-us-west-2.amazonaws.com/omsdk-files/docs/OMID_API_GA_v1.pdf) which potentially timestamps and signs tracked ad sessions in case the data inherent to the ad session isn't enough (tbd, requirements to be provided by verification providers) and send the data to some "store and forward system" on the aircraft which relays it to the ground.
Such a system could be leveraging a persistent pub/sub protocol, e.g. the lightweight MQTT which is very well proven in the IoT area? The client would be the relay server on the aircraft (maybe a MQTT broker with a bridge: http://www.steves-internet-guide.com/mosquitto-bridge-configuration/) and the "final" broker could sit in the cloud or anywhere else on the ground. See http://mqtt.org/ and "Persistence" paragraph in https://thenewstack.io/messaging-reliability-persistence-mqtt/.
The proposed reference implementation of the VerificationClient would be according to the OMSDK JS API, could implement message signing via https://github.com/PeculiarVentures/PKI.js, and leverage https://github.com/mqttjs to implement the MQTT part within the VerifciationClient and submit messages to a persistent MQTT broker on board the aircraft for further distribution to the ground when connectivity allows.
The idea of a reference implementation supporting an offline verification workflow was entertained. Looking at the OMSDK I feel like a possible path would be to create an example or reference VerificationClient (see page 53 of https://s3-us-west-2.amazonaws.com/omsdk-files/docs/OMID_API_GA_v1.pdf) which potentially timestamps and signs tracked ad sessions in case the data inherent to the ad session isn't enough (tbd, requirements to be provided by verification providers) and send the data to some "store and forward system" on the aircraft which relays it to the ground.
Such a system could be leveraging a persistent pub/sub protocol, e.g. the lightweight MQTT which is very well proven in the IoT area? The client would be the relay server on the aircraft (maybe a MQTT broker with a bridge: http://www.steves-internet-guide.com/mosquitto-bridge-configuration/) and the "final" broker could sit in the cloud or anywhere else on the ground. See http://mqtt.org/ and "Persistence" paragraph in https://thenewstack.io/messaging-reliability-persistence-mqtt/.
The proposed reference implementation of the VerificationClient would be according to the OMSDK JS API, could implement message signing via https://github.com/PeculiarVentures/PKI.js, and leverage https://github.com/mqttjs to implement the MQTT part within the VerifciationClient and submit messages to a persistent MQTT broker on board the aircraft for further distribution to the ground when connectivity allows.