Audit & limitation of data liability applications

[Paul Mundt]

Hi all,

I was unfortunately not able to participate in the first meeting, so am sending an email instead.

We are developing a platform + app for connected car data services in the European market, where the end-user must always be in demonstrable control of their data. Without going in to too much detail, the platform supports fusing multiple categories of sensitive data (e.g. personal, biometric), subject to varying regulatory requirements (with variance per member state, purpose of processing, data type, etc.), and further carries out dynamic reconfiguration at the back-end, front-end, and service level depending on e.g. changes in end-user location/jurisdiction, consent, etc. Simply put, we have a Cloud-to-Edge/Edge-to-Cloud scenario where the Edge physically moves and creates different compliance requirements in the process that we have to adapt to.

On the service provider side, a key challenge is in satisfying not only end-to-end audit requirements, but also in satisfying regional audit requirements on a jurisdictional basis (e.g. as a car travels from Country A to Country B, supervisory authorities in each country are primarily concerned with data collection and processing that has occurred within their territory, and that this has been carried out in compliance with additional/variable country-specific compliance requirements, supplemental legislation, etc). It is, therefore, rather important to be able to trace the continued provenance of a given workload as it shifts around from one set of servers/microservices to others (in whole or in part) at varying times during the deployed service life-cycle.

Beyond the audit aspects, another area we see both self-sovereign identity and transitive identity approaches being useful are in the areas of limiting liability for data to actual use. Take for example the case of in-vehicle sensors/actuators - multiple services may be using sensor data in different ways, and driving different actuation events as a result. The Automotive OEM, Head unit/ECU system integrator, and sensor manufacturers, do not want to be held liable for errant actuation events caused by a specific service - while from a forensic analysis point of view it's critical to be able to disentangle events to determine which user of the data was ultimately at fault (this is also part of a bigger discussion on reform of the European Product Liability Directive to be fit for purpose in e.g. the IoT data value chain, in which the issue of liability for data "ownership" is being pushed more towards whoever happens to do the data integration/use).

We, therefore, see transitive identity and self-sovereign identity being largely complementary methodologies, and one of the next logical steps for our platform.

Best regards,

Paul Mundt
Founder & Managing Director

Adaptant Solutions AG
Bahnhofstrasse 36
82041 Deisenhofen

Phone +49 89 904 101 30 - 2
Mobile +49 176 233 88 178
Fax     +49 89 904 101 30 - 9

E-mail paul....@adaptant.io
Web    www.adaptant.io

Vorstand: Paul Mundt
Sitz der Gesellschaft: München        
Amtsgericht München | HRB 197232
Steuernummer 14310004341 | USt-ID Nr. DE284269970

[Andrew Jessup]

This is a really interesting case study. Thanks for the great detail here Paul! A few clarifying questions follow below.

Would you be interested in presenting this case study at a future meeting? We can try to hold the meeting in a time that would work better for folks in Europe.

On Tue, Nov 19, 2019 at 1:28 AM Paul Mundt <paul....@adaptant.io> wrote:

Hi all,

I was unfortunately not able to participate in the first meeting, so am sending an email instead.

We are developing a platform + app for connected car data services in the European market, where the end-user must always be in demonstrable control of their data. Without going in to too much detail, the platform supports fusing multiple categories of sensitive data (e.g. personal, biometric), subject to varying regulatory requirements (with variance per member state, purpose of processing, data type, etc.), and further carries out dynamic reconfiguration at the back-end, front-end, and service level depending on e.g. changes in end-user location/jurisdiction, consent, etc. Simply put, we have a Cloud-to-Edge/Edge-to-Cloud scenario where the Edge physically moves and creates different compliance requirements in the process that we have to adapt to.

On the service provider side, a key challenge is in satisfying not only end-to-end audit requirements, but also in satisfying regional audit requirements on a jurisdictional basis (e.g. as a car travels from Country A to Country B, supervisory authorities in each country are primarily concerned with data collection and processing that has occurred within their territory, and that this has been carried out in compliance with additional/variable country-specific compliance requirements, supplemental legislation, etc). It is, therefore, rather important to be able to trace the continued provenance of a given workload as it shifts around from one set of servers/microservices to others (in whole or in part) at varying times during the deployed service life-cycle.

Could you explain a little more what you mean by "a given workload as it shifts around from one set of servers/microservices to others". Specifically does a "workload" in this case refer to software, or data, or both?

Assuming this is about the movement of data, what sorts of guarantees do you need to be able to provide. Is it necessary for example to prove that different microservices (some running at the edge) as being able to sign or even encrypt data to verify that they have actually performed a particular operation on it? If so, are there any specific motivating examples you could share where this might be helpful? Are there cases where it is necessary to prove certain data was not moved from the edge to the cloud (for example, by encrypting it with a key that was not available to the cloud service)?

 

Beyond the audit aspects, another area we see both self-sovereign identity and transitive identity approaches being useful are in the areas of limiting liability for data to actual use. Take for example the case of in-vehicle sensors/actuators - multiple services may be using sensor data in different ways, and driving different actuation events as a result. The Automotive OEM, Head unit/ECU system integrator, and sensor manufacturers, do not want to be held liable for errant actuation events caused by a specific service - while from a forensic analysis point of view it's critical to be able to disentangle events to determine which user of the data was ultimately at fault (this is also part of a bigger discussion on reform of the European Product Liability Directive to be fit for purpose in e.g. the IoT data value chain, in which the issue of liability for data "ownership" is being pushed more towards whoever happens to do the data integration/use).

This is a really interesting use case. Would it be fair to summarize this to say that it should be possible post hoc for an forensics team to prove the provenance of a particular piece of data came from a particular instantiation of a particular service (eg. by having it cryptographically signed by that workload)? If so, what are the attributes of the service that would need to be captured?

 

We, therefore, see transitive identity and self-sovereign identity being largely complementary methodologies, and one of the next logical steps for our platform.

Best regards,

Paul Mundt
Founder & Managing Director

Adaptant Solutions AG
Bahnhofstrasse 36
82041 Deisenhofen

Phone +49 89 904 101 30 - 2
Mobile +49 176 233 88 178
Fax     +49 89 904 101 30 - 9

E-mail paul....@adaptant.io
Web    www.adaptant.io

Vorstand: Paul Mundt
Sitz der Gesellschaft: München        
Amtsgericht München | HRB 197232
Steuernummer 14310004341 | USt-ID Nr. DE284269970

--
To unsubscribe from this group and stop receiving emails from it, send an email to transitive-identi...@spiffe.io.

--

Andrew Jessup | Scytale.io | +1 (347) 855 6187 | Let's meet!

[Paul Mundt]

Hi Andrew,

My apologies for the delay in replying - I would be happy to present this case study in an upcoming meeting.

On Thu, Nov 21, 2019 at 4:25 AM Andrew Jessup <and...@scytale.io> wrote:

This is a really interesting case study. Thanks for the great detail here Paul! A few clarifying questions follow below.

Would you be interested in presenting this case study at a future meeting? We can try to hold the meeting in a time that would work better for folks in Europe.

On Tue, Nov 19, 2019 at 1:28 AM Paul Mundt <paul....@adaptant.io> wrote:

On the service provider side, a key challenge is in satisfying not only end-to-end audit requirements, but also in satisfying regional audit requirements on a jurisdictional basis (e.g. as a car travels from Country A to Country B, supervisory authorities in each country are primarily concerned with data collection and processing that has occurred within their territory, and that this has been carried out in compliance with additional/variable country-specific compliance requirements, supplemental legislation, etc). It is, therefore, rather important to be able to trace the continued provenance of a given workload as it shifts around from one set of servers/microservices to others (in whole or in part) at varying times during the deployed service life-cycle.

Could you explain a little more what you mean by "a given workload as it shifts around from one set of servers/microservices to others". Specifically does a "workload" in this case refer to software, or data, or both?

Both. Consider the case of a driver monitoring service - as the car travels from one country to another, it may be necessary to shift the processing of a data stream to a region-specific server, which may include spinning up additional country-specific resources, as well as re-directing the frontend application. While the monitoring service itself should continue without any visible interruption in service, the change in jurisdiction and backend must be appropriately dealt with and logged for subsequent localized audit. This issue comes up when we deal with biometric data in driver monitoring (such as in drowsiness detection), where the biometric part of the data set is often subject to territorial restrictions, even if the telemetry is able to flow freely under the GDPR, and service metadata via the FFD Regulation (specifically, Regulation (EU) 2018/1807).

 

Assuming this is about the movement of data, what sorts of guarantees do you need to be able to provide. Is it necessary for example to prove that different microservices (some running at the edge) as being able to sign or even encrypt data to verify that they have actually performed a particular operation on it? If so, are there any specific motivating examples you could share where this might be helpful? Are there cases where it is necessary to prove certain data was not moved from the edge to the cloud (for example, by encrypting it with a key that was not available to the cloud service)?

 

At the moment we deal with service adaptation in response to jurisdiction shifts in three different ways: (1) disabling the storage of sensitive category data from out-of-country data sources (as in the case of the biometric data, as above) - in this case, the German server would reject the Austrian-relative data, for example. (2) Shifting the frontend connection to a backend capable of receiving the data, which can take over processing in order to provide service continuity (this could either be a country-specific cloud instance, or a physical edge gateway within the vehicle, each with their own set of microservices); and lastly (3) Notifying the application that no suitable backend instance exists, and to spin up its own lightweight version of the service with whatever capabilities it has on hand. 

While we have mechanisms in place to make sure data is encrypted and only authorized services / purposes of processing are able to access what they need, it would, of course, also be useful to attribute some kind of transitive encryption across the data life-cycle, derived from the initiating service identity. In this case, the purpose of processing is a key consideration - a driver monitoring service carrying out its core function of monitoring and alerting a driver will, in accordance with the user-defined consent settings, have rather different data access than if it's gathering statistical data for service improvement purposes (in our case we derive different access scopes / grants for different purposes of processing from a generated consent receipt, which we encode as a JWT token that accompanies the workload. This is subsequently analyzed and decided on by various OPA rego policies at different levels in the deployment hierarchy - some static, some dynamic).

Beyond the audit aspects, another area we see both self-sovereign identity and transitive identity approaches being useful are in the areas of limiting liability for data to actual use. Take for example the case of in-vehicle sensors/actuators - multiple services may be using sensor data in different ways, and driving different actuation events as a result. The Automotive OEM, Head unit/ECU system integrator, and sensor manufacturers, do not want to be held liable for errant actuation events caused by a specific service - while from a forensic analysis point of view it's critical to be able to disentangle events to determine which user of the data was ultimately at fault (this is also part of a bigger discussion on reform of the European Product Liability Directive to be fit for purpose in e.g. the IoT data value chain, in which the issue of liability for data "ownership" is being pushed more towards whoever happens to do the data integration/use).

This is a really interesting use case. Would it be fair to summarize this to say that it should be possible post hoc for an forensics team to prove the provenance of a particular piece of data came from a particular instantiation of a particular service (eg. by having it cryptographically signed by that workload)? If so, what are the attributes of the service that would need to be captured?

That would be a fair characterization, yes. Things we are most concerned about here are: data subject identifier, timestamp, initiating service identity, data types involved, purpose of processing, location of processing, etc.

I hope that clears things up a bit better!

Best regards,

-Paul.