Peter Steiner’s 1993 cartoon, as published in The New Yorker

“On the Internet, nobody knows you’re a dog.” That’s how the caption of a 1993 New Yorker cartoon by Peter Steiner reads, depicting a dog with a paw on the keyboard talking to a canine companion sitting on the floor. It’s a light-hearted take on the anonymity and freedoms afforded by being online. But for how much longer will it be true?

The sovereign cloud movement prizes control, compliance, and traceability. As it gathers steam in the EU and elsewhere, it’s putting pressure on the issue of identity management and digital anonymity. We are facing a period of significant upheaval as developers look to ensure proper authorization in the context of new legislation and federated login systems.

Below, we’ll get into how the rise of digital sovereignty will affect — and is already affecting — auth standards, how compliance could impact API access, and what the future of identity protocols might look like as the need to adapt to regional restrictions increases.

Sovereign Clouds, Silver Linings?

In March 2025, TechCrunch described a movement among European Union lawmakers to “shrink reliance on foreign-owned digital infrastructure and services to bolster the bloc’s economic prospects, resilience, and security in increasingly fraught geopolitical times.”

The move would indicate a switch to “a quasi-war footing by committing to support ‘sovereign digital infrastructure.'” Although it’s difficult to imagine exactly what that looks like in practice — one doesn’t simply create EU alternatives to US tech giants like Uber, Meta, and Netflix overnight — the move is a microcosm of a larger movement that has been brewing for a while.

On a broader scale, national governments appear increasingly concerned about user data being sent and stored offshore. For a high-profile example of this, just look at the ongoing battle between the US government and TikTok (or its recent €530 million fine from the EU).

Broadly speaking, a sovereign cloud is an environment designed to comply with the regulatory demands and security requirements of a particular country or region. An EU sovereign cloud, for example, would be required to comply with GDPR and store/process data within an EU country. A California cloud service would need to comply with the CCPA, and so on.

Amazon has already launched AWS European Sovereign Cloud, and other major providers, such as Google, Oracle, and Microsoft, are similarly engaging with sovereign clouds. (It’s worth pointing out, of course, that all four of these companies are American in origin, which many would argue sort of undercuts some of the aims of the digital sovereignty movement.)

Cross-Border Compliance

So, what, in the context of digital sovereignty, happens when user data needs to be transferred between services in different jurisdictions? That’s where things get a bit trickier. However, it’s worth pointing out that many existing and incoming data regulations are modeled on the EU’s GDPR.

In that respect, API developers can take a big step toward wider compliance by embracing some of the best practices associated with GDPR: strict access controls, encryption, data minimization to limit the impact of data breaches, logging and internal audits, and so on.

Still, there are some significant implications for developers to think about here. Interoperability is one important example of this: within the EU, for example, member states need to ensure compliance with eIDAS regulations and conform to a common assurance level.

For relationships between API providers and customers located further afield, trust frameworks may need to be reworked entirely. Without shared standards like eIDAS, there’s no guarantee that an identity provider’s API will be automatically deemed trustworthy by other systems.

In the meantime, we might well expect to see the emergence of regional single sign-on silos — each of which will, by design, be optimized for compliance as opposed to ease of use for end users. Subject to different regulations, these silos will require specific information to function properly and may require government treaties to work as they do now.

Evolving Identity Standards

Many identity protocols like OAuth 2.0 and OpenID Connect were built to be flexible without compromising on security. With the introduction of regional identity providers like itsme (Belgium), DigiD and iDIN (Netherlands), and SwissID (Switzerland), existing protocols that have long been seen as industry standards have new hurdles to clear. As mentioned above, without significant revamping, SSO systems as we know them may begin to fail.

It’s possible that self-sovereign identity (SSI) and decentralized identity (DID) markers could take on a larger role in this brave new world. Truvera, by Dock Labs, already issues verifiable credentials via API that are W3C-compliant and leverage standards from OpenID, IETF, and DIF. They, or another provider, could potentially integrate standards from — or build integrations with — regional identity providers to further boost interoperability.

For federation to work effectively, however, there’s a real possibility that OAuth tokens and the like will need to carry additional metadata, including information about proof of identity or residency, location of token issuance, and so on. Not a big deal for the average user, perhaps, but an enticing target for cyberattackers looking for data they can use to extort or blackmail.

It’s fair to say that this shift may be a microcosm of a broader trend in online identity: as of 2025, almost half of all US states require viewers of adult content to verify their age using government-issued ID documents. It’s an idea that will seem innocuous to some — until, perhaps, information about their viewing habits is leaked to friends or family members.

And there may be an even darker side to this drift toward increased data collection.

Anonymity Under Pressure?

Google recently handed over data of 61 searches made by eight accounts to authorities in what critics called a “digital dragnet.” In this case, the outcome was positive: it resulted in the identification of three suspects of a 2020 fatal arson attack. But Justice Monica Marquez argued that “such a wide-ranging search of a billion Google users’ search history without a particular target is exactly the kind the Fourth Amendment was designed to stop.”

As for the individuals associated with those other accounts? They were in the wrong place at the wrong time and should, presumably, count themselves “lucky” they weren’t hauled in for questioning. This example may not relate to data sovereignty directly, but it’s an example of why closer ties between identity markers and geographical location may be cause for alarm.

Online anonymity has long been seen as a right, and some of the aims of sovereign cloud initiatives — the availability to only authorized and regionally approved entities, knowledge of who is accessing data and from where, and so on — are directly opposed to anonymity, which will almost certainly create points of friction.

Another Direction: Enhancing Security

On the other hand, the sovereign cloud movement may take us in another direction entirely. Where ideas of open federation and “global identity” are challenged, the opportunity exists to create new systems that are more secure, grounded in the idea that anonymity can/should be maintained (even across borders) and reinforced with the appropriate architecture in place.

Indeed, many of the techniques and technologies that can be used to mitigate risks — such as zero trust architecture, zero-knowledge proofs (ZKPs), and decentralized identifiers (DIDs) — are closely associated with APIs. In fact, it’s easy to imagine a world in which APIs might be used at scale to verify and authorize access without breaking anonymity. In other words?

They might just be the secret weapon for keeping those dogs on the internet.