Defining ‘My Data’ Portability and Interoperability
There seems to be a growing recognition in the privacy/ data empowerment spaces that data portability and data interoperability across service providers are important things.
I agree, but am concerned that whilst both words trip of the tongue reasonably easily, defining what precisely we mean by them and thus what we want to emerge is a lot more tricky. With that in mind, here is a statement of outcome requirements from the various perspectives that was worked up in the Kantara Information Sharing Work Group a few years back.
- As an individual, I want to be able to pick up my data from one personal data service (locker etc.) and drop it into another with minimal fuss
- As an individual, I want to be able to have applications run on my personal data, even when it exists in multiple different services
- As an individual, I want the apps I had running on my personal data in one locker service, to work when I move my data to another one
- As an application developer, I want the apps I build to run, with minimal overhead, across multiple personal data services
- As an organisation willing to receive and respond to VRM/ Me2B/ MyData style data feeds; I don’t want to have to set up different mechanisms for each different provider
- As an organisation willing to provide/ return data to customers as part of our proposition to them; I want to be able to make this data available in the minimum number of ways that meet the users needs, not a different format for each personal data service provider
- As an organisation willing to provide/ return data to customers as part of our proposition to them; I don’t want to have a different button/ connection mechanism for each personal data service provider on the ‘customers signed in’ page of my web site.
Does that statement of requirements still feel about right? If not then ping me a note and i’ll update them.
These requirements were written around the time of the UK Midata project, and when various other data portability buttons (green button, red button and blue buttons so far) were emerging as localised or sector specific responses to obvious data portability needs.
Thinking about these requirements then in the emerging world where MyData is a stronger theme, e.g. the endorsement in the EU Data Strategy; I think we need a carefully constructed plan if we are to move beyond that localised and sector specific model. My thinking on how we put that plan together is as below:
- These solutions will not be reached by putting organisations (the supply side) in charge of the process. No amount of arm twisting and threatened regulation will make that work in any way other than slowly and sub-optimally. We have plenty of evidence for that in UK at present, see this review of the original UK MiData programme dating back to 2014, and I don’t see any sign of uptake in data portability (as defined in that project) use since then.
- These solutions will be reached by interested, data-skilled individuals and representatives of customer groups getting down into the weeds and specifying data fields and data formats (so the request to a supplier would be formed not as ‘can I make a data portability request please’, but as ‘here is precisely the data i’d like you to provide me, and the choice of formats which i’ll accept’). So I think that means a) figure out the use cases to be tackled, b) get the interested parties in a room with a whiteboard to list the fields required to make those use cases work, c) publish those data fields in a machine readable format (most likely JSON-LD) for the community to review, build on, improve and agree as a draft standard, d) build prototypes to show this data portability and inter-operability working in practice, e) put those standards through a relevant working group at a standards body (e.g. Kantara Information Sharing Inter-operability). For example, here is an illustration of such an online schema derived from the original MiData use case (home energy switching).
- Talk to existing intermediaries (e.g. comparison shopping sites) and service providers about this new model; whilst also flagging the approach up into those working to deliver the EU Data Strategy (which has many strands relating to data portability and interoperability).
- Get some basic human-centric services up and running that demonstrate the art of the possible.
There is at least one way to deliver all of the above relatively easily. The use of JSON-LD provides the necessary data documentation and mapping layer; the wider JLINC protocol gives the additional benefits of transparency, data portability co-management of data and the full audit log.
I’ll talk more about the about at the upcoming MyData Community meeting in Amsterdam with anyone who wants to dig into data portability and inter-operability in more detail.