“This is not a thrilling blog post. There are no hot takes, no predictions, and no urgent calls to action. What it is is a reference.”

I spend a lot of time following and participating in standards development across a handful of open standards development organizations (SDOs): the OpenID Foundation, the W3C, the FIDO Alliance, and the IETF. These groups all shape the future of technology in general, and digital identity in specific, in different ways. They all have their own processes, norms, and decision-making structures. It’s a big learning curve, no doubt about it, to figure out where and how to participate. 

Over the coming months, I plan to do deeper dives into specific working groups and specifications that matter to the digital identity ecosystem. When I do, I’ll often be talking about where a piece of work is in its lifecycle, what kind of feedback is being sought, and how close (or far) it is from becoming something implementers can rely on.

Rather than re-explaining each organization’s process every time, this post serves as a standing reference. It lays out, at a high level, how the SDOs I follow most closely turn ideas into published standards, where exploration occurs, who can participate, and how decisions are made.

If you’re already steeped in standards work, much of this will feel familiar. If you’re newer to it, this should help explain why two “drafts” from different organizations can mean very different things. Either way, I’ll be pointing back here throughout the year as a shared baseline for understanding how this work moves forward.

Grab a beverage; this is going to be dry.

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!

tl;dr: an SDO comparison chart

How major standards bodies develop specifications.

Dimension	OpenID Foundation (OIDF)	W3C	FIDO Alliance	IETF
Participation model	Membership-based; contributors must agree to OIDF IPR policy	Membership-based, with invited experts	Membership-based; participation tied to membership class	Open to anyone; participation is individual, not organizational
Who can join WGs	Any individual or organization agreeing to IPR policy	W3C Members, invited experts, and staff	Sponsor & Board Members by default; others by invitation	Anyone may participate via mailing lists and meetings
Decision-making style	Consensus-first; formal votes when needed	Consensus-first; Director and AC oversight	Formal voting with defined thresholds	Rough consensus; no formal voting
Primary standards body unit	Working Group	Working Group	Working Group	Working Group
Open / exploratory groups (non-standards)	Community Groups — open participation, no standards output	Community Groups — open participation, incubation only	No direct equivalent; exploratory work typically happens within member-only groups	RFCs are immutable; updates via new RFCs
Can exploratory groups produce standards?	No	No	n/a	No
Purpose of exploratory groups	Idea incubation, coordination, early collaboration	Incubation, cross-community discussion, early drafting	Exploration typically occurs inside formal structures	Test interest, scope problems, and decide whether to charter a WG
Path from exploration to WG	CG output may inform a WG proposal	CG work may feed into WG chartering	WG chartered directly by Board	BOF may lead to a WG charter proposal
Early-stage documents	Contributions → Work Group Drafts	Working Drafts	Pre-Draft → Working Draft	Internet-Drafts
Mid-stage signal to implementers	Implementers Draft	Candidate Recommendation	Implementation Draft Specification	Proposed Standard
Highest internal status	Final Specification	W3C Recommendation	Proposed Standard Specification	Internet Standard
IPR participation trigger	Explicit contributor agreement	Membership / invited expert agreement	Membership agreement	Participation governed by the Note Well
Document mutability	Final specs fixed; errata via revised versions	New versions replace prior Recs	New versions required	WG chartered directly by the Board
Core emphasis	Interoperability and ecosystem alignment	Web-wide interoperability and horizontal review	Deployability and security	Deployability, operational reality, “running code”

How OpenID Foundation specifications are developed

OpenID Foundation specifications are developed through an open, consensus-driven process (described in detail here) designed to balance innovation with stability.

1. Working Group formation: New work begins in a formally chartered Working Group (WG), created through a public proposal that defines its scope, goals, and intended deliverables. Participation is open to individuals and organizations that agree to the OpenID Foundation’s intellectual property policy; only approved contributors can submit technical contributions or participate in formal decision-making, though drafts and discussions are publicly visible for broader review and feedback.
2. Contributions and Work Group Drafts: Technical work starts with contributions from approved WG participants. Once adopted by the group, these become a Work Group Draft, which is iterated openly as the WG resolves feedback and builds consensus.
3. Implementers Draft: When a draft is considered stable enough for real-world testing, the WG may advance it to an Implementers Draft. This signals that implementers can begin building against the specification while providing feedback.
4. Final Specification: After additional review and approval—both within the Working Group and across the OpenID Foundation membership—a draft may be approved as a Final Specification. At this stage, the specification is considered stable and ready for broad adoption.
5. Errata and maintenance: Final Specifications may later receive limited errata corrections to fix errors or clarify language, without changing core functionality.

Throughout this process, decisions prioritize consensus, transparency, and documented review, ensuring specifications are both technically sound and suitable for long-term interoperability.

How W3C specifications are developed

W3C specifications are developed through an open, consensus-driven process designed to support global interoperability on the Web, while balancing technical rigor, broad review, and implementer feedback. The full details regarding their process are here.

1. Working Group formation: New work at the W3C often begins with exploratory discussion in a Community Group, where participation is open, and ideas can be tested without committing to a standards track. When the work is ready to advance, it may move into an existing Working Group or prompt the creation of a new WG, which is chartered by the W3C based on a public proposal defining scope, goals, deliverables, and success criteria. Participation in a WG is open to W3C Members, invited experts, and staff; while formal decision-making is limited to group participants, technical discussions, drafts, and issues are publicly visible to enable wide review and input.
2. Draft development (Working Drafts): Technical work progresses through a series of Working Drafts, which reflect ongoing development and refinement. These drafts are explicitly incomplete and may change substantially as feedback is incorporated and consensus evolves. Drafts are reviewed not just by the working group participants but also, as they get closer to Candidate Recommendation, but also via horizontal reviews that consider potential issues around internationalization, accessibility, security, privacy, and overall architecture for the web.
3. Wide review and Candidate Recommendation: When a specification is considered feature-complete, it advances to Candidate Recommendation. This stage focuses on implementation experience—confirming that the specification can be implemented interoperably and that its requirements are clear, testable, and practical.
4. Recommendation track: After demonstrating sufficient implementation experience and resolving outstanding issues, a specification may advance through Proposed Recommendation and ultimately become a W3C Recommendation. At this point, it is considered a stable Web standard suitable for broad adoption.
5. Maintenance and updates: W3C Recommendations may later be updated, clarified, or superseded as the Web evolves. Substantive changes typically require progressing through the Recommendation track again, rather than being applied directly to an existing standard.

Throughout this process, the W3C emphasizes transparency, documented consensus, horizontal review, and real-world implementation as prerequisites for standardization. It’s also worth noting that the W3C publishes more than just specifications. Their process docs describe several different types of publications that inform the architecture and design of the World Wide Web.

How FIDO Alliance specifications are developed

FIDO Alliance specifications are developed through a member-driven Working Group process that emphasizes implementation readiness, formal voting, and strong board oversight—reflecting FIDO’s focus on deployable authentication standards. Their process is described in Section 4.4.2 of their Membership Agreement.

1. Working Group formation: All FIDO deliverables are developed within Board-chartered Working Groups. Only Sponsor Members and Board Members have full participation and voting rights; Associate and Government Members may participate without voting, and in some cases by invitation. Each Working Group is led by a Board-appointed Chair, with Editors responsible for managing technical drafts.
2. Pre-Draft and Working Draft: Work begins when a Working Group participant submits an initial draft, which is acknowledged as a Pre-Draft. With approval by a simple majority of the Working Group, it becomes a Working Draft and serves as the active basis for technical development and iteration.
3. Review Draft: When the Working Group believes a deliverable is sufficiently mature, it may advance the document to Review Draft status by a supermajority vote. Review Drafts are shared with the full FIDO membership for feedback and, for specifications, trigger a formal intellectual property review period.
4. Implementation Draft (Specifications Only): After the review period, the Working Group may recommend a specification for advancement to Implementation Draft status. This step requires approval by a supermajority vote of the FIDO Board and signals that the specification is ready for implementation and interoperability testing.
5. Proposed Standard Specification: Specifications intended for broad deployment or submission to external standards bodies (such as the IETF) may advance to Proposed Standard status. This requires a full supermajority vote of the Board and represents the highest level of maturity within the FIDO Alliance.
6. Publication and external submission: The Board controls when and how FIDO deliverables are published or shared outside the membership, and may authorize submission of Proposed Standards to external standards organizations with the appropriate intellectual property commitments.

Throughout this process, FIDO emphasizes formal voting thresholds, defined intellectual property commitments, and Board-level approval to ensure specifications are both implementable and safe for widespread adoption.

How IETF specifications are developed

The Internet Engineering Task Force (IETF) develops technical specifications through an open, individual-driven process that emphasizes broad participation, rough consensus, and real-world implementation. Unlike membership-based standards bodies, the IETF operates as an open community: participation is based on contribution, not organizational affiliation. There are a lot of process documents for that SDO, in part because it’s been around a very long time. This website is probably the best place to start if you want to dig into the details. 

1. Working Group formation and open participation: Most IETF work happens in chartered Working Groups (WGs), which are approved by the IETF leadership and scoped to solve a specific technical problem. Before a WG is formed, individuals may request up to three Birds-of-a-Feather (BoF) sessions to either explore a topic informally or, in the case of a working group–forming BoF, to develop and test support for a proposed WG charter. Anyone may participate; in fact, everyone nominally participates as an individual, not as a corporate representative. Discussions take place primarily on public mailing lists, with in-person and virtual meetings used to support progress.
2. Internet-Drafts (work in progress): All IETF specifications begin as Internet-Drafts (I-Ds). These are openly published, time-limited documents that can be revised frequently. Drafts may be authored by individuals or adopted by a Working Group; adoption signals that the WG agrees to work on the document but does not imply approval.
3. Rough consensus and Working Group review: Technical decisions in the IETF are made by rough consensus, not formal voting. WG chairs assess consensus based on discussion and sustained agreement, prioritizing technical merit and deployability over unanimity. Silence does not automatically equal consent, and unresolved objections must be addressed before work can advance.
4. IESG review and publication approval: When a WG believes a draft is ready, it is submitted for review by the Internet Engineering Steering Group (IESG). This review includes technical, security, and process checks, as well as broader community review. Approval by the IESG authorizes the document to move forward for publication as an RFC.
5. RFC publication and document types: Approved documents are published by the RFC Editor as RFCs (which used to stand for “Requests for Comment” but they gave up on that years ago). RFCs are immutable once published. Not all RFCs are standards; common categories include:
   • Standards Track (intended for interoperable implementation)
   • Best Current Practice (BCP) (operational or procedural guidance)
   • Informational (background or descriptive material)
   • Experimental (early or exploratory work)
6. Standards Track maturity (current practice): Standards Track documents typically progress from Proposed Standard to Internet Standard, based on demonstrated interoperability, implementation experience, and operational stability. While earlier versions of the process defined additional maturity levels, current practice focuses on these two stages.
7. Maintenance, updates, and obsolescence: RFCs are never revised in place. Errors are addressed through published errata, and substantive changes require a new RFC that updates or obsoletes the earlier document. This preserves a permanent, auditable technical record.

Throughout the process, the IETF prioritizes openness, transparency, and deployability—favoring specifications that can be implemented and operated at Internet scale over theoretically complete designs.

I do want to add a quick reminder here that not all RFCs are produced by the IETF; the Internet Research Task Force (IRTF), the Internet Architecture Board (IAB), and the Independent Submission stream also work with the RFC Editor to publish RFCs. What I’ve described in this post is the most common way to get an RFC published, and the only way to get an IETF standard published, but never forget that the RFC Series is more than just IETF standards.

Choosing where to take the work (it’s not just about process)

Understanding how different standards bodies operate is useful, but it’s rarely the decisive factor in where work actually lands. In practice, choosing an SDO is less about picking the “right” process and more about understanding where the conversation will be most productive.

There are no clean lines dividing one SDO from another. Authorization specifications might reasonably belong in the IETF or the OpenID Foundation. User-facing authentication, account selection, or credential presentation could sit in the W3C or the FIDO Alliance. In some cases, the work spans multiple domains — and sometimes, as with WebAuthn, it spans multiple organizations at once.

A few practical considerations tend to matter more than formal process:

Who needs to be in the room

Standards succeed when the right mix of implementers, platform vendors, and relying parties are engaged early. Some SDOs attract browser vendors and web platform architects; others draw identity providers, protocol designers, or security hardware vendors. If the people who will ultimately implement or deploy the work aren’t participating, progress will stall no matter how elegant the process.

Where the problem naturally lives

Some problems are inherently infrastructure-level: wire protocols, token formats, cryptographic mechanisms, or authorization semantics. Others are user-facing: browser behavior, consent flows, account selection, or device interactions. While there’s overlap, different SDOs have different instincts about where responsibility should sit: in the protocol, the platform, or the application layer.

Maturity and risk tolerance

Early, exploratory work often benefits from looser structures and faster iteration, while mature, widely deployed technologies demand stronger guarantees and clearer intellectual property commitments. An idea that starts as a discussion or prototype may move between organizations as it solidifies and its audience becomes clearer.

Existing momentum

Work rarely starts from scratch. A related working group may already exist, or a community may already be circling the same problem under a different name. In those cases, joining an existing venue, even if it’s not a perfect fit, is often more effective than trying to bootstrap something new.

Willingness to collaborate across boundaries

Some of the most impactful identity standards have emerged through coordination across SDOs, not strict ownership by one. WebAuthn is a clear example: developed jointly by the W3C and the FIDO Alliance, it benefited from both web platform alignment and deep authentication expertise. That kind of collaboration is harder, but sometimes necessary.

Ultimately, standards work follows people and problems more than org charts. The most successful efforts tend to start where the conversation is already happening, evolve as understanding improves, and remain open to shifting venues when the work, or the ecosystem around it, demands it.

It’s kind of messy

Standards development is rarely linear, and it’s almost never confined neatly to a single organization. The processes outlined here provide structure, guardrails, and shared expectations, but they don’t determine where good ideas come from or where meaningful progress happens.

As I dig into specific working groups and specifications over the coming months, I’ll refer back to this post to help frame what stage the work is in, what kind of feedback is being sought, and what “progress” actually means in that context. If nothing else, this should make it easier to follow along without needing to decode each standards body’s process from scratch every time.

This isn’t meant to be exhaustive, and it won’t age perfectly. That’s fine. Standards evolve, processes get revised, and communities shift. Think of this as a shared reference point, something to return to when the details start to blur. It helps to zoom out and remember how the machinery fits together.

📩 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

[00:00:00] 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.

---

Setting Expectations for This Episode

---

[00:00:26] Let’s be honest right up front: this episode is not the most exciting thing you’re going to hear today.

[00:00:36] There are no bold predictions here.
No hot takes.
No countdown to the “next big thing” in authorization.

[00:00:45] So if that’s what you’re listening for, you may want to bookmark this and come back later.

---

Why This Is a Reference Episode

---

[00:00:50] What this episode actually is, instead, is a reference.

I spend a lot of time following—and participating in—standards development across several standards development organizations (SDOs), including:

• The OpenID Foundation
• The W3C
• The IETF
• The FIDO Alliance (which I follow closely, though I don’t participate directly)

[00:01:11] These groups shape the future of digital identity and technology in very real ways.

However, they all do it differently.

---

Why Standards Feel So Different Across Organizations

---

[00:01:19] Each organization has:

• Its own culture
• Its own processes
• Its own instincts about how ideas become usable specifications

This is why a “draft” in one organization can feel stable and real, while a “draft” somewhere else feels tentative and exploratory.

[00:01:48] If you’ve ever wondered why that is, this episode is designed to explain exactly why.

---

How This Episode Fits Into Future Content

---

[00:01:57] Over the coming months, I’ll be diving deeper into specific working groups and specifications that matter to the digital identity ecosystem.

Rather than re-explaining standards processes every time, I’ll be pointing back to this episode—and its companion blog post—as a baseline reference.

[00:02:18] This makes it easier to talk about:

• Where work sits in its lifecycle
• What kind of feedback is being sought
• How close something is to real-world implementation

---

Who This Is For

---

[00:02:44] If you live and breathe standards work, much of this will feel familiar.

If you’re newer—or if you’ve only worked in one standards organization—this should help explain why similar labels can mean very different things depending on where the work lives.

[00:03:04] So yes—grab a beverage. This one is dry, but useful.

---

The Big Picture: What “Standards” Really Means

---

[00:03:08] All four organizations we’re discussing produce things we casually call “standards.”

But that doesn’t mean:

• The same process
• The same expectations
• Or the same outcomes

[00:03:25] Some organizations are membership-based.
Some are open to anyone.
Some rely on voting, while others rely on consensus.

None of these models is inherently better—they’re simply optimized for different kinds of problems.

---

The OpenID Foundation Process

---

[00:04:19] The OpenID Foundation is membership-based, but participation in working groups is relatively open once intellectual property policies are accepted.

Key characteristics of the OpenID Foundation process include:

• Formally chartered working groups
• Clearly defined scopes and deliverables
• Iterative draft development

[00:04:49] When contributions are adopted, they become working group drafts, which may iterate for quite some time.

[00:05:00] A draft may advance to an Implementer’s Draft, signaling readiness for real-world testing—but not finality.

[00:05:14] Only after additional reviews does a specification become final, at which point changes are limited to errata.

---

The W3C Standards Model

---

[00:05:50] The W3C process often begins before a working group exists.

Early exploration typically happens in Community Groups, which are:

• Open to anyone
• Explicitly not on the standards track

[00:06:31] Once work enters a formal working group, drafts progress through well-defined maturity stages.

[00:06:56] Horizontal reviews assess:

• Accessibility
• Internationalization
• Privacy
• Security
• Overall web architecture

[00:07:04] Implementation experience becomes critical at the Candidate Recommendation stage, where interoperability is tested.

---

How the FIDO Alliance Approaches Standards

---

[00:07:59] The FIDO Alliance is intentionally different.

It is strongly member-driven, with:

• Board-chartered working groups
• Board-appointed chairs
• Voting rights tied to membership class

[00:08:38] Advancing a specification requires supermajority board approval, particularly at the implementation and proposed standard stages.

This conservative approach reflects the high stakes of authentication and security work.

---

Understanding the IETF Mental Model

---

[00:09:41] The IETF requires an entirely different mindset.

Participation is:

• Open to anyone
• Individual-based (not company-based)
• Governed by the IETF Note Well

[00:10:44] All work starts as Internet-Drafts, which are:

• Public
• Time-limited
• Expected to change frequently

[00:11:07] Decisions are made by rough consensus, not voting.

[00:11:50] Once published as RFCs, documents are immutable—updates happen through new RFCs, not revisions.

---

Choosing the Right Standards Venue

---

[00:12:08] A common question is: Which process is right?

The answer is simple—it depends.

What matters most are practical considerations, such as:

• Who needs to be involved
• Where the problem naturally lives
• How mature the idea is
• How much ecosystem risk is acceptable

[00:13:07] Standards work tends to follow people and problems more than organizational charts.

---

Final Thoughts and Looking Ahead

---

[00:13:43] This episode isn’t exhaustive, and it won’t age perfectly—and that’s okay.

Standards evolve.
Processes change.
Communities shift.

[00:14:06] Think of this as a shared reference point—a way to zoom out when the details start to blur.

---

Closing the Episode

---

[00:14:16] If you made it this far, thank you for sticking with a very dry but very practical episode.

Next time, I promise something a little more opinionated.

[00:14:30] And that’s it for this week’s episode of the Digital Identity Digest. Stay curious, stay engaged, and let’s keep these conversations going.