An OpenID Foundation working group is focused on a specific problem, technology, or opportunity for which the members will deliver a document or series of documents, after which they may disband or create a revised charter for further work. Each working group has a number of contributors, one or more editors, one or more chairs, and a written charter. The charter defines the scope of work for the working group, as well as its goals and milestones. The working group’s mailing list and meetings should focus on the topics within the charter. OpenID Foundation specifications are created in working groups. The completion of a working group charter and subsequent disbanding of the group are viewed as a sign of success.

You do not need to be a member of the OpenID Foundation to participate in working groups but you must agree to the OpenID Process and IPR Policy by submitting a Contribution Agreement before making contributions. This allows anyone to participate in specification development, while ensuring that the resulting specifications are freely implementable by anyone. (Foundation membership is, of course, encouraged, to support the work of the Foundation.)

Working group members can make contributions in writing online at any time and verbally in working group meetings. It is the working group’s decision how and whether to use all contributions.

1. Drafts: Drafts are working documents that contain contributions from working group members but do not provide intellectual property protections for implementers.
2. Implementer’s Drafts: Implementer’s Drafts are working drafts that do provide intellectual property protections for implementers.
3. Final Specifications: Final Specifications are completed specifications that provide intellectual property protections for implementers and are no longer subject to change. Additionally, there’s an errata process enabling publication of corrections to editorial issues identified in Final Specifications.

Improving specifications based on feedback from the experiences of developers implementing them is a core part of the OpenID specification process. Whether there are multiple independent implementations demonstrating interoperability and meeting the needs of the chartered use cases is an important means for a working group to determine whether a specification is mature or not. Expect changes to be made based on feedback from implementers until a specification is final – some of them breaking changes.

An Implementer’s Draft provides important intellectual property protections for implementers. Expect there to be several Implementer’s Drafts of a specification before it becomes final, often with significant changes made between them. Typically, it’s feedback from implementations of a previous Implementer’s Draft that guide the working group on specific changes needed for the next Implementer’s Draft.

Working groups periodically decide that enough substantive changes have been made to a specification that it’s time to seek intellectual property protections for implementers. At that point, the working group requests that a vote of the OpenID Foundation members be held on granting these protections. A 45-day foundation-wide review precedes this vote for Implementer’s Drafts and a 60-day review period precedes this vote for Final Specifications. Per the process document, a minimum of 20% of the Foundation members are expected to participate in the vote. The foundation-wide vote serves as a check-and-balance, helping ensure that the output of the working group fits well with the rest of the OpenID specifications.

Working group decisions are made by consensus and almost never involve voting. Needing to vote is actually a sign of lack of consensus. This comports with the World Trade Organization (WTO) TBT Treaty for the processes to be followed by international standardization organizations.

The OpenID Process document says this about consensus:

3.3 Consensus. Consensus is a core WG value. To promote consensus, Editors should encourage consideration and resolution of all legitimate comments of Contributors. All Intra-WG decisions will optimally be made by determining consensus, without formal vote. Editor(s) will assess consensus without a formal vote and, when a proposal is pending, may interpret silence of those who have received proper notice (or who are present) as assent. Consensus does not imply unanimity, although there should be substantial support for consensus decisions. For Intra-WG, Core Decisions, consensus should reasonably reflect the opinion of a Supermajority of Contributors to the applicable WG, after reasonable inquiry by the Editors. For Intra-WG, Non-Core Decisions, consensus should reflect the opinion of a majority of Contributors actually expressing an opinion. If a decision cannot be made by consensus, the WG should defer decision until consensus can be reached. If deferral would prejudice a WG’s work, however, the Editor(s) may call a formal vote in accordance with §3.4.

Most OpenID working groups have regularly scheduled working group calls. Members participating in specification development are encouraged to join the calls. It’s often easier to get everyone on the same page by talking with one another rather than by sending e-mails. Active working group members should likewise attend in-person working group meetings whenever feasible.

Important information is exchanged among working group members on the working group mailing list. Written contributions from members are typically sent via the mailing list. Notes from calls and meetings are also sent to the mailing list. Discussions of questions raised by working group members often occur there as well.

Each working group uses an issue tracker to formally track issues with their specifications. This is typically either in Bitbucket or GitHub. Please record issues with specifications in the issue tracker. The tracker contents are typically reviewed on working group calls, with proposed resolutions determined there.

Editors are expected to notify the working group of new drafts via e-mail and to summarize changes made. Working group members are expected to review drafts as they are published and to bring any issues found to the attention of the working group.

The working group is expected to determine resolutions to comments received on specifications and incorporate feedback for which there is working group consensus. When a comment is received via the issue tracker, the proposed resolution will also be recorded in the issue tracker. The issue will be closed once the determined resolution has been applied. Comments received during a foundation-wide IPR vote are often acted upon in the next published version following the vote, although may be acted upon during the review period if their result is strictly editorial.

Before a specification becomes final, the editors notify the working group via e-mail that they should review a draft that is a candidate for Final Specification status. Once it’s determined that there’s working group consensus to promote a draft to final status, the foundation-wide approval vote will be requested.

Working groups are formed by creating a charter describing what the working group will do, having a list of five or more proposers for that work, and then sending the proposed charter to the Specifications Council for review at [email protected].

Working groups can be closed by a decision of the working group or they can be closed by the Specifications Council if they become inactive.

Resources for Working Group Editors and Chairs