“Standards development has a (well-deserved) reputation for being slow.”

Specifications can spend years moving from an initial proposal through debate, implementation, revision, consensus, review, and eventual publication.

At the same time, new ideas appear constantly.

That creates an odd problem for anyone trying to follow standards work. The finished standards move slowly enough that it seems as though keeping up should be possible. The work feeding that process moves much faster. New drafts appear, existing drafts change, conversations start in one group and migrate to another, and similar ideas emerge in different organizations using completely different terminology.

Nobody can follow all of it. I certainly can’t. What I can do is try to build a reasonably good radar. That’s easier than it used to be, which is both a good thing and a bad thing.

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!

Watching the top of the funnel

For the IETF, I’ve built a small tool that queries the Datatracker (more on what that is in a second) every day, looking for Internet-Drafts that appear relevant to identity, AI, or the increasingly busy intersection between the two. Yes, I used AI to help me with this, as I can’t code myself out of a wet paper bag. If it isn’t m4 and sendmail, it isn’t me. (I’m old.)

The Datatracker is the IETF’s day-to-day platform for information about documents, working groups, meetings, agendas, minutes, presentations, and other parts of the standards process. It also exposes an API, which makes it possible to query that information programmatically rather than trying to follow everything manually.

The result is a daily report. Here’s an example from August 12, 2026.

I do not read every draft in every report. That would simply replace one impossible task with another.

Instead, every so often, I skim what has appeared and look for what catches my attention. Sometimes that is a subject I am already following. Sometimes it is an architectural idea that seems potentially important. Sometimes several different drafts appear to be circling the same problem. Occasionally, I see something and think, “Huh. That’s interesting,” which is often enough to send me down a rabbit hole.

I’m not the only person who has built tools for this kind of thing. I highly recommend what George Fletcher has put together as well; he’s focused on slightly different things than I am, but the information is still very useful. I’m sure there are others who have done something similar.

My report, and I’d say George’s as well, is therefore less a reading list than it is an early-warning system.

An Internet-Draft tells you surprisingly little

There is an important caveat here, particularly for people who do not spend much time around the IETF. The appearance of an Internet-Draft does not mean that “the IETF is standardizing” whatever the draft proposes.

Most of the documents my tracker finds are individual submissions. Someone has an idea, writes it down in the format of an Internet-Draft, and publishes it. That does not necessarily mean a working group has agreed that the problem needs solving, much less that the proposed approach is the right solution.

That low barrier to getting an idea into circulation is valuable. Standards communities need places where ideas can be explored before consensus exists. It does mean, however, that an Internet-Draft needs context.

I wrote earlier this year about how standards development actually works and why terms such as “draft” can mean very different things depending on where a document sits in a standards organization’s process. I won’t repeat that whole discussion here, but the distinction matters enormously when looking at a feed like mine.

Some individual drafts will eventually be adopted by working groups and may ultimately become RFCs. Some will influence another document without progressing themselves. Some will generate useful debate. Plenty will expire.

My tracker is deliberately watching before anyone knows which category a document will fall into.

Finding the document is where the work starts

That is also why automated discovery can only take me so far. When something in the report looks interesting, I start looking for the people and conversations around it.

Who wrote the draft? Have the authors brought it to an existing working group? Has it been discussed on a mailing list? Was it presented at an IETF meeting? Are people suggesting that it go through DISPATCH or another venue to figure out where the work belongs? Are there competing drafts? Are implementers involved? Are people debating the problem itself, or are they already debating how to solve it?

Those questions give me far more information than the existence of the draft.

A document tells me that somebody cared enough about an idea to write it down. The surrounding discussion starts to tell me whether other people care too. That is the difference between situational awareness and understanding.

Automation is good at finding things. Judgment is still doing most of the work.

There is a temptation, particularly now that AI systems can summarize large quantities of information, to imagine that the problem of keeping up can largely be automated. I don’t think that’s true.

Automation can dramatically reduce the cost of discovery. It can notice that a document appeared, extract its metadata, look for certain terms, compare versions, group related material, and help me decide where to look. Huzzah, hugely helpful.

What it cannot reliably tell me is which apparently obscure idea is going to become important six months from now. Nor can a keyword query understand all the vocabulary shifts happening across identity and AI. A document may have significant identity implications without using the word “identity.” Work involving delegation, authorization, provenance, agents, credentials, attestation, trust, permissions, principals, or representation may all turn out to be part of the same architectural conversation.

Conversely, a document can match every keyword I care about and still have very little significance for the work I actually follow. My automated report is intentionally noisy. I would rather see a few things I ultimately discard than design a beautifully precise filter that quietly removes an idea I would have wanted to notice. The judgment happens later.

I can do this because the IETF makes its work queryable

There is another part of this experiment that deserves more attention than the particular script I wrote.

I can build this tool because the IETF makes it remarkably easy to do so.

The Datatracker has a well-documented public API backed by the same underlying models used to manage information about IETF documents and groups. That means I can ask the system questions about the standards process instead of scraping pages or manually maintaining my own parallel database.

That is a significant form of openness.

Standards organizations generally think seriously about whether meetings are open, specifications are publicly accessible, mailing lists can be read, intellectual-property policies are clear, and participation rules are documented. Those things remain important.

Increasingly, though, there is another question worth asking: Can people build tools on top of the information the organization already has about its work?

The W3C provides a public API as well, including access to information about groups and specifications, and adding W3C activity to my tracker is on my to-do list.

I would eventually like to look across organizations rather than treating each standards body as its own information universe.

If you know of other standards organizations working on identity, AI, authorization, credentials, agents, or adjacent areas that expose useful APIs or similarly structured public data, I would genuinely like to hear about them.

Every radar has blind spots

Even with the tools available, there will be plenty I miss. Some conversations start in research communities. Some emerge in industry consortia. Some begin in GitHub issues long before anyone thinks of writing a formal specification. Others happen in hallway conversations, company meetings, workshops, or informal groups before there is anything public to monitor.

Terminology is another problem. The words I use to construct today’s query may not be the words people use to describe tomorrow’s problem.

And institutional boundaries are increasingly unhelpful when trying to understand technologies such as AI agents. Authentication may be discussed in one organization, authorization somewhere else, agent communication in a third, credentials in a fourth, and security considerations scattered across all of them.

No query is going to make that tidy. The goal of the tracker, then, isn’t completeness. It is to make one portion of an enormous information environment more tractable.

Keeping up is mostly deciding what deserves attention

I used to think that being good at following standards meant knowing what was happening everywhere. The longer I do this work, the less plausible that seems.

What matters more is having enough awareness to recognize when something deserves closer attention, enough understanding of the process to distinguish an experiment from emerging consensus, and enough context to know where to go next.

That means accepting that I will miss things. Everyone will. It also means building better ways to notice what we can.

The standards world is too large to fit inside anyone’s head. A good radar does not solve that problem. It gives you a fighting chance of noticing the interesting blip before it disappears over the horizon.

📩 Want to stay updated? I write about digital identity and related standards—because someone has to keep track of all this! Subscribe to get a notification when new blog posts go live. No spam, just announcements of new posts. [Subscribe here] 

Transcript

Standards development is generally slow.

At least, that’s the reputation.

And I can’t actually think of a case where that’s not true.

A specification can take years to move from an initial proposal through:

• Debate
• Implementation
• Revision
• Consensus
• Review
• Publication

But that’s only looking at one end of the picture.

At the beginning of the standards process, new ideas are appearing constantly.

New drafts are published.

Existing drafts change.

Similar proposals emerge in different organizations.

Conversations start in one group and move somewhere else.

Someone introduces a new term for a problem another community has been discussing for years.

So while standards themselves may move slowly, the flow of ideas feeding the standards process does not.

That creates a practical problem for anyone trying to follow what’s happening.

You cannot keep up with everything.

I certainly can’t.

And it’s kind of my job.

Increasingly, I think pretending otherwise is actually a bad way to approach the problem.

So instead, I’m trying to build a reasonably useful radar.

---

Building a Standards Radar

For the IETF, I have a small tool running on GitHub that queries the Data Tracker every day.

The Data Tracker is the platform the IETF uses to manage information about:

• Internet-Drafts
• Working groups
• Meetings
• Agendas
• Minutes
• Presentations
• Other standards process infrastructure

My tool looks for new and updated Internet-Drafts that appear relevant to:

• Identity
• Artificial intelligence
• The increasingly crowded intersection between the two

Every day, it produces a report.

I do not read every document in every report.

That would simply turn one impossible task into another impossible task.

Instead, I periodically skim through the reports and look for things that catch my attention.

Sometimes the subject is already familiar.

Sometimes several drafts appear to be circling the same architectural problems.

Sometimes I recognize an author whose work I know.

And sometimes the title alone is enough to make me wonder what on earth someone is proposing.

Other times, someone simply makes me think:

“Huh. That could be interesting.”

And that’s often the beginning of a much longer investigation.

---

An Early Warning System for Standards

The report isn’t really about reading through a list.

It’s an early warning system for what might be interesting.

That distinction matters.

I’m deliberately looking at things early, before anyone knows whether they’re going anywhere.

That gives the radar some utility.

But it also means the results contain a lot of noise.

And that’s okay.

The goal isn’t to create a perfectly precise list of everything that matters.

The goal is to notice something that might deserve a closer look.

---

An Internet Draft Is Not a Standard

There’s an important distinction here, especially if you don’t spend much time around the IETF.

The existence of an Internet-Draft does not mean that the IETF has decided to standardize whatever the document proposes.

A great many Internet-Drafts begin as individual submissions.

Someone has an idea.

They write it down.

They publish it in Internet-Draft format.

Other people can then:

• Read it
• Argue about it
• Build on it
• Ignore it
• Decide that the underlying problem is worth exploring

That low barrier for entry is useful.

Standards communities need a way for ideas to enter the system before consensus exists.

However, it also means that finding an Internet-Draft tells you much less than you might assume.

Some drafts will eventually be:

• Adopted by working groups
• Developed into RFCs
• Used to shape another document

Others will provoke useful discussions.

Many will simply expire.

---

Awareness Is Not Understanding

Earlier this year, I wrote a longer post about how the standards process works and why terms such as draft can be misleading if you don’t know where a document sits within a particular organization’s process.

For my purposes here, the important part is that my tracker is deliberately looking at things early.

I want to see ideas before anyone knows whether they’re going anywhere.

That means I need to distinguish between two very different things:

Awareness and understanding.

The tracker can make me aware that something exists.

Understanding:

• Why it matters
• Whether it matters
• Where it might be going

still requires context.

And that’s where the real work begins.

---

What Happens After a Draft Catches My Attention

Once a draft catches my attention, I start asking questions.

For example:

• Who wrote it?
• Are the authors active in an existing working group?
• Have they presented the idea at an IETF meeting?
• Is there discussion on a mailing list?
• Is there discussion in meeting notes?
• Are people debating whether the problem is worth solving?
• Are they already arguing about the proposed solution?
• Are there competing drafts?
• Are there different approaches to the same problem?

I also want to know whether someone is suggesting the work go through:

• A dispatch process
• A Birds of a Feather session
• Another mechanism for determining where the work belongs

Then I look beyond the IETF.

Are implementers involved?

Does this connect with work happening somewhere else?

Those questions often tell me far more about what’s happening than the document itself.

The draft tells me someone cared enough about the idea to write it down.

The surrounding conversation starts to tell me whether anyone else cares.

---

Why Context Matters More Than the Document

A document can tell you that an idea exists.

It cannot necessarily tell you whether the idea has momentum.

That requires looking at the surrounding ecosystem.

For example, a draft may be:

• A serious proposal gaining traction
• An early exploration
• One of several competing approaches
• A useful contribution to another effort
• An idea that will eventually disappear

Without context, those situations can look remarkably similar.

That is why a standards radar cannot simply be a document collector.

It needs to help identify where further investigation is worthwhile.

---

Could AI Solve the Problem?

It’s tempting to think this is exactly the kind of problem AI should solve.

There is too much information.

Machines can process more information than people can.

Therefore, why not hand everything to an AI system and ask it to tell us what matters?

I’m not convinced.

Automation can reduce the cost of discovery enormously.

It can:

• Detect that a document has appeared
• Compare versions
• Extract metadata
• Find keywords
• Group related material
• Summarize documents
• Suggest where to look next

All of that is useful.

But deciding what will become important is a very different problem.

---

Why Keywords Are Not Enough

A technically interesting individual draft might go nowhere.

A boringly titled document inside an active working group might quietly become critical infrastructure.

A proposal that doesn’t use the word identity may have enormous identity implications.

Consider work involving:

• Delegation
• Authorization
• Provenance
• Credentials
• Agents
• Trust
• Attestation

These topics may intersect with the same architectural questions without sharing the vocabulary I happen to put into my search query.

The opposite happens, too.

A document may contain every keyword I’m watching and still have very little relevance to the issues I care about.

People working at the application layer don’t necessarily talk about things in the same way as someone working at the network layer.

And yet the words may be the same.

---

Why I Prefer a Noisy Report

I’ve intentionally designed my report to be noisy.

I would rather discard false positives than build a beautifully precise filter that quietly hides something I might have wanted to notice.

That means the machine performs the first pass.

The judgment comes from me.

That’s an important distinction.

Automation is excellent at helping me answer:

“What appeared?”

It is much less reliable at answering:

“What matters?”

Those are different questions.

And the second one requires context, experience, and judgment.

---

Open Standards Data Makes This Possible

There’s another part of this experiment that deserves attention, particularly for people in leadership roles and standards organizations.

I can do this with the IETF because the IETF makes it remarkably easy to do.

The Data Tracker exposes an API.

That means I don’t have to:

• Scrape web pages
• Manually maintain my own database
• Track every GitHub issue
• Reconstruct the standards process myself

Instead, I can query structured information that the IETF already maintains.

This is a form of openness that I think we should talk about more.

---

Transparency Is More Than Publishing Documents

Standards organizations quite reasonably spend a lot of time thinking about transparency.

For example:

• Are specifications public?
• Can people attend meetings?
• Are mailing lists archived?
• Is the process documented?
• Can someone tell how a decision was made?

All of those questions matter.

But there’s another question becoming increasingly important:

Can people build tools on top of the information the organization already publishes about its work?

That’s a different dimension of transparency.

Public information becomes considerably more useful when it is structured and accessible enough for people to build new tools and analysis around it.

---

Looking Beyond One Standards Organization

The W3C also has an API.

I don’t think it’s quite as well documented, but adding W3C activity to my tracker is on my list of things to do.

Eventually, I’d like to look across organizations rather than treat every standards body as a completely separate information environment.

That’s important because ideas don’t stay inside organizational boundaries.

A problem involving AI agents might involve:

• Authentication in one organization
• Authorization somewhere else
• Credentials in a third
• Security architecture in a fourth

There is no query in the world that is going to make that depth of information tidy.

And that’s okay.

---

Completeness Cannot Be the Goal

Completeness isn’t realistic.

Ideas can start in:

• Research groups
• Industry consortia
• GitHub issues
• Hallway conversations
• Workshops
• Company discussions
• Informal communities

Some may never become formal specifications.

Terminology changes constantly.

Institutional boundaries don’t help much, either.

So the goal cannot be to create a perfect map of everything happening everywhere.

Instead, the goal is to make one part of an enormous information environment more manageable.

That’s a much more useful objective.

---

What It Means to Keep Up With Standards

I used to think that being good at following standards meant knowing what was happening everywhere.

I don’t think that’s realistic anymore.

What matters more is having enough:

• Awareness to notice when something deserves attention
• Understanding of the process to distinguish an interesting proposal from emerging consensus
• Context to know where to investigate next

That requires accepting something uncomfortable.

You’re going to miss things.

Everyone does.

The standards world is simply too large to fit inside any one person’s head.

---

Build Your Own Radar

A useful radar doesn’t solve the information problem.

But it gives you a better chance of seeing the interesting blip before it disappears over the horizon.

And this may be something you want to build for yourself.

Your areas of interest may be completely different from mine.

That’s fine.

The important thing is to identify:

• What you need to watch
• Where that information lives
• Which signals are worth collecting
• How much noise you are willing to tolerate
• When human judgment needs to take over

Building these kinds of radar tools is actually much easier than it used to be.

You don’t need to follow everything.

You need a system that helps you notice what deserves your attention.

---

Final Thoughts

The standards ecosystem is too large, too distributed, and too fast-moving for any one person to follow completely.

Trying to keep up with everything is therefore the wrong goal.

Instead, build a useful radar.

Let automation handle the first pass.

Use structured public data where it is available.

Accept some noise.

Then apply human judgment to determine:

• What matters
• Why it matters
• Where it might be going
• What you should investigate next

The goal isn’t perfect awareness.

It’s useful awareness.

---

Conclusion

Keeping up with standards does not mean knowing everything that’s happening.

It means developing enough awareness to notice interesting signals, enough context to understand what those signals might mean, and enough judgment to decide what deserves deeper investigation.

A small standards radar can turn an impossible information problem into something manageable.

You will still miss things.

That’s inevitable.

But you may notice the important thing before it disappears over the horizon—and sometimes, that’s enough.