Social Web Working Group Charter **CLOSED**

The mission of the Social Web Working Group is to define the techical protocols, vocabularies, and APIs to facilitate access to social functionality as part of the Open Web Platform. These technologies should allow communication between indepedent systems, federation (also called "decentralization") being part of the design.

This Working Group closed on 13 February 2018.

Start date 21 July 2014
End date 13 February 2018
Charter extension The charter extension history is documented in "About this charter"
Confidentiality Proceedings are Public
Co-chairs Tantek Çelik (Mozilla)
Evan Prodromou (E14N)
(previous) Arnaud Le Hors (IBM)
Team Contacts
Amy Guy
Sandro Hawke
(previous) Harry Halpin
Usual Meeting Schedule Teleconferences: Weekly, although the chair may call for topic-specific calls in addition when needed and may change working mode as work progresses.
Face-to-face: Once a year at minimum, three times a year maximum. The Working Group will meet during the W3C's annual Technical Plenary week; other additional F2F meetings may be scheduled as needed.


The Social Web Working Group will create Recommendation Track deliverables that standardize a common JSON-based syntax for social data, a client-side API, and a Web protocol for federating social information such as status updates. This should allow Web application developers to embed and facilitate access to social communication on the Web. The client-side API produced by this Working Group should be capable of being deployed in a mobile environment and based on HTML5 and the Open Web Platform. For definitions of terms such as "social" and "activity", please see the W3C Social XG report A Standards-based, Open and Privacy-aware Social Web.

There are a number of use cases that the work of this Working Group will enable, including but not limited to:


The Working Group, in conjunction with Social Interest Group, will determine the use cases that derive the requirements for the deliverables. Features that are not implemented due to time constraints can be put in a non-normative "roadmap" document for future work. The scope will include:

A transfer syntax for social data such as activities (such as status updates) should include at least the ability to describe the data using URIs in an extensible manner, time-stamping, and should include a serialization compatible with Javascript (JSON) and possibly JSON-LD. Formats based on XML or other data serializations are out-of-scope.

A social API should include the ability to embed third-party information and share social data between web applications. The API should re-use the social data transfer syntax and may allow some interaction with the federation protocol. The API should also be extensible in terms of the items of interest expressible by the data format.

A Web protocol for federating social data should include at least the ability to share status updates using the JSON-based syntax developed by the Working Group. This protocol may allow the capture of new data, the verification of data using techniques such as as digital signatures, and the use of groups with some form of access control or capabilities.

Other components necessary for building federated/decentralized social Web systems are in scope but will not lead to Recommendation-track work without re-chartering, and should be discussed in the Social Interest Group.

Success Criteria

In order to advance to Proposed Recommendation, the specification is expected to have two independent implementations of each feature defined in the specification.


Recommendation-Track Deliverables

The working group will deliver the following to fulfill its goals, subject to discussion in the Working Group:

Each of these technologies should not be tightly-coupled but can allow general purpose use. Each specification must contain a section detailing any known security and privacy implications for implementers, Web authors, and end users. The Social Web WG will actively seek an open security and privacy review for every Recommendation-track deliverable.

Other Deliverables

Other non-normative documents may be delivered as:


The production of the deliverables depends upon the resources available, and will change as new information and implementation experience is reported to the group. The most up-to-date timeline is available from the Social Web WG page.

Note: The group will document significant changes from this initial schedule on the group home page.
Specification FPWD LC CR PR Rec
Social Data Syntax Q3 2014 Q3 2015 Q4 2015 Q2 2016 Q3 2016
Social API Q3 2014 Q3 2015 Q4 2015 Q2 2016 Q3 2016
Federation Protocol Q4 2014 Q4 2015 Q1 2016 Q3 2016 Q4 2016

Dependencies and Liaisons


Social Web Interest Group
To co-ordinate around use-cases, architecture, and vocabularies for social as well as general messaging.
HTML Working Group
To co-ordinate with any features under development or that may need to be added to HTML.
Web Applications Working Group
To co-ordinate with APIs and features of the Social Web with other existing and planned Web application APIs, in particular work with Web Components that may be used by the Social API.
WebAppSec Working Group and Web Security Interest Group
To co-ordinate with any security requirements and specifications arising from the security needs of socially-enabled Web applications. In particular, the Social API may wish to build on top of the WebAppSec Working Group's chartered work around secure cross-domain framing, secure mixed content, and lightweight isolated / safe content.
Linked Data Platform Working Group
The Linked Data Platform Working Group is producing specifications for sharing Linked Data that could be useful to the federation protocol.
Privacy Interest Group
All specifications produced by the Working Group will have a review to help addresses privacy concerns.
Protocols and Formats Working Group
All specifications produced by the Working Group will have a review to help addresses accessibility concerns.
Web and Mobile Interest Group
Having the social web be "mobile first" and so easily usable by mobile is a priority.
Federated Social Web Community Group
This work of this Community Group on the Federated Social Web provides a community-driven implementation experience and use-cases.
Social Business Community Group
This work of this Community Group provides social business experience and use-cases.

Furthermore, the Social Web Working Group expects to follow the following W3C Recommendations, Guidelines and Notes and, if necessary, to liaise with the communities behind the following documents:

External Groups

The following is a tentative list of external bodies the Working Group should coordinate with:

IndieWebCamp Community
The IndieWebCamp grass-roots community has deployed and helped to develop a number of protocols and formats for federated social web related use-cases such as IndieAuth, Webmention, h-entry, h-card, h-cite, as well as design conventions for replies, web actions and other cross-site social user interfaces.
Internet Engineering Task Force
The IETF is responsible for defining robust and secure protocols for Internet functionality. A clear relationship with IETF is vital to ensure the security and success of elements of the Social Web that supervenes upon protocol-level work. Security reviews should involve participants from the IETF Security Area.
ActivityStreams Community
The work of this grass-roots community effort created ActivityStreams, a key part of the open social web. The Working Group will continue to communicate with the community.
Open Mobile Alliance
OMA was formed by mobile operators, device and network suppliers, information technology companies and content and service providers to deliver open specifications for creating interoperable services like social networking on any bearer network.
OpenSocial Foundation
This work of this Foundation will provide input for the API in the form of OpenSocial 2.5. There will also be active liasing with this Foundation over the course of the Working Group, as well as co-ordination over outreach and strategy.


To be successful, the Social Web Working Group is expected to have 10 or more active participants for its duration and to have the participation of industry leaders in fields relevant to the specifications it produces. The Chairs and specification Editors are expected to contribute one to two days per week towards the Working Group. There is no minimum requirement for other Participants.

The Social Web Working Group will also allocate the necessary resources for building test suites for each specification.

Participation by non-Members is governed by the W3C Invited Expert policy. The group encourages questions and comments on its public comment mailing list, as described in Communication. As needed, the group may also call for joint teleconferences and meetings with related organizations and standards bodies.


Most Social Web Working Group Teleconferences will be conducted on an as-needed basis. Normally, at least one teleconference will be held per week.

Most of the technical work of the group will be done through discussions on one of the group's public mailing list and a list for public comments allows posts by anyone:

The group can use a Member-confidential mailing list for administrative purposes and, at the discretion of the Chairs and members of the group, for member-only discussions in special cases when a particular member requests such a discussion.

Information about the group (for example, details about deliverables, issues, actions, status, and participants) will be available from the Social Web Working Group home page.

Decision Policy

As explained in the W3C Process Document (section 3.3), this group will seek to make decisions when there is consensus and with due process. The expectation is that typically, an Editor or other participant makes an initial proposal, which is then refined in discussion with members of the group and other reviewers, and consensus emerges with little formal voting being required. However, if a decision is necessary for timely progress, but consensus is not achieved after careful consideration of the range of views presented, the Chairs should put a question out for voting within the group (allowing for remote asynchronous participation -- using, for example, email and/or web-based survey techniques) and record a decision, along with any objections. The matter should then be considered resolved unless and until new information becomes available.

This charter is written in accordance with Section 3.4, Votes of the W3C Process Document and includes no voting procedures beyond what the Process Document requires.


This Working Group will use the W3C Software and Document license for all its deliverables.

Patent Policy

This Working Group operates under the W3C Patent Policy (5 February 2004 Version). To promote the widest adoption of Web standards, W3C seeks to issue Recommendations that can be implemented, according to this policy, on a Royalty-Free basis.

For more information about disclosure obligations for this group, please see the W3C Patent Policy Implementation.

About this Charter

This charter for the Social Web Working Group has been created according to section 5.2 of the Process Document. In the event of a conflict between this document or the provisions of any charter and the W3C Process, the W3C Process shall take precedence.


Harry Halpin, <hhalpin@w3.org>, Sandro Hawke, Team Contacts
Tantek Çelik (Mozilla), Evan Prodromou (E14N), and Arnaud Le Hors (IBM), Chairs