“If you’ve read (and bookmarked!) my Field Guide to Digital Identity Standards Bodies, you’ll know that one of the recurring challenges in this space is understanding how different standards bodies actually work, not just what they publish when they’re done.”

This is going to be clearer as you compare what I’m writing in this post with what I wrote about the OpenID Foundation’s Digital Credentials Protocol (DCP) Working Group a few weeks ago. OpenID’s process is relatively open: drafts are public, discussions happen in the open, and it’s possible to trace how ideas evolve, even when the answers are still unsettled.

FIDO Alliance is different.

This post is not, and cannot be, a blow-by-blow account of a particular FIDO working group. I’m not a FIDO member, and even if I were, the membership agreement is explicit about what participants can and cannot discuss while work is underway. That’s by design, and it’s something worth understanding rather than working around.

So instead of trying to report on work in progress, this post steps back and looks at FIDO more generally: how its structure differs from other standards organizations, why its development process is intentionally closed, and what can responsibly be said about the work happening there from the outside.

If the goal of this series is to help people navigate the standards ecosystem with clearer expectations, FIDO is an important case study, precisely because it doesn’t behave like OpenID, the IETF, or the W3C.

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!

FIDO creates freely available standards via a closed development process

FIDO’s mission is public and straightforward: replace passwords with stronger, phishing-resistant authentication through interoperable, royalty-free specifications. In that sense, its outputs clearly fall under what many people would call open standards.

But as I’ve written before, open is an overloaded term. It can describe who can implement a specification, how IP is handled, whether drafts are visible during development, or who is allowed in the room while decisions are being made. Those things are often conflated, and FIDO is a good example of why they shouldn’t be.

FIDO Alliance produces open outcomes, but the path to those outcomes runs through a member-only development process governed by a formal membership agreement. That agreement spells out, among other things:

• What information is confidential during development
• Who can participate in which groups
• What can and cannot be discussed publicly before approval

As a result, people participating in FIDO working groups are often explicitly prohibited from talking about drafts, debates, or design decisions while the work is ongoing. That makes “inside baseball” blog posts not just difficult, but inappropriate.

So instead of trying to narrate the play-by-play, it’s more useful to step back and explain how the system works, and what kinds of work are happening, even if the details remain private for now. That distinction—free standards, closed development—is essential to understanding how FIDO operates and why its public signals look the way they do.

Why you won’t see much detail until late in the process

If you’re used to following work at places like the IETF or the OpenID Foundation, FIDO can feel oddly quiet.

There are no public draft repos to skim. No long issue threads to lurk in. No early signals about which ideas are gaining traction and which are being set aside. From the outside, it can look like very little is happening until suddenly a document appears, already fairly mature. That’s on purpose.

FIDO’s process is designed to keep most of the messy, exploratory work private until there’s something concrete enough to stand behind. Early drafts, half-formed proposals, and unresolved disagreements stay inside the working group while participants sort out feasibility, interoperability, IP commitments, and real-world deployability. By the time something is shared more broadly, many of those hard questions have already been wrestled with.

There’s a tradeoff here. You lose visibility into how ideas evolve, and you don’t get to watch consensus form in real time. But what you gain is a signal that, when something does become public, it has already cleared a high bar. It’s not a sketch or a thought experiment; it’s the result of sustained, and often difficult, collaboration among organizations that don’t normally agree on much.

So the quiet isn’t a lack of activity. It’s the sound of work happening behind closed doors that only becomes visible once it’s stable enough to matter.

What can be said responsibly

Even with those constraints, a few things are always fair game:

• The problem space FIDO is trying to address
• The architectural direction implied (though not guaranteed) by past and published specs
• The ecosystem pressures driving new work (regulation, phishing, platform shifts, deployment pain)
• How FIDO’s governance shapes outcomes, for better or worse

Those lenses let you understand why a new effort exists without speculating about its internals.

Working groups, committees, and SIGs: what’s the difference?

One source of confusion when people look at FIDO Alliance from the outside is that not all “groups” inside FIDO are the same thing. The membership agreement is very explicit about working groups. They are formally chartered by the board, tightly scoped, and responsible for producing concrete deliverables: specifications, requirements documents, or other official publications. Working groups have chairs, editors, voting rules, and a clearly defined approval path. They are also where the strict confidentiality and IP obligations apply most directly, because this is where standards are actually written.

In other words, if a FIDO specification exists, it came out of a working group, and it went through a lot of process to get there.

Special interest groups and committees play a different role.

They are not chartered to produce specifications. Instead, they exist to explore problem spaces, coordinate across efforts, share deployment experience, or look ahead at emerging issues that might eventually justify formal standards work. You can think of them as places where ideas are tested, refined, and sometimes abandoned before anyone commits to the overhead of a working group.

That distinction is important, and it’s why you’ll often hear about activity in SIGs long before you ever see a new spec effort announced. If FIDO were more open, this would be more like a W3C Community Group or an ongoing IETF Birds-of-a-Feather (BoF) (some squinting may be required to see that, but it’ll do for the sake of this post).

The full list

If you want to see what’s officially on the table today, FIDO publishes the current lists:

• Working groups: https://fidoalliance.org/members/working-groups/
• Committees and special interest groups: https://fidoalliance.org/members/committees-and-special-interest-groups/

Those pages are best read as a directory, not a progress report. They tell you what groups exist and who is formally in leadership—chairs, co-chairs, and vice-chairs—but they don’t reliably indicate how active a group is right now. Some are humming along; others may be quiet for long stretches (or effectively dormant) until there’s renewed interest, staffing, or a concrete deliverable to push forward.

If you’re trying to understand what’s actually moving, the most straightforward approach is also the most human one: use the leadership list and reach out to the chairs. You won’t get details on in-progress work, but you can usually get a reality check on whether a group is active, what its scope is supposed to be, and whether there’s a public milestone worth watching for.

(And sometimes the answer is “this exists on paper more than in practice,” which is useful information all by itself.)

Why this matters for implementers and policymakers

If you’re building authentication systems or writing policy that depends on them, it’s tempting to dismiss closed processes as irrelevant or unresponsive. That’s usually a mistake.

FIDO specifications tend to surface after hard questions have already been fought through. They’ve already talked about threat models, deployment realities, backward compatibility, and legal risk. When a document finally becomes public, it often reflects years of negotiation.

Understanding how FIDO works helps you interpret what it publishes and when it’s worth paying attention.

📩 If you’d rather track the blog than the podcast, I have an option for you! Subscribe to get a notification when new blog posts go live. No spam, just announcements of new posts. [Subscribe here] 

Transcript

Introduction to the Digital Identity Digest

---

[00:00:04]
Welcome to the Digital Identity Digest, the audio companion to the blog at Spherical Cow Consulting.

I’m Heather Flanagan, and each week I break down interesting and sometimes messy topics in digital identity — from credentials and standards to browser behavior and policy twists.

If you work in 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.

---

Why Writing About the FIDO Alliance Is Hard — and Why It Still Matters

---

[00:00:30]
You could call this episode “Why Writing About the FIDO Alliance Is Hard — but Why It Still Matters.”

If you’ve read my Field Guide to Standards Organizations, you may have noticed a recurring theme: standards don’t just differ in what they produce — they differ dramatically in how they get there.

That distinction matters far more than many people realize.

---

Comparing Standards Processes: OpenID vs FIDO

---

[00:01:15]
That difference becomes especially clear when you compare the FIDO Alliance with the OpenID Foundation.

For example, the OpenID Foundation’s Digital Credentials Protocol Working Group operates in a highly visible way:

• Drafts are public
• Repositories are open
• Issue threads are accessible
• Disagreements play out in real time

In contrast, the FIDO Alliance does not work that way — and that’s not a flaw.

It’s a deliberate design choice.

---

What This Post Is — and Is Not — About

---

[00:02:05]
This episode isn’t an attempt to describe what’s happening inside any specific FIDO working group.

I’m not a FIDO member, and even if I were, the membership agreement is explicit about what participants can and cannot discuss while work is in progress.

Detailed reporting wouldn’t just be difficult — it would be inappropriate.

Instead, this post takes a step back to explain:

• How FIDO works at a structural level
• Why it’s organized the way it is
• How to interpret its signals from the outside

Without that context, silence is easy to misread.

---

What “Open Standards” Really Means

---

[00:03:05]
Let’s start with the phrase that causes the most confusion: open standards.

FIDO’s mission is public and straightforward — to replace passwords with stronger, phishing-resistant authentication using interoperable, royalty-free specifications, commonly known as passkeys.

By that definition, FIDO absolutely produces open standards.

However, open is an overloaded term.

Depending on who’s speaking, it might mean:

• Anyone can read drafts
• Anyone can participate
• The specifications are royalty-free
• Or some combination of the above

When those meanings get blurred together, people end up talking past each other.

---

Open Outcomes, Closed Development

---

[00:04:20]
FIDO produces open outcomes:

• Publicly available specifications
• Designed for broad implementation
• Backed by royalty-free IP commitments

But the path to those outcomes runs through a member-only development process, governed by a formal membership agreement.

That agreement defines:

• What information is confidential
• Who can participate
• What cannot be discussed publicly before approval

As a result, participants are often explicitly prohibited from talking about drafts or debates while work is ongoing.

That’s why commentary tends to appear only after documents are approved and published.

Again, this isn’t accidental — it’s structural.

---

Why FIDO Feels Quiet from the Outside

---

[00:05:35]
If you’re used to following organizations like the IETF, W3C, or OpenID Foundation, this structure can feel uncomfortable.

Those environments train us to expect visibility:

• Public mailing lists
• Early drafts
• Open disagreement

FIDO doesn’t provide those signals.

From the outside, it can look like nothing is happening — until something appears fully formed.

That can feel abrupt, opaque, or even suspicious if you don’t understand the process.

---

What Happens Behind Closed Doors

---

[00:06:35]
Inside FIDO working groups, the messy exploratory work stays private.

Participants wrestle with questions like:

• Will this work across platforms?
• Does it introduce new security or privacy risks?
• Can vendors outside the room implement it?
• Does it collide with existing deployments?

By the time something becomes public, many of these questions have already been argued through — sometimes painfully.

The trade-off is clear:

• You lose visibility into how ideas evolve
• But when something does surface, it’s already cleared a high bar

What you see is no longer a brainstorm — it’s the product of sustained collaboration among competitors.

---

Working Groups vs Special Interest Groups

---

[00:08:05]
Another common point of confusion is the difference between working groups and special interest groups.

Working groups are:

• Formally chartered by the board
• Defined by scope and deliverables
• Led by appointed chairs and editors
• Subject to formal voting and approval

If a FIDO specification exists, it came out of a working group.

Special interest groups serve a different purpose. They exist to:

• Explore problem spaces
• Share deployment experience
• Test whether ideas are mature enough

Some ideas graduate into working groups. Others don’t — and that filtering is a strength, not a failure.

---

Reading FIDO’s Public Signals

---

[00:09:30]
FIDO publishes lists of its working groups and special interest groups, but these are best read as directories — not progress reports.

They tell you:

• Which groups exist
• Who leads them

They don’t tell you how active a group is.

If you want to understand what’s really moving, the most reliable signal is still human contact.

Reaching out to group leadership can clarify:

• Whether a group is active
• What its scope really is
• Whether there are public milestones to watch

Sometimes the answer is simply, “Not much is happening right now.”
That’s useful information too.

---

The Trade-Offs of Closed Processes

---

[00:10:25]
Closed processes come with real downsides.

They require trust:

• Trust that decisions were made reasonably
• Trust that your concerns were considered

They also make it harder for newcomers to understand how decisions were made.

But in FIDO’s case, this structure enables something critical — allowing competitors to collaborate on shared authentication infrastructure while managing legal, competitive, and IP risks.

That collaboration is exactly what makes interoperable authentication possible.

---

Final Thoughts on Interpreting FIDO’s Silence

---

[00:11:00]
When FIDO feels quiet, it’s not inactivity.

It’s work happening behind closed doors — work that only becomes visible once it’s stable enough to matter.

Understanding how FIDO operates helps you interpret both what it publishes and what it hasn’t published yet.

In an ecosystem where open can mean many things, clarity about process matters.

I hope this made things a little clearer — or at least more interesting.

This post may be updated as processes evolve, so stay tuned, and good luck with your standards work.