“Standards organizations spend a great deal of time thinking about transparency, and for good reason.”

Public specifications, open issue trackers, archived mailing lists, meeting minutes, documented processes, and accessible repositories all make it possible for people outside the core group of participants to see how work develops. That kind of openness matters.

But there is a practical problem that becomes obvious the moment you try to follow more than a small amount of standards work: making information public does not necessarily make the process understandable.

A standards organization can expose every relevant artifact and still leave outsiders with an enormous amount of work to do before they can answer basic questions about what is actually happening.

Which documents matter? Which ones are exploratory? Which groups own the work? Where is the active discussion? What has changed recently? Who has been involved over time? Which related efforts are converging, competing, or quietly fading away?

For people who spend years inside a particular standards community, much of that context becomes second nature. Everyone else has to reconstruct it.

The idea of standards transparency has room for improvement.

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!

Public information still carries a high cognitive cost

Most mature open standards organizations already publish a great deal. You can (usually) find specifications, drafts, repositories, mailing-list archives, meeting agendas, minutes, group charters, issue trackers, and participation information on their website or in GitHub repositories. In some cases, you can trace a piece of work back through years of discussions and revisions.

The challenge is that these artifacts often make sense only when you already know how the organization works.

An experienced participant may immediately recognize that a document is still an individual proposal rather than adopted work. They may know that a particular mailing list is no longer where the important discussion happens. They may understand that one group has effectively taken over a problem previously discussed elsewhere, or that a draft with an unimpressive title is actually central to a larger architectural debate.

All that knowledge rarely lives in one place. It accumulates over time through participation, repetition, relationships, and familiarity with the organization’s process. Which works reasonably well for the people who can afford to stay deeply involved. It works much less well for everyone else.

Most people do not have time to become standards insiders

It’s easy for people deep in the weeds of standards development (myself included) to forget that the audience for standards work is much broader than the set of people who actively develop standards.

Implementers need to understand what may affect their products. Enterprise architects want to know which ideas are gaining traction before making long-lived design decisions. Policymakers and regulators need to distinguish established standards from emerging proposals. Researchers want to trace how technical ideas develop across organizations. Journalists and analysts need enough process context to avoid overstating what a draft represents.

Even active standards participants face the same problem when they look beyond their immediate area. I personally would love to know what’s going on in DNS-land that might impact digital identity, but I’m not going to even try to figure out where those conversations started.

Nobody can live inside every working group, community group, technical committee, task force, or mailing list that might eventually affect their work.

As the overlap between fields grows, that problem becomes more acute. Identity work increasingly intersects with AI, privacy, security, payments, provenance, and a long list of adjacent topics. Important ideas may emerge in several organizations at once, often under different terminology.

At some point, the problem stops being access to information and becomes the cost of making sense of it.

This is where better tooling starts to matter

In my previous post, I described the small standards radar I built around the IETF Datatracker. It runs a daily query for new and updated Internet-Drafts related to identity and AI, then gives me a report I can skim when I have time. Other people have created similar tools.

The useful thing about that experiment is not the tracker itself: It’s what the IETF Datatracker makes possible.

The Datatracker exposes structured information about documents, working groups, meetings, document state, authorship, and related activity through an API. That means I can build my own way of navigating the work rather than depending entirely on the interfaces the IETF provides for human browsing.

The W3C also provides an API, and adding W3C activity to the same monitoring system is on my list.

What interests me here is the broader pattern. When standards organizations expose structured information about their process, other people can build tools that answer questions the organization itself may never have anticipated.

That could mean a personal monitoring system like mine. It could mean a dashboard for implementers, a research tool for tracing document histories, a service that shows related work across standards bodies, or an interface that helps policymakers distinguish mature standards from speculative proposals.

The API does not create understanding by itself. It lowers the cost of building tools that can help people get there.

What useful process transparency should make easier to answer

If the goal is to help people understand what is happening, then some kinds of information are especially useful.

A reader should be able to determine the current status of a document, which group owns it, whether the work has been formally adopted, how recently it has changed, and what other documents it relates to. They should also be able to find where the active discussion is happening, what decisions have already been made, and whether implementation work exists.

Contributor history can be useful context as well. Knowing who has been involved, how long they have worked in the area, whether several organizations are represented, and whether participation extends beyond a single interested party can help someone evaluate how much attention a proposal has attracted.

Those signals do not prove technical quality or consensus, and they should not be treated as substitutes for reading the work. They do help establish provenance and context. The key point is that this information already exists in most standards communities. The question is how much effort a person must invest to assemble it.

Institutional knowledge should not be a prerequisite

Of course, some amount of insider knowledge will always matter. Going to work for a new employer means learning a new work culture, new processes, and new people, even if you’re still in the same field. It’s no different here.

Standards development is a social process, and no metadata model is going to capture every important dynamic. A working group can be technically active while enthusiasm for a particular draft is fading. A formally correct process state may not tell you whether implementers are excited about the work. A document can have strong backing from respected contributors and still be a bad idea.

Structured data does not remove ambiguity.

But there is a large gap between accepting that some context will always require judgment and requiring someone to spend years inside an organization before they can understand the basics. If a person needs to know which standards work deserves attention, they should not have to reverse-engineer the organization first.

That is where better process transparency can make a meaningful difference.

AI makes the gap more visible

AI systems add another dimension to this problem because people increasingly use them to summarize technical work they do not have time to read directly. That creates both an opportunity and a risk.

A system with access to good process information can help someone answer useful questions: What changed this month? Which drafts are newly active? Which groups are working on related problems? Which documents have moved from individual proposals into adopted work?

A system working from incomplete or weakly structured information has to infer much more. I think that is where things go wrong.

A search result may find several Internet-Drafts and describe them collectively as “IETF standards work,” even if none have been adopted by a working group. A model may fail to distinguish an old document from active work, or miss that the discussion has moved elsewhere entirely.

People who already know the process may catch those mistakes immediately. People using a tool precisely because they lack that context may not, which makes the quality of underlying process information more consequential.

AI did not create the need for better standards transparency, but it definitely makes the cost of ambiguity easier to see. There’s too much going on and no way to stay fully abreast of it all.

Better transparency supports better decisions

The value of all this is not simply convenience, though that convenience is nothing to scoff at. People make real decisions based on their understanding of standards development.

Companies, which are made up of people (despite rumors to the contrary), decide where to invest engineering effort. Architects make choices that may last for years. Governments reference technical standards in policy and regulation. Implementers decide which specifications are mature enough to depend on. The administrators of standards organizations themselves need to understand where overlapping work is emerging. Better tooling can help people make those decisions with more context and less guesswork.

That is especially important for people who do not have the time, access, or inclination to participate deeply in every relevant standards community. A good standards ecosystem should not require that level of immersion just to understand the state of play.

Transparency should include understandability

I don’t think standards organizations need to build every possible interface or predict every future use of their process data. I mean, they could try, but I don’t think it’s the best use of their time.

They do, however, need to think about whether the information they already publish is structured and accessible enough for others to build on. That means treating document state, provenance, relationships, history, group ownership, and other process information as part of the transparency story rather than as internal administrative details.

Open archives remain important. Public repositories remain important. Accessible meetings and documented procedures remain important.

The next step is making it easier for people to understand the relationships among all of those things. Because when a standards process is technically public but only understandable to people with years of accumulated institutional knowledge, there is still a transparency problem.

And as the number of standards, organizations, and overlapping technical domains continues to grow, solving that problem will matter to far more people than the standards insiders who already know where to look.

📩 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 organizations spend a lot of time thinking about transparency.

And rightly so.

Specifications should be available.

Processes should be documented.

Where practical, meeting minutes, mailing lists, and issue trackers should be open.

People should be able to see how the work develops. Depending on the organization, they should also be able to participate in that development.

All of that is important.

But there is a problem that becomes increasingly obvious when you try to follow more than a tiny corner of the standards world.

Making information public does not necessarily make the work understandable.

A standards organization can publish nearly everything and still leave someone with a formidable research project before they can answer relatively straightforward questions:

• Which documents actually matter?
• Which ones are exploratory ideas?
• Has a group agreed to work on this yet?
• Where is the active discussion happening?
• What changed recently?
• Who has been involved?
• Is the work gaining momentum?
• Or did it quietly stop moving six months ago?

For people deeply embedded in a particular standards organization, many of these questions are relatively easy to answer.

The answers are part of the institutional knowledge they have accumulated through years of participation.

Everyone else has to figure it out.

And I think that is part of standards transparency that deserves much more attention.

---

Transparency Is More Than Publishing Documents

Most mature standards organizations publish a tremendous amount of material.

You can find:

• Specifications
• Drafts
• Meeting agendas
• Meeting minutes
• Mailing list discussions
• Issue trackers

That’s a good thing.

However, the challenge comes when you need to understand how all of those pieces actually fit together.

An experienced participant may look at a document and immediately recognize it.

They may know:

• Whether it is an individual proposal
• Whether a working group has adopted it
• Where the interesting discussion is happening
• Which authors have been working on the problem for years
• Which contributors are new to the area

None of that necessarily appears on the first page someone finds through a search engine.

That context accumulates through participation.

And participation takes time.

---

Who Needs to Understand Standards Work?

This might be acceptable if the only people who needed to understand standards were the people writing them.

That’s obviously not the case.

Many different groups depend on understanding standards activity.

Implementers

Implementers need to understand which emerging work may affect the products they’re building.

They need enough context to distinguish an interesting proposal from something likely to become a real dependency.

Enterprise Architects

Enterprise architects need to know whether an emerging technical approach is likely to become relevant before making design choices that could last for years.

A decision made today may create technical constraints long before a standard is formally published.

Policymakers and Regulators

Policymakers and regulators increasingly need to understand technical standards well enough to reference them appropriately.

That requires more than simply finding a specification.

They need to understand its maturity, status, and relationship to other work.

Researchers, Journalists, and Analysts

Researchers want to trace how ideas evolve.

Journalists and analysts need to distinguish an experimental proposal from something an organization has actually agreed to pursue.

And people participating in one standards organization often need to follow related work happening somewhere else.

That last category is particularly important.

Even standards professionals cannot follow everything.

---

Identity Work Crosses Organizational Boundaries

Identity is a particularly good example.

It increasingly overlaps with:

• AI agents
• Security
• Privacy
• Payments
• Data provenance
• Authorization
• Credentials

Relevant work may therefore be happening simultaneously across multiple organizations.

For example:

• IETF
• W3C
• OpenID Foundation
• FIDO Alliance
• NIST
• Other national or regional standards organizations

Nobody has enough hours in the day to participate deeply in every relevant community.

Eventually, the problem becomes less about whether information is available.

The real question becomes:

How expensive is it to actually understand what is going on?

---

Building a Standards Radar

I’ve written previously about a standards radar I’ve been experimenting with.

It uses the IETF Data Tracker API to look for new and changing Internet-Drafts related specifically to identity and AI.

I periodically skim the resulting reports, notice the things that look interesting, and then investigate.

I’m not going to repeat the mechanics here.

The important point for this discussion is what building that tool taught me about the underlying standards infrastructure.

The Data Tracker doesn’t merely provide pages that I can browse.

It also exposes structured information about:

• Documents
• Groups
• Authorship
• Status
• Meetings
• Other parts of the standards process

That changes what is possible.

---

Structured Data Makes New Views Possible

Because the underlying information is structured, I can build a different view of the IETF’s work around the questions that I happen to care about.

The W3C has an API as well, and adding W3C activity to my tracker is something on my list.

This raises a much broader possibility.

Standards organizations do not need to anticipate every way someone might want to explore their work.

Instead, if they make the underlying process information sufficiently accessible and structured, other people can build tools around their own needs.

For example:

• An implementer might want a dashboard showing specification changes affecting a particular product.
• A researcher might want to trace the history of related proposals.
• A policymaker might need to distinguish mature standards from earlier work.
• Someone working in another standards organization might want to detect overlapping work.

My needs are different again.

I mostly want a radar that tells me when something might be interesting enough to investigate.

The common requirement is good underlying data.

---

What Information Should Be Easy to Find?

Think about the questions someone might reasonably ask when encountering unfamiliar standards work.

They might ask:

• What is this document?
• Who owns it?
• Has anyone actually adopted it?
• Is this work moving forward?
• How mature is it?
• When was the last time anyone did anything with it?
• Are there related documents?
• Where is the active discussion?

Those questions do not automatically tell you whether the work is good.

That’s an important distinction.

Contributor history can be useful.

Seeing that experienced people are involved, that several organizations are participating, or that a proposal is attracting broader engagement can tell you something about its provenance.

But it does not prove consensus.

And it certainly does not prove that the technical approach is correct.

The goal is not to automate judgment.

The goal is to make informed judgment easier to accomplish.

---

Structured Information Has Limits

There are limits to what structured information can accomplish.

Standards development remains a deeply human process.

A database field can tell you that a draft is active.

It cannot necessarily tell you that everyone in the working group has quietly lost enthusiasm for it.

A document can have all the correct procedural markers while the interesting intellectual work has actually moved somewhere else.

A proposal can be backed by extremely experienced people and still be a terrible idea.

No API is going to encode every:

• Hallway conversation
• Disagreement
• Shift in momentum
• Historical relationship
• Piece of institutional baggage

Nor should we expect one to.

But acknowledging those limitations should not become an excuse for making the basics unnecessarily difficult to understand.

There is a considerable difference between accepting that good judgment requires context and requiring someone to spend years inside an organization before they can even find where that context lives.

---

AI Makes Good Source Data Even More Important

AI adds another interesting dimension.

More people will use AI systems to help navigate technical material they don’t have time to read themselves.

That can be useful.

I’ve done this myself.

For example, I’ve fed several specifications about authorization into NotebookLM and asked for a podcast-style explanation of what’s happening.

That can be genuinely helpful.

I can also imagine asking a system:

• What changed across the standards work I care about this week?
• Which new proposals appeared?
• Are several organizations tackling related problems?

But for any of that to work well, the tools need good source information.

If status, ownership, document relationships, and process history are explicit, an AI system has something solid to work with.

If those things are implicit, the system has to infer them.

And inference is exactly where things can go horribly wrong.

---

AI Cannot Fix an Unclear Standards Process

Imagine an AI system finds several Internet-Drafts related to AI and identity.

It confidently describes them as standards the IETF is developing.

But perhaps they are individual proposals that no working group has adopted.

Someone familiar with the IETF will probably spot the mistake.

Someone asking the AI system precisely because they don’t understand the IETF may not.

AI did not create the transparency problem.

Instead, it makes the consequences of unclear process information much easier to see.

That is an important distinction.

Better AI tools do not eliminate the need for good standards metadata.

They increase the value of having it.

---

Better Transparency Supports Better Decisions

Ultimately, this is about more than making standards easier to browse.

People make decisions based on their understanding of standards activity.

For example:

• Companies decide where to invest engineering resources.
• Enterprise architects decide which technologies to build around.
• Governments decide which standards to reference.
• Standards organizations need to recognize potentially overlapping work.

Better tools can help all of these people make better-informed decisions without requiring them to become full-time standards participants first.

That seems increasingly important as the number of:

• Standards organizations
• Specifications
• Overlapping technical domains

continues to grow.

---

Standards Organizations Do Not Need to Build Everything

I don’t think standards organizations need to build every dashboard, search interface, monitoring service, or AI assistant that someone might someday need.

I do think they should consider whether the information underlying their processes is structured and accessible enough that other people can build those things.

That means making key process information available and understandable enough to support new uses.

In particular:

• Document status matters.
• Provenance matters.
• History matters.
• Relationships between documents and groups matter.
• Knowing where the discussion is happening matters.

Those things should be considered part of the transparency story.

They are not merely administrative data used to operate a standards organization.

---

From Public to Understandable

We’ve done a great deal of good work making standards processes public.

For many standards organizations, specifications, discussions, meetings, and decisions are available for anyone willing to look.

The next question is whether we can make those processes easier to understand.

That means reducing the amount of institutional knowledge someone needs before they can answer basic questions.

It means making context easier to discover.

It means providing structured information that people—and increasingly, machines—can use responsibly.

Most importantly, it means recognizing that accessibility is not only about whether information exists.

It is also about whether people can make sense of it.

---

Final Thoughts

Standards transparency has traditionally focused on openness.

That’s necessary.

But openness alone is not enough.

A standards process can be technically open to everyone while remaining practically understandable only to people with years of accumulated institutional knowledge.

The goal shouldn’t be to eliminate the need for human judgment.

It should be to make that judgment easier.

Good structured data can help.

Good tools can help.

Better documentation can help.

AI can help, provided it has reliable information to work from.

---

Conclusion

Making standards information public is an important achievement.

Making it understandable is the next challenge.

The standards ecosystem is too large for anyone to participate deeply in every relevant organization. As digital identity increasingly intersects with AI, security, privacy, payments, and provenance, that challenge will only grow.

Standards organizations do not need to predict every tool people will want.

They need to make their underlying process information structured, accessible, and understandable enough that others can build those tools themselves.

Because transparency isn’t only about opening the door.

It’s also about making it possible to understand what is happening once you’re inside.