Legislators and regulators worldwide have expressed concern about the power that some proprietary Internet platforms have over various markets, and are searching for remedies that will counteract perceived abuses of that power.
One often-proposed remedy is the imposition of specific interoperability requirements upon them, thereby promoting competition by removing a "choke point." Such proposals can either authorize a regulator to develop standards or specifications for specific functions, with assistance from a national standards developing organisation, or can establish interoperability requirements in principle and use flexible case-by-case enforcement mechanisms from existing sources of authority to determine the sufficiency of implementation.
In rare cases, existing, widely-recognised and broadly reviewed standards will be suitable without modification. More often, however, that extensions and modifications will need to be made, or whole new protocols and formats created. Even when existing specifications might be suitable for the immediate purposes of regulators, they may not meet modern criteria applied to open Internet and Web standards.
The goal of this group is to ensure that specifications nominated for such legal requirements are aligned with the architectures of the Internet and the Web, reflect the values they embed, and are able to achieve real-world interoperability.
For example, social networks are often the target of potential regulatory interoperability intervention. The group could proactively evaluate regulators' stated requirements and identify existing specifications that might address them (in this case, ones like ActivityStreams), publishing a Report that assesses whether modern requirements for Web standards are met (such as security, privacy, internationalisation and accessibility) and summarising what effects its adoption might have on the relevant markets. It might also suggest further work to be chartered to help close any gaps.
This group will proactively identify likely requirements for interoperability by regulators based upon publicly-available legal documentation (e.g., reports, settlements, cases, and statements from legislators and regulators).
The group will examine those requirements in the context of Internet and Web architecture - in particular, how different solutions might affect not only concentration of power but also user choice, architectural concerns (e.g., privacy, security, internationalisation, accessibility), operability, and simliar concerns.
Where possible, it will map those requirements to the most appropriate existing Web and Internet technology specifications, highlighting any resulting gaps in functionality, implementation availability, real-world interoperability, and specification quality. This includes performing or facilitating horizontal reviews, as well as identifying any potential barriers to user agency and broad deployment.
It will produce reports summarising these findings, potentially including outlines of potential solutions, alternative approaches and their tradeoffs, and overviews of the area in question. When appropriate, it will propose charters for specification work needed.
The group will initially consider requirements in the following areas:
Other focus areas may be added by consensus.
The group can also liaise with regulators, legislators, national standards bodies, and other relevant parties as appropriate. In particular, it can reactively evaluate proposals from those bodies in light of the criteria above.
Discussions in this group are likely to include consideration of relative power in relationships on the Internet, examples of perceived misuse of power, and advocacy for rebalancing these relationships. Participants are asked to exercise discretion when covering these topics, as they can become problematic for other participants who are the focus of legal or regulatory action.
Online advertising markets are explicitly out of scope for discussion in this group, as their complexity and contentiousness deserve dedicated focus elsewhere.
Mobile applications are explicitly out of scope for discussion in this group, as there are already substantial efforts to facilitate these in the W3C.
No Specifications will be produced under the current charter.
The group is expected to produce Community Group Reports within the scope of this Charter.
Additionally, the group may discuss charter proposals for additional groups to address the gaps it identifies.
The group will not produce any test suites or software.
It is expected that the group will liaise with the appropriate communities and standards developing organisations for the specifications it selects as candidates.
Where appropriate, the group will also liaise with regulators, legislators and other relevant parties.
The group operates under the Community and Business Group Process. Terms in this Charter that conflict with those of the Community and Business Group Process are void.
As with other Community Groups, W3C seeks organizational licensing commitments under the W3C Community Contributor License Agreement (CLA). When people request to participate without representing their organization's legal interests, W3C will in general approve those requests for this group with the following understanding: W3C will seek and expect an organizational commitment under the CLA starting with the individual's first request to make a contribution to a group Deliverable. The section on Contribution Mechanics describes how W3C expects to monitor these contribution requests.
The W3C Code of Ethics and Professional Conduct applies to participation in this group.
The group will not publish Specifications on topics other than those listed under Specifications above. See below for how to modify the charter.
Substantive Contributions to Specifications can only be made by Community Group Participants who have agreed to the W3C Community Contributor License Agreement (CLA).
Specifications created in the Community Group must use the W3C Software and Document License. All other documents produced by the group should use that License where possible.
Community Group participants agree to make all contributions in the GitHub repo the group is using for the particular document. This may be in the form of a pull request (preferred), by raising an issue, or by adding a comment to an existing issue.
All Github repositories attached to the Community Group must contain a copy of the CONTRIBUTING and LICENSE files.
The group will conduct all of its technical work in public. All technical work will occur in its GitHub repositories.
Meetings may be restricted to Community Group participants, but a public summary or minutes must be posted to a group GitHub repository.
This group will seek to make decisions where there is consensus. Groups are free to decide how to make decisions (e.g. Participants who have earned Committer status for a history of useful contributions assess consensus, or the Chair assesses consensus, or where consensus isn't clear there is a Call for Consensus [CfC] to allow multi-day online feedback for a proposed course of action). It is expected that participants can earn Committer status through a history of valuable contributions as is common in open source projects. After discussion and due consideration of different opinions, a decision should be publicly recorded (where GitHub is used as the resolution of an Issue).
If substantial disagreement remains (e.g. the group is divided) and the group needs to decide an Issue in order to continue to make progress, the Committers will choose an alternative that had substantial support (with a vote of Committers if necessary). Individuals who disagree with the choice are strongly encouraged to take ownership of their objection by taking ownership of an alternative fork. This is explicitly allowed (and preferred to blocking progress) with a goal of letting implementation experience inform which spec is ultimately chosen by the group to move ahead with.
Any decisions reached at any meeting are tentative and should be recorded in a GitHub Issue for groups that use GitHub and otherwise on the group's public mail list. Any group participant may object to a decision reached at an online or in-person meeting within 7 days of publication of the decision provided that they include clear technical reasons for their objection. The Chairs will facilitate discussion to try to resolve the objection according to the decision process.
It is the Chairs' responsibility to ensure that the decision process is fair, respects the consensus of the CG, and does not unreasonably favour or discriminate against any group participant or their employer.
The Chairs of the Group are:
The Chairs are responsible for the day-to-day running of the group, including:
The Chairs have a number of other powers and responsibilities which are defined throughout this document.
No two Chairs can be from the same organization.
Participants in this group choose their Chair(s) and can replace their Chair(s) at any time using whatever means they prefer. However, if 5 participants, no two from the same organisation, call for an election, the group must use the following process to replace any current Chair(s) with a new Chair, consulting the Community Development Lead on election operations (e.g., voting infrastructure and using RFC 2777).
Participants dissatisfied with the outcome of an election may ask the Community Development Lead to intervene. The Community Development Lead, after evaluating the election, may take any action including no action.
The Chairs are responsible for maintenance of this charter. Amendments are the responsibility of Chairs, based on the consensus of Community Group Participants.
The chairs must notify the group of any material changes to the Charter, per the Community and Business Group Process.