I’m starting off with a German startup called Helmit, which has Trust Level 2 in our Registry (the highest level), and proudly displays the DTI Badge of Accreditation on its website. Their tools address an issue that is highly topical and certainly one that is front of mind for me – how do we keep our kids safe online?

Banning, or age-gating, social media for children is the most extreme policy option that is gaining traction in various countries, having been implemented in Australia already, with similar policy proposals announced in other jurisdictions including the UK and the EU. As a parent of two young children I understand the reasons for this tough approach, but then as a policy professional I can’t unsee the implementation challenges and potential unintended consequences.

Toward the other end of the interventionist spectrum, there are various parental control tools that help parents moderate and monitor their children’s online activity, many of which enable parents to read the messages their child sends and receives. As children get older, they will understandably seek ways to circumvent this privacy invasion, which will undermine the protection.

Leonardo and Alexander – Helmit’s co-founders – are pioneering a different path. Their AI-powered child safety and parental control app is designed to actively combat digital violence while preserving children’s right to privacy. This balance between online safety and privacy is made possible through data portability.

Through various data portability integrations, such as Meta’s Export Your Information (EYI) tool, Helmit’s users can import their children’s social media account data (with appropriate prior authorisations of course) to an AI scanning tool stored locally on device. Rather than reading through all their children’s online interactions across multiple platforms, the AI tool does it in real time and notifies the parents only when a threat has been identified – for example, when it detects signs of behavioral threat patterns, such as adult grooming tactics, coercion, or severe bullying.

When combined with AI technology stored locally, portability can help empower parents to keep their kids safer online without invading their personal life. I’m hopefully still a good few years away from facing this problem myself, but I am reassured to know that there are innovative companies like Helmit developing solutions that can complement the regulatory debate.

Where AI abilities come from

Most AI chat models can only generate text. If you send the message “What’s the weather?” directly to an AI model, the response will almost certainly not be helpful. By default, the model doesn’t know where you are, what day it is, or any current or predicted weather conditions for any location. It might hallucinate conditions, or hopefully reply that it can’t help with your request. So how do chatbots like ChatGPT and Claude manage to answer these requests helpfully, not to mention edit files, search the web, and all the other things AI agents are being used for today? The answer lies with the program used to run the model.

When you chat with an AI model, you use an interface like a website (chatgpt.com, claude.ai, gemini.google.com, etc) or an app on your device (Claude Code, Claude Desktop, ChatGPT Work, Codex, etc). Most of these interfaces do much more than just forward your message to the model and show you the response. They also inject additional text as context for your message.

For example, when you send “What’s the weather?” a chatbot interface might add context like, “The user is located in New York City. The date is Monday, September 14, 10:18 AM.” Many interfaces also include a list of “tools” available, which represent software designed to be invoked by the AI model. Modern AI models have been trained to watch for available tools and respond with special text to invoke them. Tools are advertised to the model along with other context, like in this simplified example:

The user sent: "What's the weather?"

The user is located in New York City. The date is Monday, September 14, 10:18 AM.

You have access to tools you can use to answer the user's question:

Tool: Weather search
Description: Search for weather conditions for the provided location (city, state, country)
Use: Respond with "search_weather(<location>)"

If the model wants to use a tool, it’s been trained to respond with special text, along with any data necessary to use the tool. In this example, it might respond with something like, “<invoke_tool>search_weather("New York City")</invoke_tool>.” The chatbot interface intercepts this response, and rather than showing it to you, performs a weather search for New York City. The results of that search are sent back to the model, which can finally respond to your original “What’s the weather?” message based on actual weather data.

This is how AI models actually do stuff, but there’s two problems:

• With so many different chatbot interfaces (we listed 7 above and barely scratched the surface!), how can third-party service providers sustainably create integrations for them all?
• More importantly, how can users and service providers actually add the integrations they want to use without relying on the interface developers?

As we’ll see, the Model Context Protocol is designed to help with both.

The Model Context Protocol

The Model Context Protocol is an open standard for integrating custom tools into AI chat interfaces. It defines a client/server relationship and communication protocol which enables AI chat interfaces to provide models with access to external services and tools.

Most popular chat interfaces can already act as MCP clients, including claude.ai, Claude Code, Claude Desktop, ChatGPT work, Codex, and many more. Organizations and software developers can create MCP servers for their services to make their functionality accessible to these clients. For example, GitHub has created an MCP server to allow AI models to interact with its services. Users can add any MCP servers they like to whichever MCP clients they use to give AI models new functionality.

MCP clients handle getting a list of tools and instructions for their use from MCP servers, according to communication specified by the Model Context Protocol. The clients then include that information along with a user’s messages to the AI chat models, just as they would with the “weather search” tool in the previous example. If the MCP client detects an invocation, it again communicates with the MCP server according to the MCP specification. When the server recieves the request, it runs whatever code the server’s developers wrote for the requested tool, and returns some response back the the MCP client. That response is usually sent back to the model, just like in our weather example. MCP even defines optional authentication methods, allowing AI models to access data and take actions using the user’s authorization.

Since MCP is just a protocol definition, MCP client and server developers simply need to implement their respective sides of the relationship according to the MCP specification to make their software work together. Offical code libraries exist to aid developers in making their software compatible with MCP. During our development of the Schemas.Pub MCP server, these libraries allowed us to mostly skip thinking about the details of the protocol and instead spend our time on the actual functionality we wanted to make accessible to AI.

MCP and personal data

While our work adding MCP support to Schemas.Pub focused on public data, the experience helps us understand MCP’s potential for personal data. Companies have already added support for managing personal data through MCP, and we’re especially interested in exploring if MCP can facilitate personal data portability between services. It may be possible to transfer personal data between services by connecting AI agents to the services’ MCP servers, then instructing the agents to copy data from one service to another.

That said, providing AI agents with personal data management capabilities also involves privacy and safety considerations. It may add AI service providers as another party with access to personal data. Additionally, AI agents have potential to mishandle personal data, especially if influenced by malicious attacks such as prompt injection. As MCP adoption increases, navigating these risks will be essential to ensuring the technology empowers users without compromising the privacy and security of their personal data.

The Model Context Protocol is an example of the power of open standards. MCP enables independent developers to build interoperable software which gives users the freedom to extend AI model functionality through the interfaces and services they choose. This aligns well with our fourth guiding principle for AI calling for “open processes” when AI services communicate with other services.

We wanted to help empower AI-assisted users who may not have coding experience to take advantage of the portable data schemas on Schemas.Pub. By supporting MCP, we only had to write one AI integration, which saved us a significant amount of time. And yet, our single integration serves the maximum number of AI chat interfaces we could practically support, meaning users get to choose whichever compatible client they like. This exemplifies how open standards like the Model Context Protocol can be beneficial for everyone.

Following that post, I continued further down the rabbit hole. I spoke with experts across the ecosystem to test a simple ambition: could we bring the sector together to define what “good” actually looks like for the user. The feedback has been remarkably consistent and supportive:

“Don’t reinvent the wheel – this is precisely what the W3C is there for.”

As someone with a policy background rather than a technical one, I’ll admit the prospect of engaging the W3C is a little daunting. I have worried that I wouldn’t be welcomed by the community as I don’t speak Python or Java, and that I could become bogged down by the institutional processes. Neither of these worries were well founded (so far at least!).

With thanks to friends from the web community that have been supporting me – I won’t name them but they know who they are – I’ve officially submitted a proposal to establish the first W3C Community Group for Browser Data Portability.

My primary goal for the group is to build consensus among browser implementers on what a high-quality data transfer experience looks like for users. Ultimately, we aim to publish a W3C Community Group Report establishing shared principles for import and export functionality, leading to more consistent and reliable outcomes for users across different devices, platforms, and browsers.

A principles-based, non-normative approach will be essential for this work. It makes no sense for me to barge into the W3C community and start dictating the precise way that all browsers should implement their user switching and data transfer journeys. Not least because this is one of the key areas that are sovereign to browsers. But also, critically, there is just too much water under the bridge, with individual product design tied to legacy architecture, and in some cases, shaped by specific regulatory obligations.

By building consensus on the what, we preserve the space browser implementers need to solve the how for their specific platforms and user bases.

If you are a browser implementer, a W3C community member, or a policy professional interested in data portability, we want your input. Check out the Community Group proposal, join the conversation, and help shape what comes next.

See you there!

The fundamental AI data portability concern that has motivated me for nearly three years now remains: in the AI future, will people be empowered or held hostage by their personal data? In that 2023 article, I said that models would become commoditized, and thus the ability of personal data to provide a personalized experience would be a key value proposition for AI services. The context I had in mind when writing that piece was providing personal data directly to a model; thus, portability meant being able to move personal data from one model provider to another.

Where does personal data sit today? With agents, the locus of where and how we build infrastructure to promote empowerment through personal data may have shifted. From an architectural perspective, an agent is a model plus a harness (see Vivek Trivedy or Databricks). A harness is everything except the core trained inference engine. That includes tools that execute code and run terminal commands and look up information in databases and online; memory beyond that in the current context window, including user specific preferences and an understanding of interaction history; workspace details including files, system environments, and other context; and guardrails, any policies or permissions that are meant to limit action. Harnesses both condition and load context before the model runs – context windows being the only form of input to LLM inference other than model weights – and review and modify its outputs before the user sees them.

Under this definition, perhaps we’ve been talking about agentic AI portability for the entirety of our time talking about AI portability! As our focus is on an individual’s personal data, which is gained through processes apart from inference and stored in some form of long-term memory (whether in the sense of a hard disk or in the sense of an AI memory), that data has always been something a bit separate from pure LLM operations. It has always been loaded into the LLM’s context window for inference by a harness structure of some form; and that combination, then, is an agent. When those functions were blurred into the service offered by the model provider, the terminology blurred similarly.

These terms can be used loosely in practice. For example, Claude Code is described in Anthropic’s documents as an agentic harness around Claude. Is it a harness or an agent? Is Claude part of the agent or something separate from it? Also, doesn’t Claude as a “pure” chatbot, as distinct from its coding tool instantiation, also include at least memory and guardrails and some level of workspace?

Hugging Face usefully broadens agents into three concepts: model, harness, and scaffold. In this configuration, the scaffold is a behavior-defining layer, and the harness is an execution layer. As I see those terms, scaffolding is more tightly connected to the model from a user’s perspective, whereas harnesses are easier to view as something operating separately.

Another possible layer for personal data in this context is “context,” as used by DTI affiliate Koodos Labs. A user’s personal context includes not just their memories and conversation histories, but other data that is specific to their use and running instance of AI. This could be something kept separately from the model, harness, and scaffold; in theory it could be stored within one or more of them, or separately, and paged in and out as the user needs.

So to return to my earlier question: Where does personal data live? Where should DTI be working with service providers to build portability tools? Like the terminology, the locus for personal data portability is unclear. Chat histories are one thing; we can get a handle on that in many respects. We know where it’s stored, and we can even build a clean schema for it. But the personal data used in customizing AI agent experiences, as distinct from chat services, can be much richer and at the same time much less clear.

There has been some progress in portability, though it is thus far inconsistent and very incomplete. You can import and export “memory” from Claude. You can usually download your chat histories from service providers, and some other personal data, and Google has rolled out guidance to import such data into Gemini. Meanwhile, a mention of the value of portable personal memory in an OpenAI Developer Community forum didn’t get any traction. As Kevin Bankston at CDT wrote in June in “Don’t Let Perfect be the Enemy of Portable,” there’s more that can be done, especially when it comes to imports.

Establishing clarity, transparency, and documentation into where personal data lives and how it can be accessed by other services matters, and not just for the kinds of user personal data portability that DTI works on. The frontier services aren’t just shipping models, and haven’t been for quite a long time. They’re shipping agents themselves, integrated models and harnesses with their own context and infrastructure. This integration can make data portability more challenging technically, trying to disentangle data and services; but it also makes it more tractable for regulators, who can impose rules on a single service provider and require them to figure it out. That seems more and more likely every day.

The IETF is responsible for major parts of the Web API stack with HTTP and JSON the most visible, stable and widespread components. Below HTTP, the IETF is responsible for lower layers like TCP/IP and QUIC among many others. Most portability APIs use HTTP+JSON on top of some network/transport stack, providing their own data formats for the personal data being transferred. For purposes of this piece, we won’t worry about the lower-level components and the work going on to make those components faster, more secure or more manageable.

The work that goes on at the top layer of IETF protocols is often the most relevant for data portability. Some standards are only relevant for one topic (for example, if your personal data isn’t a calendar then CalDAV is not relevant). This article lists work relevant to implementers of:

• Personal productivity servers, clients and helper apps
• Text, voice and video chat or conference platforms
• Social media feed clients or services
• Personal data services implementing their own APIs, data formats and authorization scopes

Some work is general-interest, especially on OAuth, so jump ahead if your data portability subject matter doesn’t match the above list.

Updating the old guard

There is a family of related standards that have been used for personal data portability for decades: the IETF standards for email, events, tasks and contacts. Let’s call these the personal productivity standards, the widely deployed originals of which are:

• IMAP and Internet Message Format for mailboxes and mail messages
• CalDAV and iCalendar for calendars, events and tasks
• CardDAV and vCard format for contacts

Did you think of these as solutions for data portability? I’ve changed email providers by using IMAP twice, first telling an IMAP client to copy all my email to my laptop, then configuring that client to sync all that email history to a new email provider. This relies on well-established interoperability on email formats, mailboxes, and metadata like read/unread and draft/sent. Especially because there are two transfers and three storage implementations involved, these standards have to be pretty solid for all the details and oddities to be transferred correctly.

Alternately, some folks are comfortable providing a new email service with their old email service password. After all, the decision to upload all email history to the new service requires nearly the same trust in it anyway. Then the new service uses IMAP or JMAP to fetch email from the source service until it’s all synchronized. (There’s also the variation of using a third service like Audriga and providing credentials to both source and destination, then it can use IMAP or JMAP.)

CalDAV and CardDAV are used the same way, either server-to-client-to-server, or sharing access credentials so that the destination server can act as a client. The iCalendar formats are typically used in export/import data portability flows, because the data volume is more manageable.

These personal productivity standards are worth reviewing because of work in several groups that may affect data portability.

• The JMAP WG is completing some refinements to a mature set of protocols and formats for accessing productivity data using HTTP and JSON. Since the Web kind of runs on HTTP and JSON these days, and JMAP was designed to unify and simplify a bunch of prior work, JMAP lowers the bar for supporting interoperability and portability for many kinds of personal data. More folks should look at implementing JMAP.
• In the mailmaint WG, we are working on PDPArchive, a consolidated export/import format that can be used to do data transfers including mailboxes, mail, calendars, tasks, events, contacts and address books. This saves users from exporting and importing calendars and address books one by one, and adds other user experience and fidelity improvements.
• The mailmaint WG is also working on hooking OAuth up to IMAP/SMTP/JMAP, which is useful and relevant to data portability for a number of reasons - but this should be discussed in context of all active work on OAuth which I’ll tackle below.

One more well-established personal data standard, not technically “productivity”, is Atom. Atom is described as a feed standard for clients to follow a feed like a blog or newsletter, but it’s also commonly used for the owner to move their feed content to a new system through export/import steps. Atom does not have active work but it felt incomplete not to mention it.

OAuth

Many are unsatisfied with the approaches described above for personal productivity data. Transferring data twice may be error prone, slow, and in many cases users don’t have the storage to hold all the email they’ve received for a decade or three. New providers would like to be able to make this process easier for new users by handling transfers server-to-server. But security folks are definitely not happy with sharing passwords to enable server-to-server because this gives ALL permissions to the destination (or 3rd party transfer service), not just content access. Everybody is turning to OAuth to provide scoped delegated authorization – but there are a few gaps.

OAuth is broadly deployed for Web services and their service partners, where a user logged into a Web service can authorize access to their data to the partner service. This works by pre-establishing a client_id and client_secret that the Web service and partner service know, to protect the user from rogue services pretending to be trusted services. But manually established secrets don’t scale well or work well in some situations.

1. OAuth for client access

The goal here is to use OAuth with the kind of client software we run on our laptops and phones. OAuth would seamlessly allow partial authorization rather than full account access, keep passwords even more secret, and support two-factor authentication. OAuth replacing SASL would make a service’s security surface more consistent and manageable between Web access and client access.

The blocker to using OAuth with user-installed copies of software is that the client_id/ client_secret solution doesn’t work across many installs. The developer of the client software can’t distribute the same client_id to all, or it would be discovered and used by hackers. Nor is it easy to prearrange client_id and client_secret and then deliver matched pairs to every client and every service those clients need to access.

Some solutions are being explored here:

• Using a fixed client_id in clients without short-circuiting the protections that client_id offers in server-to-server cases
• Using certificates instead of secrets, like DPoP or DSig
• Dynamically configuring and exchanging client_id and client_secret

1. Reducing barriers to new parties requesting API access

In an ideal rich and functional data portability ecosystem, a service provider would not have to go through manual applications to get a client_id and client_secret with every other service it may port data from. This is an NxN-scale operations and configuration challenge. At the same time, many more people are thinking of reducing barriers to AI services and AI agents requesting authorization for personal data access, for exactly the same NxN scale and overhead issues, so lots of folks are tackling this problem from SEVERAL different directions.

• DPoP or HTTPSIG using signatures instead of client_secret
• Dynamic Client Registration Protocol - still NxN shared secrets but automatically set them up
• AAuth

• Tying OAuth to a layer with certs: mTLS

  Some HTTP-based protocols like JMAP already support OAuth and will be able to benefit from these new extensions. Still, we’ll need some consolidation. It can get complicated if different services make different choices among all the options above.

1. Better defined scopes and permissions

Again, AI services and AI agents are driving innovation and elaboration in this space. OAuth scopes are a black box, and although the resource server offering the scope can define any scope they like, and also walk the user through additional limits on the scope via Web UI, automation and interoperability are hard to do with that approach. For example, if a user wants to limit a booking agent to $1500 on a travel booking site, that choice of $1500 would have to be set manually each time and can’t be interoperably reviewed or set by tools such as agent harnesses.

• OAuth RAR and extensions to RAR
• Scoping and motivating new work

As you can see, work on OAuth is exploding.

Brand new work

There is some newer work that is application specific.

VCon defines formats for virtual conversation transcripts and metadata. People wishing to port their conversation history from one platform to another, or wishing to make a reference archive of conversations, can use VCon.

ATP, also known as AT Proto, used by the BlueSky network, has a WG and is laying groundwork. It’s an explicit goal of the group to allow users to move their post/follow history between servers and not lose their connections (the way a Twitter user leaving Twitter would have had to). Note that in parallel W3C is working on ActivityPub with the same goal.

XMPP is being discussed at IETF again despite having a few years of development outside the IETF. It’s too early to say if a WG will be formed but folks may be interested in helping form one.

Things you won’t find…

Since personal productivity data formats were established twenty years ago, despite their success, we don’t tend to see more IETF standards for personal data.

Why is there no access protocol for photo albums in the cloud, or playlists in the cloud?

• File formats for images, videos and music are defined in other standards organizations (like the ISO for JPEG). Defining a protocol in IETF would require collaboration with folks who are used to operating elsewhere.
• IETF hasn’t been a great place to define data formats (e.g. for playlists). Folks seem to take semantic arguments to extremes, less willing to just accept a working proposal, even when a choice such as a field’s name just doesn’t matter that much for interop.
• It’s easier for implementers to host their own API. There’s a lot of consistency about using HTTP+JSON even if the data format for each photo album site is different.

This is OK. The biggest barrier to interoperable data portability today is trust, not data formats. It’s even more true in the last two years as AI has made it easy to use JSON data, often with the help of JSON Schema defined APIs (as Juan Cruz Viotti has pointed out, AIs are very good at JSON and JSON Schema). It’s easier to write or have AI write translators for slightly different photo album or music playlist formats than it is to standardize on a single format. That’s not to say we won’t see actual or defacto standards for those data types, because real stability, performance and perfection in the edge cases comes with standardization.

Takeaways

• Since trust is the largest barrier to a more functional data portability ecosystem, the OAuth work is important to everybody in data portability.
• New data format standards are more likely to be ad-hoc than IETF standards, although doors are open for folks to bring new data format standards if there is demand.
• AI is driving a great deal of work that will be relevant to non-AI driven personal data portability too.
• Personal productivity implementers who haven’t been engaged for a few years will find a pile of new work to digest.

We started at DTI with a two-fold mandate: build out and grow the Data Transfer Project, and work with policymakers and industry to help portability policy work in practice. To take the latter first, our policy research and engagement efforts are shaping the implementation of regulations to support an interoperable global data portability ecosystem that brings in all stakeholders and works without friction or duplication across borders. Emerging alignment between key UK and EU requirements are early signals of this vision in practice. You can read more on our new policy website page!

Our technology efforts have a similarly clear impact. Since we’ve been stewarding DTP, it has acquired several new contributors and several big wins. It’s now fully in the public domain with clearer contribution paths. DTP includes music playlist portability which was a huge data and semantic undertaking with many wrinkles to iron out. And finally, it now has a public API interface for even broader interoperability: small companies can now interoperate with DTP server instances without needing to run it. It’s more valuable than ever to join DTP and reduce network interoperability barriers.

And our portfolio has grown far beyond DTP: we’ve built a toolkit for data donations to research and a schema repository, and begun digging into portability of personal data in artificial intelligence. The biggest dimension of growth is our work on trust, notably our Data Trust Registry, entirely conceived, built and piloted in the last two years. DTR reduces unnecessary and onerous trust barriers by centering an ecosystem of shared trust criteria and verification processes. More organizations apply to join every week, connecting companies large and small to each other to unlock the trusted execution of user-initiated personal data transfers. Some use this access to deliver value for their users in customized digital experiences; others, like registry participants Supermarketer and Helmit, use it to protect people online.

There’s a running internet meme about how the real treasure is the friends we made along the way. That’s why all of the projects we’ve built or written have been intertwined with our network. Both DTP and DTR have brought us into regular contact with real companies solving real problems — and we help them share wins with each other, too. We work with other nonprofits, associations, academics, and businesses large and small. But the core of our community is DTI’s partners and affiliates. They are the most plugged into our policy and technology vision, and the biggest contributors to and champions of our impact.

What comes next for DTI? Continued success in our work means more tools, more trust, and smoother portability processes for the data ecosystem – and for individual people, more choice, more confidence, and more freedom. Our outputs, such as the Data Trust Registry, will be the foundation of many bridges – between companies large and small, between companies and agents, between agents and users, between companies and regulators. In particular, as I’ve written in other places, our work on data trust and transfers will shape key contours of the future of the AI landscape. We are at a key turning point on this, today.

The data portability party is heating up. And everyone is invited. The value proposition for user-initiated personal data transfers is more apparent and more diversified than ever before. While consumers become increasingly curious and assertive about who collects their data and how, AI agents emerge to remind us once again that access to personal data is the evergreen killer feature. Only data portability can prevent these two trends from coming into conflict. The technology infrastructure is changing constantly, as are policies and practices.

It won’t be this dynamic forever, though, and as normative and practical lines start to solidify, it’s crucial to be at the table and not left behind. DTI is now established as the table that matters when it comes to personal data. And yet, considering the value of personal data in artificial intelligence, and the significance of AI and data in evolving regulatory landscapes, I feel like DTI’s work is just beginning. Reach out if data is as central to your agenda as it is ours.

One theory for the value of blockchains and cryptocurrency technology was that they would eliminate the need for trust infrastructure, embedding trust in code rather than policy or promise; that didn’t work in practice. While immutable distributed ledgers have their time and place, there is no technosolution for trust problems of the form facing the agentic AI ecosystem today. Open source is similar, in that it can help contribute to trust by providing visibility into data policies and practices, but it is certainly no panacea here. Similarly, there’s value and security in creating sandbox environments where it is safe to run untrusted tech; but that doesn’t fit the many use cases where the value inherently requires connecting to the open internet and personal data.

So, what do we need? I’ll start with an assumption: trust is simultaneously both technical and sociopolitical. The technical side requires discovery, authorization, identity, and policy validation; the sociopolitical side first needs the entities performing the technical pieces to themselves be trusted, because “show your work” only goes so far when the stakes are so high; and second, needs tech that is scoped and applied correctly for the problem and context at hand.

Who’s tackling the technical pieces of trust? Here are some of the efforts we’re tracking, particularly in the identity and authorization direction where there is the most visible energy:

• The AAuth protocol allows an agent provider to self-publish per-agent per-instance cryptographic identity over HTTPS.
• Aria.bar, a nonprofit, operates a DNS-anchored agent identity registry.
• Agentic Resource Discovery, led by Google, claims to be “DNS and search engine for the agentic web”.
• Blockchain-based projects such as AgentDID and ERC-8004, like AAuth, offer decentralized self-certification options.
• In Estonia, the government allows agents to get official digital identities.
• The Agent Name Service recently announced by the Linux Foundation carries a big brand name.

Overall, the picture is complicated. In some cases, addressing and discovery issues are mixed up with identity; agents and services and users and providers can be conflated; and it’s often unclear who or what really needs identifying, who or what needs to be trusted (and by whom or what), and for what purpose. The umbrella label of “trust” often doesn’t keep the rain out, but rather just … leaks all the water through and spreads it around.

To make matters more complex, the critical target for establishing trust typically isn’t the agent, but rather the legal entity sitting behind it. Our use case for trust is personal data. If an agent is touching personal data, there is–hopefully!–a policy somewhere, adopted and enforced by an entity, that governs how it is using the data. At the very least, there is a person or company legally responsible for the compute that agent runs and the storage it lives on and uses. Find (and identify) the agent, find the entity, then find the policies and practices. Those can be reviewed to establish trust, and monitored for compliance to create accountability.

Looked at from this lens, the trust problem in data portability and the trust problem in agentic AI, at least with regard to the use of personal data, collapse to the same pair of factors: 1) make sure the user has authorized this action with the right level of insight; and 2) make sure the policies and practices that govern how personal data is handled are adequate. As I wrote in Tech Policy Press:

What, really, is different in the agentic AI context in terms of trust and the flow of personal data? Speed and reduced friction of development, deployment, and adoption is a clear change. But the abstract architectures and responsibilities are the same. Someone, person or entity, produces and ships a piece of software; that software communicates over the internet to a source of personal data; and a user authorizes the source of that data to make it available to the software, which uses it in some manner, including potentially passing it along to other software.

At DTI, we built the Data Trust Registry to help establish trust in data portability. When services apply to the registry, depending on the level of trust they are seeking, we verify the service provider’s identity, examine their privacy policy and security credentials, and review how they are communicating with users about their use of personal data. The resulting trust accreditation signals are reflected on the registry website, available for service providers to embed as a badge, and provided through the registry’s API for integration into other services’ verification processes. While built for our core use case of data portability, given the convergence of trust challenges between classic portability and agentic AI, we believe DTR has the potential to be a very effective starting point for the infrastructure and system necessary to promote trust in the agentic AI ecosystem.

Our mission statement at DTI is: “Empower people by building a vibrant ecosystem for simple and secure data transfers.” Agentic AI is full of data transfers, and they can seem simple, but helping them be secure requires trust. We build data transfer tools and infrastructure, but as with anything adjacent to technical standards, the impact isn’t maximized by shipping perfect technology, but rather by bringing a community together around a shared solution. As one example of that, we recently joined the Open Forum on AI and are looking forward to working with them more.

Building community around trust infrastructure is central to the journey we’re on now, and we invite you to join us on it.

As well as being mammals with a decent leap, they are all recognised logos – or trust marks – for successful certification schemes. Today DTI has launched a trust mark of our own.

Each of these schemes solves an informational asymmetry problem between buyers and sellers. Where consumers see these logos on products, they gain confidence that they meet certain standards with respect to animal welfare, environmental protection, or safety. They enable producers to differentiate themselves on grounds of quality that are otherwise difficult for consumers to observe at the point of purchase.

There are many other accreditation and certification schemes covering a wide range of sectors, from farming, to jewelry, to forestry, to electronics. Although these schemes all solve important market failures, most are not the result of government intervention. In fact, the most successful schemes are typically run by the industry themselves, through a trade association or dedicated independent body.

Participation by market participants is also rarely mandated by government or regulation of any form. Whether it is a supplier of tuna, coffee, or toys, suppliers sign up to these schemes and display the badges voluntarily, because they want to send a positive signal to their customer base.

Businesses operating in the data transfer community have a similar informational problem. They need to be able to signal to their users, their clients, and the businesses at the other end of the transfer pipeline that they are a legitimate service that takes their data protection responsibilities seriously. In other words, that you can trust them to take care of your personal data. Just like a supermarket shopper can’t tell if dolphins were harmed in the making of a can of tuna, a user online can’t tell whether an app developer will protect their data from malicious actors, or in fact if they are one themselves.

We have gone part way to addressing this informational challenge through our Data Trust Registry, by verifying services against our transparent requirements, and then listing them publicly on the Registry.

But that only spreads the word when someone looks at our website. Service providers have told us they want a louder signal. They want a trust mark to demonstrate their credibility. And they want it from an independent and respected body.

In response to this feedback, we are today launching the DTI Badge of Accreditation, which we will issue to all services listed on the Data Trust Registry. Where approved services display it is up to them, so long as it links back to their individual listing on the Registry.

Get in touch if you would like to know more.

That’s where I believe DTI has an important role to play that arguably no other organisation is capable of. Our advice and global perspective can help shape the pieces so that they fit together and form a single vision, so that the ‘tabs’ from one intervention slot into the ‘blanks’ of another. Or in other words, we can help to promote international interoperability. To do that, we need to keep up to date with global developments.

This newsletter sets out some of the main regulatory developments for the technology sector most relevant for our audience, including highlighting the ones we are engaging with directly.

United Kingdom

I would of course list the UK first because I am biased. But in any case, it deserves headline billing this time around as authorities prepare to deploy the powers granted by two new Acts of Parliament: The Data (Use and Access) Act (aka “the DUAA”) and the Digital Markets, Competition and Consumers Act (aka “the DMCCA”).

• The DUAA gave the UK Government enabling powers to introduce Smart Data Schemes like Open Banking in other sectors of its choosing. The Department of Business and Trade has since published a Smart Data Strategy in March 2026, which lists digital markets as one of the priority sectors to be pursued. In parallel, following a call for evidence on the Smart Data opportunities in digital markets last summer (to which we responded), the Department for Science Innovation and Technology (DSIT) published in May 2026 a summary and decision on next steps. DSIT indicated that the Government will consult “shortly” on the overall design of a digital markets scheme.
• Through the DMCCA, Parliament handed the Competition and Markets Authority (CMA) strong new powers to regulate large digital services where they are judged by the CMA to have Strategic Market Status (SMS). The CMA has investigations open, at different stages of development, in relation to various parts of Google’s, Apple’s, and Microsoft’s businesses. Within its investigation into Google’s General Search and Search Advertising services, which is the furthest forward, the CMA has consulted on Conduct Requirements that would oblige Google to maintain availability for its Data Portability API in the UK, and effectively peg the UK to any further advancements in the API resulting from the EU’s implementation of the Digital Markets Act (DMA). The CMA hinted in a recent press release that this Conduct Requirement will come into force in the “coming weeks”.

Also, published this week, is a consultation from DSIT on empowering people through data intermediaries. This follows a call for evidence last year that DTI responded to. In addition to consideration of legislative options for removing barriers to data intermediaries, the consultation seeks views on a non-statutory authorisation scheme, with an industry run certification process. The consultation notes that “Authorised intermediaries could be listed on a public register or permitted to display a recognised trust mark, providing a visible signal to individuals and data controllers that they meet agreed standards.”

DTI is engaging extensively with each of these developments, where we are pressing the importance of our Data Trust Registry as a key component for achieving international interoperability of smart data schemes, while also acting as a signal of credibility for listed services, which includes many data intermediaries.

For any UK-based readers, I encourage you to attend the Smart Data Forum next week, where these developments will be a key topic, with DTI’s Data Trust Registry shortlisted for the Trust, Consent and Governance Award. Hopefully I will see some of you there!

European Union

Although the EU is further along this regulatory journey than the UK, the implementation of targeted data portability regulations is still relatively early. There have been several developments over the past year that have moved the regulatory dialogue forwards:

• The DMA one year review: in 2025, the European Commission ran a consultation as part of its one year review of the DMA. Here is our response. In its follow up Report, the Commission rightly sought to highlight the data portability provisions in the DMA as one of its success stories, where visible progress has been made and innovative new services are starting to reach consumers. Also noteworthy was the Commission’s signal in its Staff Working Document that it will be, as a matter of priority, “monitoring whether certain AI services should be designated as virtual assistants” and therefore brought within the scope of the DMA.
• Joint guidelines on the interplay between the DMA and the GDPR: in Q4 2025, the European Data Protection Board and the European Commission consulted on draft joint guidelines on the interplay between these two regulations. With respect to data portability, the document sought to clarify the complementary nature of DMA Article 6(9) and the GDPR Article 20, as well as setting out some more granular expectations regarding compliance with DMA Article 6(9), such as appropriate third-party onboarding procedures.
• The Data Act: this legislation came into application in September 2025, bringing in direct transfer data portability provisions for suppliers of Internet of Things connected devices and for cloud storage providers. Despite being new, it is already facing changes through the Digital Omnibus package. Aimed at simplifying and consolidating parts of the EU’s digital regulatory framework, the package contains some tweaks to regulations that could affect existing data portability rules at the margins. For example, targeted exemptions to the Data Act’s cloud switching requirements for smaller businesses, and removing the requirement (currently in the Data Governance Act) for mandatory reporting and labelling of data intermediation services. Some concerns have been raised over the Omnibus, including by researchers over potential limits to data donations.

DTI has been frequently engaged with the European Commission on all of these topics, including responding to the consultations. We are now watching closely to see whether the DMA will be the catalyst for portability of AI ‘virtual assistant’ conversation histories, and whether the Data Act encourages more IOT companies to participate proactively in the data portability community.

US State-level Legislation

In the United States, progress on data portability seems most likely to be steered by legislation at the State level. Utah and South Dakota have led the way, each enacting into law a “Digital Choice Act”, effective from July 2026 and July 2027 respectively. They require social media platforms to support direct data transfers to other services of all user data including the social graph. Several other States are following with similar Acts, including New York, Minnesota, South Carolina, Virginia, and California.

Although the legislative process still has some way to run, California’s version of the Digital Choice Act may turn out to be the most impactful. Aside from the mere fact it is California, which tends to suggest national application for tech regulation, it also includes new requirements for portability of AI contextual data such as conversation histories (as does Virginia’s). We view this as a high priority moving target, and while DTI as an organization does not engage in advocacy for or against legislation, we seek to contribute our expertise where it will help facilitate collective understanding, and are monitoring this closely.

South Korea

South Korea is one of the most advanced jurisdictions for empowering citizens to access and utilise their personal data, with its Personal Information Protection Commission (PIPC) announcing in April 2026 that citizens’ data portability rights would be extended to all major sectors of the economy.

Under the announced rollout timeline, individuals will be able to access their data directly from public institution websites starting in August 2026, with application to the private sector next year. As well as sectors for healthcare, telecommunications, and energy, South Korea’s MyData framework will also apply to various online platforms (above set quantitative thresholds) such as taxi-hailing services, e-commerce platforms, streaming platforms, and holiday lodging services.

Japan

On December 18, 2025, Japan’s long-awaited Mobile Software Competition Act (MSCA) – also known as the Smartphone Act – officially entered into force. Enforced by the Japan Fair Trade Commission (JFTC), this ex-ante regulatory framework is focused on supporting competition within and between Apple’s and Google’s mobile ecosystems.

With some similarities to aspects of the EU’s DMA, the MSCA establishes explicit data portability mandates. This has prompted an expansion in the geographic availability of some existing data portability tooling, such as Apple’s Account Data Transfer API, which now lists availability for users in the EU, UK and Japan.

We have recently held conversations with the JFTC to discuss these developments, as well as to share updates on our relevant projects such as our Data Trust Registry.

Australia

With some parallels to the UK, Australia has two routes that may eventually lead to data portability initiatives in the digital economy:

• Most immediately, there is the ongoing expansion of its Consumer Data Right (CDR) which, like the UK’s Smart Data programme, has its origins in the banking sector. It has subsequently rolled out to the energy sector, and is now expanding to non-bank lending services in July 2026. We spoke recently to the Australian Competition and Consumer Commission (ACCC) about its implementation of the CDR, highlighting some potential future overlap between our Data Trust Registry and the ACCC’s register of accredited data recipients.
• Australia is also expected to introduce legislation to establish a new ex ante digital markets competition regime, leading to codes of conduct for designated digital platforms. Described by some as a hybrid between the EU’s and UK’s approaches to digital markets regulation, the requirements may well include provisions for supporting data portability.

Given these developments, Australia appears to be a strong candidate for implementing data portability requirements for online platforms in the near future, though it is unclear at this stage whether it will adopt a sector wide approach via the CDR, or a more targeted approach through its planned ex ante digital competition regime.

Canada

Following many years of policy debate, Canada formally codified its Open Banking framework through Bill C-15, which received Royal Assent in March 2026. Critically, the Bill also amended Canada’s federal privacy law (PIPEDA) with the introduction of a new section on “Mobility of Personal Information”. This lays the foundations for Canadian authorities to introduce new data sharing frameworks in other sectors beyond banking.

Alongside these legislative developments, the Competition Bureau Canada published a comprehensive report in January 2026 entitled Your Data, Your Control, with extensive references to data portability in the digital economy. It was a pleasure to chat to the team behind the report in March this year about ongoing developments in Canada and how they connect with DTI’s mission.

India

I highlight India in this update for two significant non-developments on data portability.

First, the Digital Personal Data Protection Act (DPDPA) has been proceeding through a phased rollout, with full enforcement by May 2027. It is particularly noteworthy that the DPDPA, as India’s comprehensive data protection framework, does not include a GDPR-like right to data portability.

Second, India’s equivalent of the DMA - the Digital Competition Bill - has continued to stall, with focus shifting to further evidence gathering through a market study.

In contrast to some jurisdictions where data portability is a feature of privacy and competition legislation in parallel, India is not prioritising either regulatory route.

Brazil

Brazil has been progressing its Digital Markets Bill designed to tackle competition challenges in digital markets, as written about by Laís Martins and Megan Kirkwood for Tech Policy Press in February this year. In March, lawmakers approved an “urgency motion” enabling the Bill to skip some of the slower committee stages of review.

If passed, the Bill will give new powers to Brazil’s competition regulator, CADE, to designate platforms as an “economic agent with systemic relevance”, with a menu of interventions then available to it including imposing requirements for continuous and real-time data portability.

The Bill still has several legislative hurdles to clear, so we’ll keep a watching brief.

Chile

The new Data Protection Act In Chile, which brings in substantial alignment with the GDPR, will officially come into full effect in December 2026. Like the GDPR, the Act includes a right to data portability, which gives the data subject “the right to have their personal data transmitted directly from controller to controller where technically possible.” As has been the case in Europe, the final three words of that quote are likely to be impactful.

Get in touch if there are some developments in your part of the world that deserve to be on the next update.

A social account can be used to maintain friendships, collaborate professionally, pursue hobbies, share information, promote one’s preferred policies or politicians, and so much more. All of the posts and replies in a social account build a very personal history, holding years of images, messages, memories, relationships, and a sense of evolving identity and purpose.

Although the Fediverse offers choice of where to create an account (like email does) and still connect, every account must live on a server, and that server is not permanent. Often hosted by a friend or former colleague, one’s Fediverse server can be shut down in an orderly way, change policies, defederate from other servers, be defederated, or simply suddenly disappear. If these server changes prompt a user to move their account, they face the difficult reality that their posts, followers, and entire digital social life may not move with them.

For the Fediverse’s freedom from centralized control to continue to work in a constantly moving world, Fediverse account portability cannot be an afterthought; it must be a first-class, foundational capability. Users need a reliable, non-workaround solution to move their content, accounts, and relationships from one server to another.

Fortunately, this isn’t hard, at least technically. Since in the Fediverse servers request data from each other, most of the data requests to move an account to another server are already supported. This interoperability is defined mostly by ActivityPub, an open standard developed by the World Wide Web Consortium (W3C). ActivityPub acts as the shared language, defining common structures for users (actors), content publication (outboxes), notifications and messages (inboxes), and social actions like following and sharing.

The few missing pieces for safe and reliable server-to-server account transfer require a bit of agreement on specifics:

• How can the requesting server use OAuth to gain full access to private account information? What exactly is the OAuth URL and what data access scope can be requested?
• How is private information conveyed? What ActivityStream collections hold private information and what are their URLs?
• How are references across servers handled when the object referred to moves?

Answering these questions is why the LOLA Portability (Live, On-Line Account Portability ) draft specification was developed. LOLA defines a process where a destination server can request and copy account data directly from a source server, with the user’s authorization, while both systems remain online. The specification is being developed within the W3C’s Social Web Working Group.

LOLA organizes account portability into three structured phases:

1. Discovery and Authorization
   The destination server confirms the source server supports portability and what its URLs are. The user is redirected to the source server to authenticate and explicitly approve the data transfer using OAuth 2.0 and an appropriate scope that grants just the right permissions.

2. Fetching and Saving Data
   Once authorized, the destination server requests and recreates the user’s key collections, such as posts, following lists, liked content, and block lists. Crucially, this is designed as a copy, not a destructive move, allowing the user to verify the result before making further decisions.

3. Testing and Finalizing Phase
   After the copy is successful, the user can choose to notify followers of the move, redirect links to old content, and close down their old account, when they are ready.

The Data Transfer Initiative supports this work by contributing to the authoring of LOLA and of a testbed for LOLA implementers to test against. This supports our overall mission of improving the availability and functionality of data portability generally, by showcasing an architecture that works well even under the difficulties of federation, linked content, and private as well as public information. For a deeper dive, I have written the start of a series of articles on the testbed and the technical pieces of LOLA – check it out.