API Security & Identity

Democratizing Data Regulations with APIs and (Smarter) JWT tokens


A century after the dismantling of Standard Oil and in a world where data is the new oil, how can we replace the Big Five of Tech that now hold the monopoly? To what extent can these companies’ models be decentralized and what technical means can be used to this end? In other words, how can a company with a silo mentality be transformed into a company with a culture of peers?

To publish is to exist: transitioning from an on-demand to an in-demand economy

Digital platforms are based on the principle of information asymmetry which allows them, as shown by the economics Nobel prize-winners Aberkov, Spence and Stiglitz, to acquire greater value than others on the market. By capturing the attention of large numbers of users in this way, they are in control of the information relating to demand and thus position themselves as intermediaries with their offers. For example, a platform such as Uber monitors the demand of users, knows where they are, where they want to go, and at the same time knows the number of drivers available, the traffic, the most congested areas, etc. Uber has a full understanding of the level of demand and acts as the intermediary for drivers who obtain their clients exclusively via Uber’s centralised application and must relinquish 25% commission on the final price of the fare in exchange for the service provided.

If, in the future, we move to an in-demand economy (thanks to Mike Amundsen to coin that term and idea in a postconference late discussion), where buyers declare their intentions, needs and budgets on the market, and suppliers offer to meet them without an intermediary platform, an Uber customer would then be in a position to ask: “I have €12 and I want to go from the centre of Paris to the north of the city. What driver can take me?” In this scenario, all drivers can simultaneously bid against each other and/or respond to demand on the network without being controlled by any platform. This would transform the whole relationship with platforms and would create a beneficial effect on the market. The price would no longer be decided by the platform but would be based on actual supply and demand, and would no longer be subject to the 25% commission that Uber takes between supply and demand.

Decentralisation cuts out the platforms in their capacity as middlemen. Following the example of the initial success of the Web, we need an economy of publication. When the Web burst onto the scene, each network user was free to easily publish webpages and to navigate from page to page via all the hypertext links, which were all discoverable due to the open protocols designed for such purpose. Let’s consider the example of social networks. We publish our data on Facebook and its closed network because the platform ensures discoverability. The Californian company thus monopolises our data in exchange for a free service, analyses it and makes it available to advertisers via its advertising sales house, using an asymmetrical model. If we had the means to easily post our photos or messages without using platforms but by directly publishing on the open network, Facebook would then be dependent on our willingness to share our data and we would retain usufruct with third-party applications.

APIs as a lever of the great replacement

To publish something means to make it public so that it becomes discoverable. To avoid monopolisation by platforms, users must be given back the technical means of publication, just as in the era of the Web, so that users can make their contributions more accessible. In this digital age with its programmable economy, data is published via interfaces called APIs (Application Programming Interfaces). These are programming interfaces which allow software to communicate with other software in an automated, programmable manner.

APIs therefore allow an application to recover or send data to another application. For example, the “Connect With Facebook” button allows an application to recover a user’s data from Facebook with the user’s consent. The application does not therefore have to ask for the surname, first name, date of birth and list of friends etc., as it directly recovers them via its API. Having the choice of whether to give or not give a third-party application the right to access our data is a mighty power. However, when we provide our data to Facebook, we attribute this right to them and this concentration of value contributes greatly to the creation of the de facto monopolies which platforms have become.

There are two possible solutions for turning the situation around: either a top-down solution which requires platforms to ensure API neutrality, which has the advantage of creating a strong impact in a short time without actually reversing the existing business models, or a bottom-up solution which facilitates users’ right to be represented by an API, which, while taking longer to put in place and having to cover more ground, gives all the power back to the user.

API neutrality

API neutrality requires platforms to allow indiscriminate access to their APIs with user data. Any third-party application, therefore, even a competing one, would be entitled to access the data if it had the user’s consent. In the past these platforms prevented many start-ups from accessing their APIs as they had a competing business model, to the detriment of the choice of the user, and this is where the issue of neutrality arises.

The first industry to be bound by API neutrality will be the banking industry. Indeed, as of September 2019, all European banks will be bound by the PSD2 European regulations to indiscriminately provide access to their APIs to any registered company which requests this on behalf of a user. This is a major reshuffle: any start-up — even a competing bank — will be able to request the complete import of a client’s account data. It would simply be a matter therefore of extending this requirement of API neutrality to the Big Five.

The other solution, derived from the Collin and Colin report, would be to levy digital VAT on companies which do not redistribute the data via open APIs. The company would pay a digital value added tax on the data only if it is the last consumer of this data. If the company redistributes it to others via open APIs, it would be exempt from this tax.

APIs for all

The other solution, a decentralised one, is the right as an individual to be represented by an API. As Albert Wenger says, this software interface would be our algorithmic representation in the digital world and would manage our contractual interactions with platforms. This would position the individual at the centre with total control and power.

Personal data would stay with users and platforms would have to consult their APIs, requesting access to users’ data. This would resemble a sort of Dropbox, hosted by us or hosted on a domain owned by us, with data readable by humans and software robots. Depending on our predefined choices, applications would or would not have the right to gain full or partial access. And if we share data, we retain control as we can revoke access to it at any time. This is notably the project of Tim Berners Lee, inventor of the World Wide Web, with his SOLID project, and the projects of the Indieweb and Mydata communities.

But in this case, how do we retrieve and manage the data?

Using the GDPR lever as the legal basis for the overhaul of the data landscape

All of our clicks, comments, photos, book or restaurant reviews, in short all of our interactions with digital platforms, constitute digital labour. This data represents flows that are accumulated and stored as digital capital by platforms; it has created incredible levels of value for them.

These platforms have accumulated this data over many years, but Article 20 of the GDPR will see a major shakeup of the status quo. Each user will have the right to portability of data, i.e. to reimport it in order to share it with other platforms, thus feeding them with data and enabling them to provide an equivalent level of service to the Big Five. In essence, reimporting and reinvesting one’s digital capital to data-fund other key players.

Imagine a user who has retrieved all of their past purchases and requests made on Amazon in their private data storage facility, made available via their personal API. A company such as Fnac.com could request access to the user’s API to recommend better products to them, thereby gaining ground on Amazon’s big data. This would create a new power balance in favour of users, who would decide which platform they want to give information to, and in return for what experience.

On the condition that this right is accessible to all.

Popularising, Automating, Tokenising and “APIing” the GDPR

The implementation of the GDPR has not been accompanied by the technical means to apply it. Nevertheless, a new generation of tools is emerging to manage the relationship between platforms and users in a programmable manner via open and decentralised APIs. These tools enable:

  • Automation of the GDPR, whereby users are able to automatically exercise their access rights to data or to portability (Article 20.1). Requests for data portability are sent regularly and automatically by email or post to the Data Protection Officer of every company for users to recover their personal data.
  • API-fying data deriving from the GDPR. This is where unified interfaces are created for developers so that they can easily understand and integrate these APIs in their applications, which are as well created and as easy to integrate as the best APIs on the market, with an attractive developer experience, in order to access users’ data. These APIs must be used by applications but also by platforms such as Facebook, Google and others to integrate users’ data.
  • Tokenising the GDPR, which consists of producing an authorization token from any interaction or exchange of data between a user and a platform. This token contains an official GDPR contract, which is cryptographically secure and legally enforceable. It is necessary for users in order to monitor the accessing and revocation of their data by platforms. The law becomes code, and the code becomes law.

Relationships between platforms and users are usually created by simple permission tokens, which are merely a randomly generated character string with no intelligent information inside (such as in Google or Facebook Connect which use the OAuth2.0 authorization protocol). In this case, each permission token is an smart JWT token which contains as body a real GDPR contract, with all necessary legal notices such as:

  • The uses of the data in the context of the contractual necessity
  • The uses of the data in the context of the consent
  • The uses of the data in the context of legitimate interests
  • The recipients’ list of the data
  • Tue duration of the data storage
  • If the data will be used for profiling, will be transferred outside the European Economic Area, will be used for automated surveillance etc…

In the event that these contracts are public, it is then easy to check them to find out whether a platform has legally had access or not to the data. Users are able to see which contracts and permissions are active via a simple decentralised interface and are also able to revoke them in a single click.

“We only destroy what we replace” said Danton

Replace the Big Five GAFAMs ? If only it were that simple. Those who have tried to replace the existing platforms in a decentralized way have often failed in their attempts. This is because decentralization is not an end in itself: its cost on the user experience must be offset by its beneficial effects. Will users accept having to install programmes on their computers for each usage? Or paying for hosting and bandwidth? Will they understand how to use a private key? And what benefits will they seek in return? All of these questions must be answered if we truly want to revolutionize our relationship with platforms and keep the individual at the centre of the agenda.

Mehdi Medjaoui
Mehdi Medjaoui is the founder of the worldwide apidays conferences series he started in 2012 in Paris. Mehdi is highly involved in the API community and API Industry, as author, lecturer, consultant and investor in the API tooling space. His industry research involves publishing and maintaining the API Industry Landscape and the yearly State of Banking APIs. In 2018, he publishes as co-author "Continuous API management" (O’Reilly) and begins as lecturer and invited professor at HEC MBA and EMLyon Executive MBA. In 2019, Mehdi become H2020 European Commission expert to lead the APIS4Dgov study on public sector and government APIs. As entrepreneur, Mehdi co-founded in 2014 OAuth.io, an API middleware for OAuth intégration used by 40,000+ developers that has been acquired in 2017. Mehdi’s new venture GDPR.dev develops a Personal data API framework and protocol to democratize data regulations usage for mass users and compliance for applications developers, making GDPR programmable.

APIdays | Events | News | Intelligence

Attend APIdays conferences

The Worlds leading API Conferences:

Singapore, Zurich, Helsinki, Amsterdam, San Francisco, Sydney, Barcelona, London, Paris.

Get the API Landscape

The essential 1,000+ companies

Get the API Landscape
Industry Reports

Download our free reports

The State Of Api Documentation: 2017 Edition
  • State of API Documentation
  • The State of Banking APIs
  • GraphQL: all your queries answered
  • APIE Serverless Architecture