“There is a lot of standards development work happening around AI right now.”

Also, the sun rises in the east, the sky is blue, and water is wet. Still, it’s worth catching up on things where one can.

New working groups, community groups, industry consortia, open source projects, and specifications seem to appear almost weekly (I heard someone just say “daily”. You are not wrong.) Some of those efforts focus on models; others on content. Other efforts are focusing on identity, authentication, authorization, discovery, and how AI systems interact with the Web.

And that makes it very easy to look at two standards groups with “AI” somewhere in their description and wonder if they are working on the same problem. Often, they aren’t, but it takes a bit of digging to figure out what they are doing. Last week, I wrote about two groups looking at (among other things) discovery when it comes to AI. This week, I’m writing about some of the AI-related work happening in the W3C and the IETF. These are far from the only organizations doing work in this space. ISO, IEEE, OASIS, the OpenID Foundation, the Linux Foundation, the ITU-T, and a variety of industry groups are all working on different parts of the picture.

So this is not intended to be a definitive map of AI standards.

But W3C and IETF are particularly interesting places to look because so much of what we think of as the Web and the Internet already passes through standards developed in those communities. Looking at what they are working on gives us a useful glimpse of how some of the technical layers around AI may start fitting together.

And what I find most interesting is that there is less direct duplication than you might expect.

You can Subscribe and Listen to the Podcast on Apple Podcasts, or wherever you listen to Podcasts.

And be sure to leave me a Rating and Review!

Two fairly specific problems at the IETF

I touched on some of this work last year, but let’s recap with two groups in the IETF. The first is the AI Preferences Working Group (AIPREF).

AIPREF is working on a way for content owners and publishers to express preferences about how their content can be used by AI systems.

That includes questions such as whether content may be used for training or other AI-related purposes and how those preferences can be associated with resources through mechanisms such as HTTP and robots.txt.

This is not intended to solve every problem involving AI and content. In particular, it does not try to provide enforcement, authenticate crawlers, or determine whether an AI system has actually respected a publisher’s preference. Those are different problems.

The second group, Web Bot Auth, addresses one of them.

WebBotAuth (yes, we usually just drop the spaces, I don’t know why) is working on cryptographic authentication for automated HTTP clients visiting websites that primarily serve humans.

That category is intentionally broad. It includes traditional crawlers, search engines, web archivers, AI training crawlers, and AI agents interacting with websites on behalf of users. The current work includes an HTTP Message Signatures-based authentication protocol and related mechanisms for conveying information about the bot or its operator.

So already we have two distinctly different questions.

AIPREF asks something like: What does the publisher permit an AI system to do with this content?

WebBotAuth asks: What automated client is making this HTTP request?

Those questions clearly interact, but answering one does not answer the other.

The W3C work covers several different layers

Searching the W3C Community Groups for AI-related work produces quite a few results. But the fact that a Community Group exists is not necessarily the same thing as a group doing sustained standards development.

W3C Community Groups are deliberately lightweight. People can come together to explore an idea without first getting the organizational commitment required to establish a formal W3C Working Group. That makes them extremely useful for incubation. It also means that some groups are very active while others may have little more than an initial proposal and a participant list.

Looking specifically for groups with evidence of substantive meetings, three stand out.

The AI Content Disclosure Community Group is exploring machine-readable ways to describe the degree to which content was created or assisted by generative AI.

Its work includes questions such as whether material is entirely human-authored, AI-assisted, AI-generated but reviewed by a human, or generated without human oversight. The group has been discussing terminology, disclosure levels, granularity, and candidate technical mechanisms.

At first glance, that can sound similar to AIPREF because both involve AI-related metadata attached to content, but the direction of the information is completely different.

AIPREF is working on “Here is what AI systems may do with this content.“

AI Content Disclosure, on the other hand, says, “Here is information about how AI was involved in creating this content.“

Those specifications may eventually need compatible ways of representing metadata on the Web, but they are not trying to standardize the same thing.

From content to capabilities

Another active area is the Web Machine Learning Community Group.

WebML has been around considerably longer than many of these newer AI groups. Its original focus was making machine learning a first-class capability of the Web, including work around browser-based inference. A nice reminder that machines reading web content is not a new thing.

More recently for that group, however, some of the discussion has expanded into agent interaction through WebMCP.

WebMCP (not to be confused with MCP) is interesting because it moves the problem away from simply processing or describing content. Instead, it asks how a Web application might expose structured capabilities that an AI agent can invoke.

The idea here is to have a site where an agent does not have to reconstruct every available action by interpreting buttons, forms, and visual layout. The application could instead expose structured tools describing what the agent can do.

That is a very different problem from AIPREF, but it definitely snuggles up against WebBotAuth.

If an agent can invoke a capability exposed by a website, at some point, the website may need to know something about the agent making the request.

WebMCP does not, therefore, need to become an authentication protocol. In fact, it would probably be better if it didn’t. Instead, authentication may be something supplied by another layer: WebBotAuth.

That kind of boundary that will matter as these standards develop.

Agents on the Web

There is also the Autonomous Agents on the Web Community Group.

This group is looking at a much broader architectural question: what would Web-based multi-agent systems look like if they were designed around Web architecture?

Its work draws heavily on technologies such as Linked Data, the Semantic Web, and the Web of Things. One recent discussion, for example, explored whether W3C Thing Descriptions could effectively become integration documents that agents can interpret as tools.

Again, that is not WebBotAuth.

WebBotAuth deliberately limits itself to authenticating automated clients accessing websites intended primarily for humans. Agent-to-agent APIs and other machine-oriented interfaces are explicitly out of scope. The WebAgents work is much more interested in how agents, services, people, devices, and other resources interact in a Web-native distributed environment.

The two areas may eventually need to connect. But they occupy different parts of the architecture.

The groups I’m watching

But wait, there’s more! There are also newer W3C Community Groups where the boundaries are less settled.

One is the Agent-to-Web Framework Community Group (A2WF). A2WF starts from the observation that AI agents are increasingly doing more than retrieving content. They may fill in forms, book appointments, add products to shopping carts, or submit transactions. The group proposes machine-readable policies that allow website operators to govern those actions.

Interestingly, the group’s own description calls out both robots.txt and AIPREF as solving different problems. Those mechanisms can govern crawling or content use, but they do not tell an agent whether it may perform an action, whether authentication is required, or whether a human must approve something first.

That makes sense, but it also puts A2WF very close to WebBotAuth.

One clean architectural boundary would be for A2WF to describe policies such as “this action requires an authenticated automated client,” while WebBotAuth provides the mechanism for performing that authentication. If A2WF instead starts defining its own agent authentication scheme, the two efforts could begin solving the same problem. That is why this is an area where coordination matters before specifications harden.

Another new effort is the Agent Identity Registry Protocol Community Group.

Its scope includes verifiable agent identities, credentials tying agents to controlling organizations, authorization scope, trust negotiation, revocation, and integration with technologies including OAuth, OpenID Connect, MCP, and A2A. It explicitly anticipates coordination with several other organizations and with the IETF WIMSE Working Group. That raises a much broader set of questions about agent identity than WebBotAuth is trying to answer.

But as more groups begin working on agent identity, authorization, authentication, delegation, and trust, maintaining clarity around what’s happening in each layer is going to get harder.

Overlap isn’t necessarily the problem

Looking across these efforts, I don’t see a simple W3C-versus-IETF story, nor do I see much direct duplication today. Instead, I see a stack beginning to emerge.

• One specification might describe how AI was used to create content: W3C AI Content Disclosure Community Group
• Another might describe how that content may be used by AI: IETF AIPREF Working Group
• Another might authenticate the automated client requesting it: IETF WebBotAuth Working Group
• Another might describe the actions a website permits that client to perform: W3C Agent-to-Web Framework Community Group (A2WF)
• Another might expose application capabilities in a form an agent can understand: W3C Web Machine Learning Community Group
• And still another might provide credentials that say something about who operates the agent and what authority it has: W3C Agent Identity Registry Protocol Community Group

The danger in this lovely layered set of efforts is not necessarily that two standards groups deliberately create competing specifications. I mean, that happens, but the liaisons for these two organizations do try to avoid it. That said, without sufficient coordination, it’s possible for adjacent specifications make incompatible assumptions about each other.

That might look like one layer using a policy mechanism assumes one model of identity. Another layer might have an authentication mechanism that exposes information in a form the authorization layer cannot use. A discovery mechanism might reveal capabilities without saying anything about whether they may be invoked.

That kind of fragmentation is much harder to see than two obviously competing protocols.

Start with the problem, not the acronym

This is becoming a recurring lesson in looking at AI standards. It is tempting to start by asking whether two groups overlap because they both mention agents, identity, content, or AI. A better place to start is with the actual problem each group is trying to solve.

W3C and IETF give us only part of this picture. There is substantial AI-related standards work happening elsewhere, and that work will introduce still more boundaries that need to be understood.

But even this partial view makes one thing fairly clear. We are not getting one AI protocol. We are building an increasingly complicated set of protocols, vocabularies, APIs, credentials, and policies around AI systems.

Given that, the important question is going to be less whether they all live in the same standards organization and more whether the pieces can actually work together.

📩 If you’d like to be notified of new posts rather than hoping you catch it on social media, I have an option for you! Subscribe to get a notification when new posts go live. No spam, just announcements of new posts. [Subscribe here]

Transcript

Welcome to the Digital Identity Digest, the audio companion to the blog at Spherical Cow Consulting. I’m Heather Flanagan, and every week I break down interesting topics in the field of digital identity, from credentials and standards to browser weirdness and policy twists.

If you work with digital identity but don’t have time to follow every specification or hype cycle, you’re in the right place.

Let’s get into it.

There’s a lot of standards development work happening around AI right now. Also, the sun rises in the east, the sky is blue, and water is wet.

Still, it’s worth catching up where we can. New working groups, community groups, consortia, open-source projects, and specifications seem to appear almost weekly. Someone recently suggested daily, and that might actually be closer to the truth.

Some efforts focus on models, while others focus on content. Still others look at identity and authentication, authorization, discovery, or how AI systems interact with the web.

I talked about a couple of these efforts in the last episode. That makes it easy to look at two standards groups with AI somewhere in the description and assume they’re working on the same problem. Often, that isn’t the case.

Last week, I wrote about two groups looking at AI agent discovery, among other things. This week, I want to zoom out and look at some of the AI-related work happening more broadly in the W3C and IETF.

These are absolutely not the only organizations doing work in this space. ISO, IEEE, OASIS, the OpenID Foundation, the Linux Foundation, ITU-T, and various other industry groups are all working on different pieces of the puzzle that AI has brought to the table.

This isn’t a definitive map of AI standards. However, the W3C and IETF are interesting places to look because so much of what we think of as the web and the Internet already depends on standards from those communities.

And one thing becomes particularly clear when you look at this work: there’s less direct duplication than you might expect.

---

AI Content Preferences and Automated Client Authentication

Let’s start with two fairly specific problems that the IETF is working on.

One is being addressed by the AI Preferences Working Group, known as AIPREF.

AIPREF is working on ways for content owners and publishers to express preferences about how their content may be used by AI systems. That includes questions such as whether content can be used for training or other AI-related purposes, and how those preferences can be associated with resources using mechanisms such as HTTP or robots.txt.

What AIPREF is not trying to do is just as important.

It isn’t defining enforcement. It isn’t authenticating crawlers. And it isn’t determining whether an AI system actually respects a publisher’s preference.

Those are separate problems.

The second IETF working group, Web Bot Auth, addresses one of those problems. It is working on cryptographic authentication for automated HTTP clients visiting websites that primarily serve humans.

That includes:

• Traditional crawlers
• Search engines
• Web archivers
• AI training crawlers
• AI agents interacting with a website on behalf of users

Already, we have two very different questions.

AIPREF asks, what does the publisher permit an AI system to do with this content?

Web Bot Auth asks, what automated client is making this HTTP request?

Those questions may interact, but answering one does not answer the other.

---

Exploring AI Standards Work at the W3C

Now let’s move over to the W3C.

If you search the W3C groups, you’ll find that much of the AI-related work is currently happening in Community Groups. That situation is subject to change, probably relatively soon.

However, it’s important to remember that the existence of a Community Group doesn’t necessarily mean sustained standards development is happening inside it.

W3C Community Groups are intentionally lightweight. They’re inexpensive to propose and manage, allowing people to come together and explore an idea without first making the organizational commitment required for a formal Working Group.

That is very useful for incubation.

At the same time, some groups are active and mature, while others may have little more than a proposal, a few participants, and a meeting or two.

Looking specifically for groups with evidence of substantive activity, there are three that stand out.

---

AI Content Disclosure and AI Preferences Solve Different Problems

The first is the AI Content Disclosure Community Group.

This group is exploring machine-readable ways to describe the degree to which content was created or assisted by generative AI.

For example, was something entirely human-authored? Was it AI-assisted? Was it generated by AI but reviewed by a human? Or was it generated without human oversight?

These are the kinds of questions the group is discussing, along with terminology, disclosure levels, granularity, and potentially technical mechanisms.

At first glance, this can look a little like AIPREF because both involve AI-related information associated with content.

However, the direction is completely different.

AI Preferences says:

Here’s what an AI system may do with this content.

AI Content Disclosure says:

Here’s information about how AI was involved in creating this content.

These are adjacent ideas, but they are not the same standards problem.

---

Web Machine Learning and WebMCP

Another active W3C area is the Web Machine Learning Community Group.

WebML has been around longer than many of these newer AI efforts. Its original focus was on making machine learning a first-class capability of the web, including browser-based inference.

More recently, some of the discussion has expanded into agent interaction through something called WebMCP.

This is where things get interesting.

The basic idea is that a web application could expose structured capabilities that an AI agent can invoke.

Instead of forcing an agent to reverse-engineer every button, field, or visual affordance on a page, the application could describe its available tools directly.

It’s worth noting that WebMCP and MCP have absolutely nothing to do with one another.

This work is very different from AIPREF, but it gets closer to Web Bot Auth.

If an agent can invoke a capability exposed by a website, the website may eventually need to know something about the agent making the request.

That does not mean WebMCP should become an authentication protocol. In fact, it would probably be better if it didn’t.

Authentication may instead come from another layer, such as Web Bot Auth.

That’s exactly the kind of boundary that is going to matter.

---

Autonomous Agents on the Web

The Autonomous Agents on the Web Community Group is asking a broader architectural question.

What would a web-based, multi-agent system look like if it were designed around existing web architecture?

Its work draws on concepts such as Linked Data, the Semantic Web, and the Web of Things.

One recent discussion, for example, explored whether the W3C Thing Description could function as an integration document that agents interpret as tools.

This isn’t what Web Bot Auth is doing.

Web Bot Auth is deliberately scoped to authenticating automated clients accessing websites intended primarily for humans. Agent-to-agent interfaces and machine-oriented APIs are outside its scope.

The web agents work is more interested in how agents, services, people, devices, and other resources interact in a web-native distributed environment.

Different layer, different problem.

---

Governing What AI Agents Can Do on Websites

There are a couple of newer W3C groups I’m watching more closely because their boundaries aren’t settled yet.

One is the Agent to Web Framework Community Group, or A2WF.

A2WF starts from the observation that agents are increasingly doing more than retrieving content. They may also be:

• Filling in forms
• Booking appointments
• Adding items to shopping carts
• Submitting transactions

The group is therefore looking at machine-readable policies that let a website operator govern those actions.

Its description explicitly distinguishes this work from robots.txt and AIPREF.

Those mechanisms can say something about crawling or content use. However, they don’t say whether an agent is allowed to perform an action, whether authentication is required, or whether a human must approve something first.

That distinction makes sense.

But it puts A2WF a bit closer to Web Bot Auth.

A clean boundary between the two might look something like this: A2WF says that an action requires an authenticated automated client, and Web Bot Auth provides the mechanism used to authenticate that client.

If A2WF starts defining its own authentication mechanism, however, the two efforts could begin solving the same problem.

That would be unfortunate because they might not solve it in the same way, creating interoperability issues.

This is where coordination becomes really important.

---

Agent Identity and Trust

Another group I’m watching is the Agent Identity Registry Protocol Community Group.

Its scope is broader again.

It includes:

• Verifiable agent identities
• Credentials tying agents to controlling organizations
• Authorization scope
• Trust negotiation
• Revocation
• Integration with technologies such as OAuth, OpenID Connect, MCP, and A2A

That goes well beyond what Web Bot Auth is trying to do.

As more groups begin working on agent identity, authentication, authorization, and related topics, keeping those architectural boundaries clear is going to become pretty hard.

---

The Emerging Stack of AI Standards

This brings me to my larger point.

Looking across all this work, I don’t see a simple story of one standards organization versus another.

I also don’t see a whole lot of duplication of effort right now, which is good.

What I do see is the beginning of a really interesting stack of protocols.

One specification may describe how AI was used to create content.

The next may describe how that content may be used by AI. Another may authenticate the automated client requesting it. The next protocol may describe what actions the website allows that client to perform.

Then another layer may expose application capabilities in a form that an agent can understand.

Finally, a further layer may provide credentials that say something about who operates the agent and what authority it has.

That actually sounds like a pretty sensible stack.

The problem isn’t necessarily that two standards groups will deliberately create competing protocols. That does happen, but both organizations have liaison processes intended to mitigate it.

The subtler risk is that adjacent standards may make incompatible assumptions about each other.

For example:

• One layer might assume a particular model of identity.
• Another might assume authentication information will be exposed in a form the authorization layer cannot use.
• A discovery mechanism might reveal capabilities without saying anything about whether those capabilities may actually be invoked.

That kind of fragmentation is much harder to spot than two obviously competing protocols.

---

Start With the Problem, Not the AI Label

This leads back to a theme I keep running into when looking at AI standards work.

Remember to start with the problem you’re trying to solve, not simply the fact that it’s AI.

It’s tempting to ask whether two groups overlap because they both mention agents, identity, context, or AI.

A better set of questions is:

• What information are you trying to exchange?
• Between which parties?
• At what architectural layer?
• What decision is that information supposed to enable?
• What does the specification assume has already happened before its mechanism comes into play?

Once you ask those questions, many things that might look like overlaps start to disappear. Others, however, become more important.

The W3C and the IETF are only part of this landscape. They just happen to be the organizations I know best.

There is substantial AI-related standards work happening elsewhere, and those efforts will create still more boundaries that need to be understood.

---

Why Interoperability Matters More Than One Universal Protocol

Even this partial view makes something pretty clear.

If you’re looking for one protocol to rule them all, you’re not going to get it.

We’re building an increasingly complicated set of protocols, vocabularies, APIs, credentials, and policies around AI systems.

The important question is probably not whether they all live in the same standards organization, because they won’t.

The important question is whether the pieces can actually work together.

That’s going to be a very interesting problem.

For links to all the Working Groups and Community Groups I mentioned here, take a look at the written version of this post.

I’ll talk to you again next week.

---

About the Digital Identity Digest

And that’s it for this week’s episode of the Digital Identity Digest.

If it helps make things a little clearer, or at least a little more interesting, share it with a friend or colleague and connect with me on LinkedIn @hlflanagan.

If you enjoyed the show, be sure to subscribe and leave me a rating and review on Apple Podcasts or wherever you listen to podcasts.

You can also find the full written post at Spherical Cow Consulting.

Stay curious, stay engaged, and let’s get these conversations going.