Answers to Frequently Asked Questions (FAQs) about OpenID Foundation working groups
Preface
This FAQ is intended to help working group members and OpenID members effectively participate in the OpenID working group processes. Please note the OpenID Process and OpenID IPR Policy documents at http://openid.net/intellectual-property/ are authoritative and take precedence over this general guidance.
What are OpenID working groups?
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.
Do I need to be an OpenID Foundation member to participate in OpenID working groups?
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.)
Contributions
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.
Drafts, Implementer’s Drafts, and Final Specifications
OpenID specifications go through three stages as they are developed:
- Drafts: Drafts are working documents that contain contributions from working group members but do not provide intellectual property protections for implementers.
- Implementer’s Drafts: Implementer’s Drafts are working drafts that do provide intellectual property protections for implementers.
- 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.
Implement Early and Often
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.
Implementer’s Drafts are not Final Specifications
As noted above, 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.
Granting Intellectual Property Protections to Implementers
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.
Consensus
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.
Attend Calls and Meetings
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.
Participate on the Mailing List
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.
Use the Issue Tracker
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.
Notification and Review of Drafts
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.
Resolution of Comments
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.
Working Group Last Call
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.
Forming a Working Group
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 openid-specs-council@lists.openid.net.
Ending a Working Group
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.
For More Information
Please feel free to submit questions and comments to director@oidf.org.