What does a data request API exactly look like? In this chapter, we cover goals and the means that are put forward for achieving these goals.
GoalsAuthenticationAPI FormattingDescribing DataThe Open Data Rights API is aimed at improving the status quo of exercising data rights. In this proposal, we clarify the goals of the initiative. Further development, cooperation and implementation efforts are made according to these goals.
Organisations must provide a form of processing data rights. We strongly believe that electronic means for doing so constitute the best way of doing so. By providing common patterns and best practices for creating these electronic means, we aim to increase adoption and widespread use of data rights systems, not only in Europe or companies covered by the GDPR, but universally.
Adoption by organisations should be as easy as possible. The specification must support the 80% use case, while facilitating th 20% use case. Documentation should be high-quality and plentiful, not only covering the specification, but implementation from different perspectives. Moreover, the documentation should provide guides for going through the process of supporting data rights as a whole, not only covering the implementation of a data request API.
Exercising data rights should be feasible for any citizen. Finding out how citizens can exercise their rights and facilitating that should be as easy as humanly possible. The aim of these systems should therefore focus on human aspects of data rights.
Personal information should be stored, processed and be made available securely. By providing well-known and tested frameworks for facilitating data rights, we aim to make the process of exercising data rights more secure.
We believe that exercising data rights is an important aspect of digital citizenship. The law allows citizens to verify agreements that are made with an organisation. As this process that is based on trust, we place emphasis on that a delightful process increases this bond of trust that exists between a data subject and data processor. Therefore, increasing ways of facilitating delight in user interaction with regards to data rights is a must-have.
Data rights provide an opportunity to organisations to demonstrate their commitment to their users privacy. As awareness on the necessity of such rights rises with citizens, the neccessity for organisations to address those rights is evident. By promoting easy, accessible and easy-to-implement standards we aim to facilitate the sorts of conversations in organisations that increase this commitment to user privacy.
Data privacy increasingly is becoming a right that many citizens are concerned about, but feel increasingly powerless over. Data rights are handles that facilitate better reflection on what actually is happening, as well as providing citizens power to change their situations. By making exercising data rights easy, we aim to stimulate societal discussion on what personal information means to individuals. By making data rights accessible, we aim to increase the awareness that citizens have on what power they have to command their personal information.
Loading...
Loading...
A large aspect of both GDPR compliance and user understanding of data being processed comes down to the question what data types are being processed. With this being a central part, the Open Data Rights API needs to define semantics describing data types as well. Fortunately, major strides have already been made in the department of data semantics in the form of schema.org and JSON-LD. The Open Data Rights API adopts both for the purposes of providing data semantics.
These semantics are broken up between how data processing is described, as well as how the eventual data is described in a data archive.
Data is processing is described as part of the /data and /data/me endpoints. The former endpoint describes the data processing practices for the organisation at large. Both endpoints are described in detail in the API documentation.
For the organisational practices, all possibly processed data types must be listed. For each data type, organisations must indicate the following:
What schema.org / custom context the type is based on
The processing ground for this type of information
Whether the data may be erased by the user
Whether the data may be rectified by the user
A human-readable description for the data type.
Lastly, the /data/me endpoint constitutes an array of all context-based data types that are being (possibly) being processed in connection with the authenticated user.
When data is eventually exported using the API, the data must be made available in a particular format. In the case of the Open Data Rights API, this data is formatted using JSON-LD and schema.org definitions. Organisations may create many files containing data, as long as data is always formatted using JSON-LD. Additional file types, such as images, videos and other non-structured media, must be included as well. Any included non-JSON-LD files must be referenced from at least a single JSON-LD file. The archive must be ZIP file.
The archive may follow a self-defined internal structure, except for a a folder at the root level with the open-data-rights-api name. This folder contains another folder called schemas, in which each JSON-LD @context property that is used is archived as well. In this folder, each schema is contained in a seperate JSON file, of which the content exhaustively describes the schema. Also, two files called data.json and data-me.json describe the output for the respective endpoints at the time of archive creation.