17 |
18 |
19 |
--------------------------------------------------------------------------------
/draft-states.md:
--------------------------------------------------------------------------------
1 | Definitions related to the state of in-progress work adopted in a charter (per [§ 5.2.6 Working Group and Interest Group Charters](https://www.w3.org/Consortium/Process/#WGCharter)):
2 |
3 | Adopted Draft
4 | =================
5 |
6 | *Adopted Draft* is the draft from which the WG will start work. It will usually be the latest document of its shortname in /TR. Once a draft is "Adopted," any changes against it must be resolved through the WG's decision process once the group is chartered.
7 |
8 | Reference Draft
9 | =================
10 |
11 | *Reference Draft* is "the latest Working Draft published within 90 days of the First Public Working Draft or if no Public Working Draft has been published within 90 days of the First Public Working Draft it is that First Public Working Draft." Systeam is developing a tool by which team can identify the Reference Draft for a /TR document.
12 |
13 |
--------------------------------------------------------------------------------
/README.md:
--------------------------------------------------------------------------------
1 | # Draft charters for public review
2 | This repo is a space for draft charters to be developed for W3C Working
3 | Groups or W3C Interest Groups, to be discussed and refined. No charters that
4 | get added to this repo necessarily have any official standing at all—anyone
5 | can create a draft charter here for public discussion. If you’d like to have
6 | push access to add a draft charter to the repo,
7 | [file an issue requesting access](https://github.com/w3c/charter-drafts/issues) or fork this repo to make a pull request.
8 |
9 |
10 | See [the template](https://w3c.github.io/charter-drafts/charter-template.html)
11 |
12 | For W3C Community Groups, please start from the [CG charter template](https://github.com/w3c/cg-charter).
13 |
14 |
15 | # Using the template for a W3C Working Group
16 |
17 | The scope section serves a key function: to guide the WG chairs, participants, and reviewing legal teams on the outer boundaries of their work and patent commitments. To facilitate that review "Scope" should be limited to a clear description of the WG's permitted work areas. Other material (background, explanations, motivations) should go outside the Scope section.
18 |
19 | # Notes for W3C Team
20 |
21 | Before proposing a charter for review to the Advisory Committee, mark the charter "PROPOSED" and copy the PROPOSED charter to w3.org date-space (leaving a pointer to the github repo for continued issue-raising). That way, we can update the draft in response to AC review comments, without changing what's being reviewed.
22 |
23 | You are encouraged to give a pointer in the call for review to previous issue discussion, e.g. the charter-drafts github repo.
24 |
25 | Older drafts may be found in the /archive/ folder.
26 |
--------------------------------------------------------------------------------
/archive/encrypted-media-agreement.html:
--------------------------------------------------------------------------------
1 |
2 |
3 |
4 | Encrypted Media Agreement
5 |
6 |
7 |
8 |
14 |
15 |
16 |
Encrypted Media Agreement
17 |
18 |
19 | The Web has been built through iteration and collaboration, and enjoys strong security because so many people are able to continually test and review its designs and implementations. As the Web gains interfaces to new device capabilities, we rely even more on broad participation, testing, and audit to keep users safe and the web’s security model intact. Therefore, W3C policy should assure that such broad testing and audit continues to be possible, as it is necessary to keep both design and implementation quality high.
20 |
21 |
22 | The following obligations shall apply to all participants in the W3C HTML Media Extension Working Group. These obligations will be referenced from each Working Group charter and Calls for Participation.
23 |
24 |
1. Security Research Requirements for All Working Group Participants
25 |
26 | As a condition of participating in a Working Group, each participant (W3C Members, W3C Team members, invited experts, and members of the public)
27 | shall agree to make available under W3C Encrypted Extensions licensing requirements any implementations related to the work of that particular Working Group. This requirement includes Implementations that the participant owns and any that the participant has the right to license.
28 |
29 |
30 | Only the affirmative act of joining a Working Group, or otherwise agreeing to the licensing terms described here, will obligate a Member to the W3C Encrypted Extensions licensing commitments. Mere Membership in W3C alone, without other factors, does not give rise to the Content Protection licensing obligation under this policy.
31 |
34 | With respect to a Recommendation developed under this policy, a W3C Encrypted Extensions license shall mean a non-assignable, non-sublicensable license that:
35 |
36 |
37 |
38 | exempt computer programs, operating solely for the purpose of good-faith security research related to implementations of the Recommendation. “good-faith security research” means accessing a computer program solely for purposes of good-faith testing, investigation and/or correction of a security flaw or vulnerability, where the information derived from the activity is used primarily to promote the security or safety of the implementation of the Recommendation on which the computer program operates, and is not used or maintained in a manner that facilitates copyright infringement.
39 |
40 |
41 | may not impose any further conditions or restrictions on the circumvention of a technological measure for the sole purpose of identifying and analyzing those elements of the program that are necessary to achieve interoperability of an independently created implementation of the Recommendation, and that have not previously been readily available to the person engaging in the circumvention. The information acquired through the acts may be made available to others if the person provides such information or means solely for the purpose of enabling interoperability of an independently created implementation of the Recommendation.
42 |
43 |
44 |
45 |
46 |
--------------------------------------------------------------------------------
/2017/swwg-disposition.md:
--------------------------------------------------------------------------------
1 | # Disposition of Comments - AC Review of Service Workers WG Charter
2 | ## Summary
3 | * [Proposed charter](https://w3c.github.io/charter-drafts/sw-charter.html)
4 | * [Review form](https://www.w3.org/2002/09/wbs/33280/swwg-2017/results)
5 | * 23 Members supported; 5 members with suggested changes
6 | * 0 Formal Objections
7 |
8 | * Changes since review: as below, we added greater clarity around the testing and implementation success criteria.
9 | * [Link to diff](https://services.w3.org/htmldiff?doc1=https%3A%2F%2Frawgit.com%2Fw3c%2Fcharter-drafts%2F299e9ab77071361f52956e640e82509fe26a0909%2Fsw-charter.html&doc2=https%3A%2F%2Fw3c.github.io%2Fcharter-drafts%2Fsw-charter.html)
10 |
11 | ## Suggested Changes:
12 |
13 | **Mozilla Foundation**: "all normative specification changes are generally expected to have a corresponding change" should end with "corresponding *test* change", I think.
14 |
15 | *Accepted.*
16 |
17 | **Microsoft Corp.**:"Microsoft would like to see the Success Criteria more explicit. First, this group is being proposed in the belief that it will get more participation than was possible when Service Workers was in scope for the Web Platform WG. That rationale should be stated in the charter, perhaps "If a critical mass of key stakeholders and implementers of this technology do not join the group, its charter should be re-examined by the W3C."
18 |
19 | *Added*: "If a critical mass of key stakeholders and implementers of this technology do not join the group, its charter should be re-examined by the W3C."
20 |
21 | **Microsoft Corp.**: Also, we'd prefer that the Success Criteria duplicate much of the language in the Web Platform WG charter that stresses the need for real world implementations, not just proof of concept or prototype implementations. Something like:
22 | "The group will be considered successful if its deliverables are widely used. In particular:
23 |
24 | Production of stable documents addressing the work items listed in the Milestones section.
25 | A test suite for each deliverable with conformance criteria that provides evidence to support the position that there is good (though perhaps not perfect) interoperability.
26 | Availability of authoring tools and validation tools.
27 | User-community and industry adoption of the group deliverables.
28 | Availability of multiple, independent, interoperable implementations of each deliverable in shipping or planned products. ""
29 |
30 | *Added*:
31 | ...and a test suite for each deliverable, sufficiently broad to demonstrate interoperability.
32 |
33 | Each specification should have implementation reports showing adoption, fostering the ready availability of multiple, independent, interoperable implementations, including in browsers, authoring, and validation tools, and usage on the Web.
34 |
35 | **JS Foundation**: We echo the comments made by Microsoft around defining more explicit success criteria
36 |
37 | *Addressed above*
38 |
39 | **Apple, Inc.**:
40 | "This specification defines an API" needs to go and say "that enables the teleportation of small mammals" or something that scopes it a little more.
41 |
42 | *Added*: "that enables applications to take advantage of persistent background processing, including hooks to enable bootstrapping of web applications while offline." (No small mammals were harmed in the crafting of this comment.)
43 |
44 | **Apple, Inc.**:
45 | Really no Coordination with Ecma/JS needed?
46 |
47 | *Added*: [ECMA TC 39](http://www.ecma-international.org/memento/TC39.htm)
48 |
49 | **Apple, Inc.**:
50 | "The charter says that specs 'should' have a privacy and security considerations section. I think that is or is close to a general 'must' at the W3C level so either should be deleted to go with the general policy, or made 'must'.
51 |
52 | The charter says that consensus on a call or meeting is provisional until confirmed online after publication in meeting minutes. I don't think it's acceptable to have controversial questions published in minutes, which are easily missed. I think a clear separate message 'Call for consensus: do X' is required. I commented this way on a related charter before, and almost made this a FO then.
53 |
54 | Communication: Is it clear *how* (e.g. an online form) an external IPR commitment is acquired? Could we link to the form or whatever tool is used? Ideally this is a separate section, as it's not exactly 'communication' that it is about."
55 |
56 | *No change*: We are taking these suggestions into a broader review of Chartering process and Working Group modes of practice. As regards the privacy and security considerations, such a section (and its adequacy) is effectively a must at this point.
57 |
58 |
59 |
60 | **Digital Bazaar**: The creation of a test suite should be mandatory for exiting CR.
61 |
62 | *Addressed above with clarifications to success criteria.*
63 |
64 |
--------------------------------------------------------------------------------
/games-cg-2020.html:
--------------------------------------------------------------------------------
1 |
2 |
3 |
4 |
5 | Games Community Group Charter
6 |
7 |
8 |
9 |
10 |
29 |
30 |
31 |
32 | [PROPOSED] Games Community Group Charter
33 |
34 |
35 | This Charter is work in progress. To submit feedback, please use
36 | GitHub Issues where this
37 | Charter is being developed.
38 |
39 |
40 |
This Charter: {TBD: URI}
41 |
42 |
Start Date: {TBD: date the charter takes effect}
43 |
44 |
45 |
46 | Goals
47 |
48 |
49 | The goal of the Games Community Group is to improve the quality of open
50 | web standards that games developers rely on to create games.
51 |
52 |
53 | Scope of Work
54 |
55 |
56 | To achieve its goal, the Games community group will:
57 |
58 |
59 |
Track specifications and vendor implementations related to open web
60 | games.
61 |
Recommend new specifications to be produced and find group homes
62 | for them.
63 |
Refine use cases to communicate specific needs of games.
64 |
Suggest refinements or fixes to existing specifications to better meet
65 | the needs of the game development community.
66 |
Explore capabilities —APIs, semantics, techniques for rendering, processing, personalization, customization, interoperability, etc.— that developers can leverage to localize games and guarantee that they are accessible.
67 |
Evangelize specifications to browser vendors.
68 |
Document how to best use open web standards for games.
69 |
Evangelize open web standards to game developers and game development
70 | best practices to web developers.
71 |
72 |
73 |
The Games community group will not develop any normative specification.
74 | As such, there will not be any Essential Claims under the W3C Contributor
75 | License Agreement or Final Specification Agreement.
76 |
77 |
78 | Deliverables
79 |
80 |
81 | Specifications
82 |
83 |
84 | No Specifications will be produced under the current charter.
85 |
86 |
87 |
88 | Non-Normative Reports
89 |
90 |
91 | The group may produce other Community Group Reports within the scope of
92 | this charter but that are not Specifications, for instance use cases,
93 | requirements, or white papers.
94 |
95 |
96 | Test Suites and Other Software
97 |
98 |
99 | The group may develop open source software as needed to demonstrate
100 | scenarios of interest, guidelines, and highlight possible gaps in web
101 | technologies. Please see the GiHub LICENSE file for software contribution
102 | licensing information.
103 |
104 |
105 | The group will not develop Test Suites.
106 |
107 |
108 |
109 | Dependencies or Liaisons
110 |
111 |
112 | By definition, this group will closely monitor ongoing standardisation
113 | activities that are deemed useful in game scenarios. This includes those
114 | identified during the
115 | W3C
116 | Workshop on Web games (list is non-exhaustive):
117 |
138 | The group operates under the Community and Business
140 | Group Process. Terms in this Charter that conflict with those of the
141 | Community and Business Group Process are void.
142 |
143 |
144 | As with other Community Groups, W3C seeks organizational licensing
145 | commitments under the W3C Community
147 | Contributor License Agreement (CLA). When people request to
148 | participate without representing their organization's legal interests,
149 | W3C will in general approve those requests for this group with the
150 | following understanding: W3C will seek and expect an organizational
151 | commitment under the CLA starting with the individual's first request to
152 | make a contribution to a group Deliverable.
153 | The section on Contribution Mechanics describes
154 | how W3C expects to monitor these contribution requests.
155 |
167 | The group will not publish Specifications on topics other than those
168 | listed under Specifications above. See
169 | below for how to modify the charter.
170 |
181 | Specifications created in the Community Group must use the
183 | W3C Software and Document License. All other documents produced by
184 | the group should use that License where possible.
185 |
186 |
187 | Community Group participants agree to make all contributions on
188 | public-facing tools chosen by the group (public mail list, GitHub
189 | repositories, public discussion forum). For GitHub, this may be
190 | in the form of a pull request (preferred), by raising an issue, or by
191 | adding a comment to an existing issue.
192 |
193 |
194 | All Github repositories attached to the Community Group must contain a
195 | copy of the CONTRIBUTING
197 | and LICENSE
199 | files.
200 |
201 |
202 | Transparency
203 |
204 |
205 | The group will conduct all of its technical work in public. If the group
206 | uses GitHub, all technical work will occur in its GitHub repositories
207 | (and not in mailing list discussions). This is to ensure contributions
208 | can be tracked through a software tool.
209 |
210 |
211 | Meetings may be restricted to Community Group participants, but a public
212 | summary or minutes must be posted to the group's public mailing list, or
213 | to a GitHub issue if the group uses GitHub.
214 |
215 |
216 | Decision Process
217 |
218 |
219 | This group will seek to make decisions where there is consensus. Groups
220 | are free to decide how to make decisions (e.g. Participants who have
221 | earned Committer status for a history of useful contributions assess
222 | consensus, or the Chair assesses consensus, or where consensus isn't
223 | clear there is a Call for Consensus [CfC] to allow multi-day online
224 | feedback for a proposed course of action). It is expected that
225 | participants can earn Committer status through a history of valuable
226 | contributions as is common in open source projects. After discussion and
227 | due consideration of different opinions, a decision should be publicly
228 | recorded (where GitHub is used as the resolution of an Issue).
229 |
230 |
231 | If substantial disagreement remains (e.g. the group is divided) and the
232 | group needs to decide an Issue in order to continue to make progress, the
233 | Committers will choose an alternative that had substantial support (with
234 | a vote of Committers if necessary). Individuals who disagree with the
235 | choice are strongly encouraged to take ownership of their objection by
236 | taking ownership of an alternative fork. This is explicitly allowed (and
237 | preferred to blocking progress) with a goal of letting implementation
238 | experience inform which spec is ultimately chosen by the group to move
239 | ahead with.
240 |
241 |
242 | Any decisions reached at any meeting are tentative and should be recorded
243 | in a GitHub Issue for groups that use GitHub and otherwise on the group's
244 | public mail list. Any group participant may object to a decision reached
245 | at an online or in-person meeting within 7 days of publication of the
246 | decision provided that they include clear technical reasons for their
247 | objection. The Chairs will facilitate discussion to try to resolve the
248 | objection according to the decision process.
249 |
250 |
251 | It is the Chairs' responsibility to ensure that the decision process is
252 | fair, respects the consensus of the CG, and does not unreasonably favour
253 | or discriminate against any group participant or their employer.
254 |
255 |
256 | Chair Selection
257 |
258 |
259 | Participants in this group choose their Chair(s) and can replace their
260 | Chair(s) at any time using whatever means they prefer. However, if 5
261 | participants, no two from the same organisation, call for an election,
262 | the group must use the following process to replace any current Chair(s)
263 | with a new Chair, consulting the Community Development Lead on election
264 | operations (e.g., voting infrastructure and using RFC 2777).
266 |
267 |
268 |
Participants announce their candidacies. Participants have 14 days to
269 | announce their candidacies, but this period ends as soon as all
270 | participants have announced their intentions. If there is only one
271 | candidate, that person becomes the Chair. If there are two or more
272 | candidates, there is a vote. Otherwise, nothing changes.
273 |
274 |
Participants vote. Participants have 21 days to vote for a single
275 | candidate, but this period ends as soon as all participants have voted.
276 | The individual who receives the most votes, no two from the same
277 | organisation, is elected chair. In case of a tie, RFC2777 is used to
278 | break the tie. An elected Chair may appoint co-Chairs.
279 |
280 |
281 |
282 | Participants dissatisfied with the outcome of an election may ask the
283 | Community Development Lead to intervene. The Community Development Lead,
284 | after evaluating the election, may take any action including no action.
285 |
286 |
287 | Amendments to this Charter
288 |
289 |
290 | The group can decide to work on a proposed amended charter, editing the
291 | text using the Decision Process described above.
292 | The decision on whether to adopt the amended charter is made by
293 | conducting a 30-day vote on the proposed new charter. The new charter, if
294 | approved, takes effect on either the proposed date in the charter itself,
295 | or 7 days after the result of the election is announced, whichever is
296 | later. A new charter must receive 2/3 of the votes cast in the approval
297 | vote to pass. The group may make simple corrections to the charter such
298 | as deliverable dates by the simpler group decision process rather than
299 | this charter amendment process. The group will use the amendment process
300 | for any substantive changes to the goals, scope, deliverables, decision
301 | process or rules for amending the charter.
302 |
32 | [DRAFT] Security Web Application Guidelines (SWAG) Community Group Charter
33 |
34 |
35 | {TBD: remove next sentence before submitting for
36 | approval} This Charter is work in progress. To submit feedback,
37 | please use
38 | GitHub Repository Issue where Charter is being developed.
39 |
Start Date: {TBD: date the charter takes effect,
46 | estimate if not known. Update this if the charter is revised and include
47 | a link to the previous version of the charter.}
48 |
49 |
Last Modifed: {TBD: If the system does not
50 | automatically provide information about the date of the last
51 | modification, it can be useful to include that in the charter.}
52 |
53 |
54 |
55 | Goals
56 |
57 |
58 | The mission of this Community Group is to increase the overall security
59 | of web application development, thereby making the
60 | web a more
61 | secure platform for web users.
62 | It will accomplish this by writing web developers security best practices
63 | and providing a platform for stakeholder collaboration.
64 |
65 |
66 | Scope of Work
67 |
68 |
This Community will:
69 |
70 |
Clarify documentation needs to inform security documentation writers, which will include:
71 |
72 |
Web Application Security Developer's Principles.
73 |
Threat Models.
74 |
Theory, Attacks, Practices and Tools.
75 |
76 |
77 |
Develop a set of security best practices for web developers and product owners. This includes:
78 |
79 |
Framework/Library secure development best practices.
80 |
WebAssembly secure development best practices.
81 |
Integrating software supply chain approaches to ease security assessments.
82 |
Formulating end-user stories related to security to inform groups developing technical APIs and policymakers developing regulations.
83 |
84 |
85 |
Coordinate actions with external organizations:
86 |
87 |
It could include one or more joint deliverables.
88 |
It could include joint communication.
89 |
Integrating software supply chain approaches to ease security assessments.
90 |
Formulating end-user stories related to security to inform groups developing technical APIs and policymakers developing regulations.
91 |
92 |
93 |
Review possible directions to sanitize web APIs in isolated contexts (compartments).
94 |
Track specifications and vendor implementations related to security.
95 |
...What should build tools do to assure that nobody is hijacking the process?
96 |
...helping to bring security best practices into the default developer lifecycle for web developers
97 |
...helping package managers become more responsible about their dependency checking
98 |
...work with Security IG to help develop security principles that can be used in wide reviews
99 |
100 |
101 | Out of Scope
102 |
103 |
104 | The development of normative standards and technical specifications is not in the scope of the Community Group.
105 |
106 |
107 | This group does not perform horizontal reviews for security at W3C; that is the responsibility of the Security Interest Group (SING).
108 |
109 |
110 |
111 | Deliverables
112 |
113 |
114 | Non-Normative Reports
115 |
116 |
117 |
Application Developer’s security best practices, by the end of 2025.
118 |
119 |
120 | The group may produce other Community Group Reports within the scope of
121 | this charter but that are not Specifications, for instance use cases,
122 | requirements, or white papers.
123 |
124 |
125 | Test Suites and Other Software
126 |
127 |
128 | The group MAY produce test suites to support the Specifications. Please
129 | see the GitHub LICENSE file for test suite contribution licensing
130 | information.
131 |
132 |
133 | Dependencies or Liaisons
134 |
135 |
136 |
OpenSSF
137 |
OWASP
138 |
OpenJS Foundation
139 |
ISECOM
140 |
...
141 |
142 |
143 | Community and Business Group Process
144 |
145 |
146 | The group operates under the Community and Business
148 | Group Process. Terms in this Charter that conflict with those of the
149 | Community and Business Group Process are void.
150 |
151 |
152 | As with other Community Groups, W3C seeks organizational licensing
153 | commitments under the W3C Community
155 | Contributor License Agreement (CLA). When people request to
156 | participate without representing their organization's legal interests,
157 | W3C will in general approve those requests for this group with the
158 | following understanding: W3C will seek and expect an organizational
159 | commitment under the CLA starting with the individual's first request to
160 | make a contribution to a group Deliverable.
161 | The section on Contribution Mechanics describes
162 | how W3C expects to monitor these contribution requests.
163 |
175 | The group will not publish Specifications on topics other than those
176 | listed under Specifications above. See
177 | below for how to modify the charter.
178 |
189 | Specifications created in the Community Group must use the
191 | W3C Software and Document License. All other documents produced by
192 | the group should use that License where possible.
193 |
194 |
195 | {TBD: if CG doesn't use GitHub replace the remaining paragraphs in this
196 | section with: "All Contributions are made on the groups public mail list
197 | or public contrib list"}
198 |
199 |
200 | Community Group participants agree to make all contributions in the
201 | GitHub repo the group is using for the particular document. This may be
202 | in the form of a pull request (preferred), by raising an issue, or by
203 | adding a comment to an existing issue.
204 |
205 |
206 | All Github repositories attached to the Community Group must contain a
207 | copy of the CONTRIBUTING
209 | and LICENSE
211 | files.
212 |
213 |
214 | Transparency
215 |
216 |
217 | The group will conduct all of its technical work in public. If the group
218 | uses GitHub, all technical work will occur in its GitHub repositories
219 | (and not in mailing list discussions). This is to ensure contributions
220 | can be tracked through a software tool.
221 |
222 |
223 | Meetings may be restricted to Community Group participants, but a public
224 | summary or minutes must be posted to the group's public mailing list, or
225 | to a GitHub issue if the group uses GitHub.
226 |
227 |
228 | Decision Process
229 |
230 |
231 | If the decision policy is documented somewhere, update this section accordingly to link to it.
232 |
233 |
234 | This group will seek to make decisions where there is consensus. Groups
235 | are free to decide how to make decisions (e.g. Participants who have
236 | earned Committer status for a history of useful contributions assess
237 | consensus, or the Chair assesses consensus, or where consensus isn't
238 | clear there is a Call for Consensus [CfC] to allow multi-day online
239 | feedback for a proposed course of action). It is expected that
240 | participants can earn Committer status through a history of valuable
241 | contributions as is common in open source projects. After discussion and
242 | due consideration of different opinions, a decision should be publicly
243 | recorded (where GitHub is used as the resolution of an Issue).
244 |
245 |
246 | If substantial disagreement remains (e.g. the group is divided) and the
247 | group needs to decide an Issue in order to continue to make progress, the
248 | Committers will choose an alternative that had substantial support (with
249 | a vote of Committers if necessary). Individuals who disagree with the
250 | choice are strongly encouraged to take ownership of their objection by
251 | taking ownership of an alternative fork. This is explicitly allowed (and
252 | preferred to blocking progress) with a goal of letting implementation
253 | experience inform which spec is ultimately chosen by the group to move
254 | ahead with.
255 |
256 |
257 | Any decisions reached at any meeting are tentative and should be recorded
258 | in a GitHub Issue for groups that use GitHub and otherwise on the group's
259 | public mail list. Any group participant may object to a decision reached
260 | at an online or in-person meeting within 7 days of publication of the
261 | decision provided that they include clear technical reasons for their
262 | objection. The Chairs will facilitate discussion to try to resolve the
263 | objection according to this decision process.
264 |
265 |
266 | It is the Chairs' responsibility to ensure that the decision process is
267 | fair, respects the consensus of the CG, and does not unreasonably favour
268 | or discriminate against any group participant or their employer.
269 |
270 |
271 | Chair Selection
272 |
273 |
274 | Participants in this group choose their Chair(s) and can replace their
275 | Chair(s) at any time using whatever means they prefer. However, if 5
276 | participants, no two from the same organisation, call for an election,
277 | the group must use the following process to replace any current Chair(s)
278 | with a new Chair, consulting the Community Development Lead on election
279 | operations (e.g., voting infrastructure and using RFC 2777).
281 |
282 |
283 |
Participants announce their candidacies. Participants have 14 days to
284 | announce their candidacies, but this period ends as soon as all
285 | participants have announced their intentions. If there is only one
286 | candidate, that person becomes the Chair. If there are two or more
287 | candidates, there is a vote. Otherwise, nothing changes.
288 |
289 |
Participants vote. Participants have 21 days to vote for a single
290 | candidate, but this period ends as soon as all participants have voted.
291 | The individual who receives the most votes, no two from the same
292 | organisation, is elected chair. In case of a tie, RFC2777 is used to
293 | break the tie. An elected Chair may appoint co-Chairs.
294 |
295 |
296 |
297 | Participants dissatisfied with the outcome of an election may ask the
298 | Community Development Lead to intervene. The Community Development Lead,
299 | after evaluating the election, may take any action including no action.
300 |
301 |
302 | Amendments to this Charter
303 |
304 |
305 | The group can decide to work on a proposed amended charter, editing the
306 | text using the Decision Process described above.
307 | The decision on whether to adopt the amended charter is made by
308 | conducting a 30-day vote on the proposed new charter. The new charter, if
309 | approved, takes effect on either the proposed date in the charter itself,
310 | or 7 days after the result of the election is announced, whichever is
311 | later. A new charter must receive 2/3 of the votes cast in the approval
312 | vote to pass. The group may make simple corrections to the charter such
313 | as deliverable dates by the simpler group decision process rather than
314 | this charter amendment process. The group will use the amendment process
315 | for any substantive changes to the goals, scope, deliverables, decision
316 | process or rules for amending the charter.
317 |
318 |
319 |
320 |
--------------------------------------------------------------------------------
/2022/wot-cg-2022.html:
--------------------------------------------------------------------------------
1 |
2 |
3 |
4 |
5 | Web of Things Community Group Charter
6 |
7 |
8 |
9 |
10 |
29 |
30 |
31 |
32 | [DRAFT] Web of Things Community Group Charter
33 |
34 |
35 | {TBD: remove next sentence before submitting for
36 | approval} This Charter is work in progress. To submit feedback,
37 | please use Issues or
38 | the Pull Requst 392
39 | where Charter is being developed.
40 |
41 |
42 |
This Charter: https://github.com/w3c/charter-drafts/blob/gh-pages/2022/wot-cg-2022.html
43 |
55 | The goal of WoT Community Group is to accelerate the community activities around the recommendations and notes published by the WoT WG and IG. More concretely, the group aims to:
56 |
57 |
Increase awareness of the WoT specifications
58 |
Collect use cases from the wider community
59 |
Collect implementation experience and references to technologies from the wider community
60 |
Facilitate the implementation of the specifications by providing guidelines and tutorials
61 |
62 |
63 |
64 | Scope of Work
65 |
66 |
67 | In order to achieve the above goals, the scope of the Web of Things Community Group includes the following activities:
68 |
69 |
70 |
Organizing events such as hackathons, plugfests, ideathons, etc.
71 |
Supporting other communities to host W3C WoT related events, i.e. satellite events
72 |
Supporting communication between WoT-related developers through platforms such as Gitter, Matrix, StackOverflow, etc.
73 |
Increasing the social media presence of the W3C WoT
74 |
Handling questions and discussions on the standards of the Web of Things Working and Interest Groups
75 |
Coordinate activities with the Web of Things Working and Interest Groups
76 |
77 |
78 | In addition,
79 | the WoT CG will report the results of its activities back to the Web of Things Working and Interest Groups,
80 | the W3C membership, and the Web community.
81 |
82 |
83 | The Web of Things Community Group, together with the Web of Things Interest Group will decide in the future how to manage the
84 | Web of Things Website together.
85 | How this collaboration will work is defined in a separate document.
86 |
87 |
88 | Out of Scope
89 |
90 |
91 | Publishing recommendations (standards specifications) is out of the scope of this community group (thus the CLA patent policy does not apply)
92 |
93 |
94 | Deliverables
95 |
96 |
97 | Specifications
98 |
99 |
100 | No specifications will be produced under the current charter.
101 |
102 |
103 | Non-Normative Reports
104 |
105 |
106 | The group may produce other Community Group Reports within the scope of this charter
107 | that are not specifications, for instance use cases, requirements, implementation experience reports, or white papers.
108 |
109 |
110 | Test Suites and Other Software
111 |
112 |
113 | There are no plans to create a test suite.
114 |
115 |
116 | Other Deliverables
117 |
118 |
119 | The group may produce deliverables to promote or explain the W3C Web of Things standard. For example (but not limited
120 | to):
121 |
122 |
Multimedia content: Videos, Podcasts, Slides, etc.
123 |
Code snippets and examples
124 |
Thing descriptions or Thing Models
125 |
Tutorials (written or in other forms)
126 |
127 |
128 | Dependencies or Liaisons
129 |
130 |
131 | The Web of Things Community Group will manage dependencies and liaisons separately in the documents listed below:
132 |
138 | Any changes to these documents need to be either a Pull Request reviewed by the chairs or agreed upon in a public meeting.
139 |
140 |
141 | Community and Business Group Process
142 |
143 |
144 | The group operates under the Community and Business
146 | Group Process. Terms in this Charter that conflict with those of the
147 | Community and Business Group Process are void.
148 |
149 |
150 | As with other Community Groups, W3C seeks organizational licensing
151 | commitments under the W3C Community
153 | Contributor License Agreement (CLA). When people request to
154 | participate without representing their organization's legal interests,
155 | W3C will in general approve those requests for this group with the
156 | following understanding: W3C will seek and expect an organizational
157 | commitment under the CLA starting with the individual's first request to
158 | make a contribution to a group Deliverable.
159 | The section on Contribution Mechanics describes
160 | how W3C expects to monitor these contribution requests.
161 |
173 | The group will not publish on topics other than those
174 | listed under Deliverables above. See
175 | below for how to modify the charter.
176 |
192 | Community Group participants agree to make all contributions in the
193 | GitHub repo the group is using for each particular deliverable. This may be
194 | in the form of a pull request (preferred), by raising an issue, or by
195 | adding a comment to an existing issue.
196 |
197 |
198 | Only commits against this repository's deliverables are considered contributions.
199 | Discussions that take place in chat platforms, social media or similar are not contributions and
200 | are exempt from the rules that apply to the deliverables.
201 | However, Code of Ethics and Professional Conduct still applies.
202 |
203 |
204 | All GitHub repositories attached to the Community Group must contain a
205 | copy of the CONTRIBUTING
207 | and LICENSE
209 | files.
210 |
211 |
212 | Transparency
213 |
214 |
215 | The group will conduct all of its technical work, including organizational matters, in public.
216 | All technical work will occur in its GitHub repositories (and not in mailing list discussions or in chat platforms)
217 | and any work or discussion that happens elsewhere is not considered official.
218 | This is to ensure contributions can be tracked through a software tool.
219 | Announcements should be made via public emails and messages in chosen chat platform.
220 |
221 |
222 | Meetings may be restricted to Community Group participants, but a public
223 | summary or minutes must be posted to the group's public mailing list, or
224 | to a GitHub issue if the group uses GitHub.
225 |
226 |
227 | Decision Process
228 |
229 |
230 | This group will seek to make decisions where there is consensus. Groups
231 | are free to decide how to make decisions (e.g. Participants who have
232 | earned Committer status for a history of useful contributions assess
233 | consensus, or the Chair assesses consensus, or where consensus isn't
234 | clear there is a Call for Consensus [CfC] to allow multi-day online
235 | feedback for a proposed course of action). It is expected that
236 | participants can earn Committer status through a history of valuable
237 | contributions as is common in open source projects. After discussion and
238 | due consideration of different opinions, a decision should be publicly
239 | recorded (where GitHub is used as the resolution of an Issue).
240 |
241 |
242 | If substantial disagreement remains (e.g. the group is divided) and the
243 | group needs to decide an Issue in order to continue to make progress, the
244 | Committers will choose an alternative that had substantial support (with
245 | a vote of Committers if necessary). Individuals who disagree with the
246 | choice are strongly encouraged to take ownership of their objection by
247 | taking ownership of an alternative fork. This is explicitly allowed (and
248 | preferred to blocking progress) with a goal of letting implementation
249 | experience inform which spec is ultimately chosen by the group to move
250 | ahead with.
251 |
252 |
253 | Any decisions reached at any meeting are tentative and should be recorded
254 | in a GitHub Issue for groups that use GitHub and otherwise on the group's
255 | public mail list. Any group participant may object to a decision reached
256 | at an online or in-person meeting within 7 days of publication of the
257 | decision provided that they include clear technical reasons for their
258 | objection. The Chairs will facilitate discussion to try to resolve the
259 | objection according to the decision process.
260 |
261 |
262 | It is the Chairs' responsibility to ensure that the decision process is
263 | fair, respects the consensus of the CG, and does not unreasonably favour
264 | or discriminate against any group participant or their employer.
265 |
266 |
267 | Chair Selection
268 |
269 |
270 | Participants in this group choose their Chair(s) and can replace their
271 | Chair(s) if 5 participants, no two from the same organisation, call for an election.
272 | To do so, the group must use the following process to replace any current Chair(s)
273 | with a new Chair, consulting the Community Development Lead on election
274 | operations (e.g., voting infrastructure and using RFC 2777). If there are not enough participants
276 | or the participants are from the same organisation, thus not meeting the above-mentioned
277 | criteria, participants should ask the Community Development Lead to intervene.
278 |
279 |
280 |
Participants announce their candidacies. Participants have 14 days to
281 | announce their candidacies via email, but this period ends as soon as all
282 | participants have announced their intentions. If there is only one
283 | candidate, that person becomes the Chair. If there are two or more
284 | candidates, there is a vote. Otherwise, nothing changes.
285 |
286 |
Participants vote. Participants have 21 days to vote for a single
287 | candidate, but this period ends as soon as all participants have voted.
288 | The individual who receives the most votes, no two from the same
289 | organisation, is elected chair. In case of a tie, RFC2777 is used to
290 | break the tie. An elected Chair may appoint co-Chairs.
291 |
292 |
293 |
294 | Participants dissatisfied with the outcome of an election may ask the
295 | Community Development Lead to intervene. The Community Development Lead,
296 | after evaluating the election, may take any action including no action.
297 |
298 |
299 | Amendments to this Charter
300 |
301 |
302 | The group can decide to work on a proposed amended charter, editing the
303 | text using the Decision Process described above.
304 | The decision on whether to adopt the amended charter is made by
305 | conducting a 30-day vote on the proposed new charter. The new charter, if
306 | approved, takes effect on either the proposed date in the charter itself,
307 | or 7 days after the result of the election is announced, whichever is
308 | later. A new charter must receive 2/3 of the votes cast in the approval
309 | vote to pass. The group may make simple corrections to the charter such
310 | as deliverable dates by the simpler group decision process rather than
311 | this charter amendment process. The group will use the amendment process
312 | for any substantive changes to the goals, scope, deliverables, decision
313 | process or rules for amending the charter.
314 |
2019 DRAFT Patents and Standards Interest Group Charter
41 |
42 |
The Patent and Standards Interest
43 | Group (PSIG) is designed as a forum for W3C Members to discuss matters
44 | regarding the W3C Patent Policy as well as W3C copyright in particular and
45 | larger issues regarding patents, licenses and Web standards. The PSIG is an
46 | Interest Group that gives feedback to the W3C Team, the Advisory Board and the
47 | Advisory Committee; PSIG does not make final policy decisions on behalf of W3C.
48 |
Teleconferences: The Interest Group may also
80 | conduct virtual meetings using email, IRC, wiki and teleconference
81 | facilities
82 | Face-to-face: The Patent and Standards Interest Group may meet
83 | face-to-face on the order of once or twice each year. It may also
84 | sponsor "Birds-Of-a-Feather" sessions at conferences, W3C Advisory
85 | Committee Meetings or Technical Plenaries or alongside other W3C
86 | meetings, at the discretion of the Chair(s).
87 |
88 |
89 |
90 |
91 |
92 |
Overview and Background
93 |
94 |
In May 2003, the W3C Director, on the advice of the W3C Membership, approved
95 | the W3C Patent Policy as the governing document for patent matters in W3C
96 | Recommendations. The Patent Policy Working Group (PPWG), which developed that
97 | policy over a more than three year period, assisted the Team with the
98 | implementation of the policy, and the PPWG then closed.
99 |
100 |
The W3C Patent Policy affirms and strengthens the basic patent licensing
101 | model that has driven innovation on the Web from its inception. The
102 | availability of an interoperable, unencumbered (i.e. royalty-free) Web
103 | infrastructure provides an expanding foundation for innovative applications,
104 | profitable commerce, and the free flow of information and ideas. The W3C Patent
105 | Policy encourages both commercial and non-commercial implementations of W3C
106 | Recommendations. Beyond establishing a commitment to royalty-free standards,
107 | the Patent Policy provides W3C with:
108 |
109 |
a stable, practical, written policy for all W3C Recommendations
110 |
a clear licensing framework for all W3C Recommendations
111 |
consistent patent disclosure obligations, and
112 |
an exception-handling process when problems arise.
113 |
114 |
115 |
The Patents and Standards Interest Group (PSIG) was formed in December 2004
116 | to provide an ongoing forum for discussion of general issues regarding
117 | implementation of the Patent Policy and to exchange views on Intellectual
118 | Property Rights (IPR). Upon request, PSIG continues to provide feedback on
119 | whether changes to the Patent Policy are desirable and how those changes might
120 | look.
121 |
122 |
Over time, PSIG has been asked for feedback on a variety of non-patent
123 | questions. For example, PSIG opinions helped the W3C Team define the Community
124 | Group Licensing Agreement. In the discussion around HTML5 licensing, PSIG
125 | helped the Advisory Board evaluate licensing alternatives.
126 |
127 |
This PSIG Charter continues the established practice for PSIG to
128 | discuss and provide feedback on IPR matters. This Charter also permits the PSIG
129 | to draft or suggest amended or additional patent policy documents.
130 |
131 |
132 |
133 |
Mission Statement
134 |
135 |
PSIG is a forum for W3C Members and Invited Experts to discuss and provide
136 | feedback to the W3C Team, the Advisory Board and the Advisory Committee on IPR
137 | questions.
138 |
139 |
PSIG may suggest further policy development and draft documents for
140 | such additional policies. Any policy development would be subject to
141 | Advisory Committee and Director review.
142 |
143 |
144 |
145 |
Scope
146 |
147 |
The W3C Team, Advisory Board and Advisory Committee may request
148 | that the PSIG provide feedback regarding the W3C Patent Policy, issues related to patent commitments for participants in current and proposed W3C activities (for example, Evergreen Standards[1]), and other IPR issues.
149 | The PSIG may
150 | also exchange views and flag issues regarding the W3C Patent Policy.
151 | It may produce non-binding Interest Group Notes on those specific
152 | issues.
153 |
154 |
The PSIG will review, but is not responsible for formally documenting or
155 | implementing, W3C IPR policies.
156 |
157 |
158 |
159 |
Deliverables
160 |
161 |
As an Interest Group, the PSIG issues neither Recommendations nor other
162 | binding policy documents. It may draft policy documents or amendments to existing policy documents for Advisory Comittee review.
163 |
164 |
The PSIG is responsible for recommending wording for the Patent Policy FAQ. The PSIG reviews
166 | proposed entries to it as follows: The initiative to add a FAQ entry may start
167 | with either the Team or the PSIG. If it starts with the Team, the Team proposes
168 | the FAQ entry to the PSIG. One PSIG Chair must reply within 7
169 | days with one of these two dispositions:
170 |
171 |
PSIG heads-up. If the entry is likely uncontroversial, the PSIG Chair(s)
172 | forwards the proposal to the PSIG list with a comment deadline of
173 | 14 days. Unless someone on the PSIG objects within 14
174 | days, then the proposal may be added to the FAQ by the Team on the 15th
175 | day. If there is an objection from the PSIG, then it will be added to the
176 | PSIG agenda for discussion.
177 |
PSIG Agenda. If the proposal raises some substantial issue in the
178 | judgment of the PSIG Chair(s), then it will be sent to the PSIG list for
179 | comment and discussion will be scheduled for the next PSIG teleconference.
180 | After that, the PSIG will report back on the results.
181 |
182 |
183 |
The PSIG shall report at least annually to the Advisory Committee on its
184 | activities identifying issues resolved or unresolved.
185 |
186 |
187 |
188 |
Dependencies
189 |
190 |
The PSIG will coordinate with the W3C Advisory Board, the Advisory Committee
191 | and the W3C Team on IPR matters raised. During considerations and as needed,
192 | PSIG can informally liaise with the relevant institutions in the standards and
193 | public policy communities around the world. Informal coordination is done via
194 | the Interest Group's mailing lists.
195 |
196 |
197 |
198 |
Participation
199 |
200 |
Any W3C Member may nominate up to 3 participants to the PSIG. The Chair(s)
201 | may invite qualified Invited Experts to participate in the PSIG in accordance
202 | with the Invited Expert provisions in the Process Document.
203 |
204 |
To the extent that PSIG participants are attorneys, they shall not be deemed
205 | to provide legal advice to W3C. Discussions, even about legal topics and while
206 | focused on a use case, are mere discussions and do not represent a legal
207 | opinion, express or implied.
208 |
209 |
210 |
211 |
Communication
212 |
213 |
The Patents and Standards Interest Group is a Member-only forum. PSIG
214 | mailing lists and their archives are Member-accessible. The Interest Group
215 | functions primarily through an email discussion list hosted by W3C. The main
216 | PSIG list is <member-psig@w3.org> with a Member accessible archive. It is
218 | expected that face-to-face meetings will take place on the order of once or
219 | twice each year, or as necessary, at the discretion of the Chair(s).
As explained in the Process Document (section
233 | 3.3), this group will seek to give feedback when there is consensus. When
234 | the Chair(s) puts a question and observes dissent, after due consideration of
235 | different opinions, the Chair(s) shall record any objections and a decision
236 | (possibly after a formal vote), and move on. Section 3.4,
238 | Votes of the W3C Process Document applies.
239 |
240 |
241 |
242 |
Patent Policy
243 |
244 |
The Patents and Standards Interest
245 | Group provides an opportunity to share perspectives on the topic addressed
246 | by this charter. While the Interest Group does not produce Recommendation-track
247 | documents, when Interest Group participants review Recommendation-track
248 | specifications from Working Groups, the disclosure obligations set out in Section
250 | 6 of the W3C Patent Policy do apply.
This charter for the Patents and Standards Interest Group has been created
260 | according to section 5.2.2 of the Process Document. In the event of a conflict between this
263 | document or the provisions of any charter and the W3C Process, the W3C Process
264 | Document shall take precedence.
265 |
266 |
Changes since the 2009 Charter
267 |
268 |
In 2013, the scope of the charter was extended. Beyond the discussion of
269 | Patent Policy issues, PSIG is now enabled by this new charter of 2013 to
270 | address questions of copyright, trademark and other intellectual property
271 | rights upon request of the Advisory Board, the Advisory Committee or the W3C
272 | Team.
273 |
In 2016, Scott Peterson stepped down as co-chair.
274 |
PROPOSED 2018: Charter extended through 2021, with scope expanded to permit drafting of new policy documents for consideration.
DRAFT 2021 Patents and Standards Interest Group Charter
41 |
42 |
The Patent and Standards Interest
43 | Group (PSIG) is designed as a forum for W3C Members to discuss matters
44 | regarding the W3C Patent Policy as well as W3C copyright in particular and
45 | larger issues regarding patents, licenses and Web standards. The PSIG is an
46 | Interest Group that gives feedback to the W3C Team, the Advisory Board and the
47 | Advisory Committee; PSIG does not make final policy decisions on behalf of W3C.
48 |
Teleconferences: The Interest Group may also
80 | conduct virtual meetings using email, IRC, wiki and teleconference
81 | facilities
82 | Face-to-face: The Patent and Standards Interest Group may meet
83 | face-to-face on the order of once or twice each year. It may also
84 | sponsor "Birds-Of-a-Feather" sessions at conferences, W3C Advisory
85 | Committee Meetings or Technical Plenaries or alongside other W3C
86 | meetings, at the discretion of the Chair(s).
87 |
88 |
89 |
90 |
91 |
92 |
Overview and Background
93 |
94 |
In May 2003, the W3C Director, on the advice of the W3C Membership, approved
95 | the W3C Patent Policy as the governing document for patent matters in W3C
96 | Recommendations. The Patent Policy Working Group (PPWG), which developed that
97 | policy over a more than three year period, assisted the Team with the
98 | implementation of the policy, and the PPWG then closed.
99 |
100 |
The W3C Patent Policy affirms and strengthens the basic patent licensing
101 | model that has driven innovation on the Web from its inception. The
102 | availability of an interoperable, unencumbered (i.e. royalty-free) Web
103 | infrastructure provides an expanding foundation for innovative applications,
104 | profitable commerce, and the free flow of information and ideas. The W3C Patent
105 | Policy encourages both commercial and non-commercial implementations of W3C
106 | Recommendations. Beyond establishing a commitment to royalty-free standards,
107 | the Patent Policy provides W3C with:
108 |
109 |
a stable, practical, written policy for all W3C Recommendations
110 |
a clear licensing framework for all W3C Recommendations
111 |
consistent patent disclosure obligations, and
112 |
an exception-handling process when problems arise.
113 |
114 |
115 |
The Patents and Standards Interest Group (PSIG) was formed in December 2004
116 | to provide an ongoing forum for discussion of general issues regarding
117 | implementation of the Patent Policy and to exchange views on Intellectual
118 | Property Rights (IPR). Upon request, PSIG continues to provide feedback on
119 | whether changes to the Patent Policy are desirable and how those changes might
120 | look.
121 |
122 |
Over time, PSIG has been asked for feedback on a variety of non-patent intellectual property
123 | questions. For example, PSIG opinions helped the W3C Team define the Community
124 | Group Licensing Agreement. In the discussion around HTML5 licensing, PSIG
125 | helped the Advisory Board evaluate licensing alternatives.
126 |
127 |
In 2019-2020, PSIG helped to draft and review an update to the W3C
128 | Patent Policy to align with Process 2020. On the advice of the Membership, W3C adopted that policy on 15 September, 2020.
129 |
130 |
This PSIG Charter continues the established practice for PSIG to
131 | discuss and provide feedback on IPR matters. This Charter also permits the PSIG
132 | to draft or suggest amended or additional patent policy documents.
133 |
134 |
135 |
136 |
Mission Statement
137 |
138 |
PSIG is a forum for W3C Members and Invited Experts to discuss and provide
139 | feedback to the W3C Team, the Advisory Board and the Advisory Committee on IPR
140 | questions.
141 |
142 |
PSIG may suggest further policy development and draft documents for
143 | such additional policies. Any policy development would be subject to
144 | Advisory Committee and Director review.
145 |
146 |
147 |
148 |
Scope
149 |
150 |
The W3C Team, Advisory Board and Advisory Committee may request
151 | that the PSIG provide feedback regarding the W3C Patent Policy, issues related to patent commitments for participants in current and proposed W3C activities (for example, continuous development), and other IPR issues.
152 | The PSIG may
153 | also exchange views and flag issues regarding the W3C Patent Policy.
154 | It may produce non-binding Interest Group Notes on those specific
155 | issues.
156 |
157 |
The PSIG will review, but is not responsible for formally documenting or
158 | implementing, W3C IPR policies.
159 |
160 |
161 |
162 |
Deliverables
163 |
164 |
As an Interest Group, the PSIG issues neither Recommendations nor other
165 | binding policy documents. It may draft policy documents or amendments to existing policy documents for Advisory Comittee review.
172 | The initiative to add or modify a FAQ entry may start with either the Team or the PSIG.
173 | If it starts with the Team, the Team proposes the FAQ entry to the PSIG. If it starts with the PSIG,
174 | any PSIG participant may raise an issue to the attention of PSIG, Chair(s), and Team, with or without a proposed disposition.
175 | One PSIG Chair must reply within 7
176 | days with one of these two dispositions:
177 |
178 |
PSIG heads-up. If the entry is likely uncontroversial, the PSIG Chair(s)
179 | forwards the proposal to the PSIG list with a comment deadline of
180 | 14 days. Unless someone on the PSIG objects within 14
181 | days, then the proposal may be added to the FAQ by the Team on the 15th
182 | day. If there is an objection from the PSIG, then it will be added to the
183 | PSIG agenda for discussion.
184 |
PSIG Agenda. If the proposal raises some substantial issue in the
185 | judgment of the PSIG Chair(s), then it will be sent to the PSIG list for
186 | comment and discussion will be scheduled for the next PSIG teleconference.
187 | After that, the PSIG will report back on the results.
188 |
189 |
190 |
The PSIG shall report at least annually to the Advisory Committee on its
191 | activities.
192 |
193 |
194 |
195 |
Dependencies
196 |
197 |
The PSIG will coordinate with the W3C Advisory Board, the Advisory Committee
198 | and the W3C Team on IPR matters raised. During considerations and as needed,
199 | PSIG can informally liaise with the relevant institutions in the standards and
200 | public policy communities around the world. Informal coordination is done via
201 | the Interest Group's mailing lists.
202 |
203 |
204 |
205 |
Participation
206 |
207 |
Any W3C Member may nominate up to 3 participants to the PSIG. The Chair(s)
208 | may invite qualified Invited Experts to participate in the PSIG in accordance
209 | with the Invited Expert provisions in the Process Document.
210 |
211 |
To the extent that PSIG participants are attorneys, they shall not be deemed
212 | to provide legal advice to W3C. Discussions, even about legal topics and while
213 | focused on a use case, are mere discussions and do not represent a legal
214 | opinion, express or implied.
215 |
216 |
217 |
218 |
Communication
219 |
220 |
The Patents and Standards Interest Group is a Member-only forum. PSIG
221 | mailing lists and their archives are Member-accessible. The Interest Group
222 | functions primarily through an email discussion list hosted by W3C. The main
223 | PSIG list is <member-psig@w3.org> with a Member accessible archive. It is
225 | expected that face-to-face meetings will take place on the order of once or
226 | twice each year, or as necessary, at the discretion of the Chair(s).
As explained in the Process Document (section
240 | 3.3), this group will seek to give feedback when there is consensus. When
241 | the Chair(s) puts a question and observes dissent, after due consideration of
242 | different opinions, the Chair(s) shall record any objections and a decision
243 | (possibly after a formal vote), and move on. Section 3.4,
245 | Votes of the W3C Process Document applies.
246 |
247 |
248 |
249 |
Patent Policy
250 |
251 |
The Patents and Standards Interest
252 | Group provides an opportunity to share perspectives on the topic addressed
253 | by this charter. While the Interest Group does not produce Recommendation-track
254 | documents, when Interest Group participants review Recommendation-track
255 | specifications from Working Groups, the disclosure obligations set out in Section
257 | 6 of the W3C Patent Policy do apply.
This charter for the Patents and Standards Interest Group has been created
267 | according to section 5.2.2 of the Process Document. In the event of a conflict between this
270 | document or the provisions of any charter and the W3C Process, the W3C Process
271 | Document shall take precedence.
The mission of the Web Security Interest Group is to serve as a forum for discussions on improving standards and implementations to advance the security of the Web.
119 | Wendy Seltzer (0.05 FTE) and Samuel Weiler (0.05 FTE), W3C
120 |
121 |
122 |
123 |
124 | Meeting Schedule
125 |
126 |
127 | Teleconferences: as-needed.
128 |
129 | Face-to-face: we will meet during the W3C's annual Technical Plenary week.
130 |
131 |
132 |
133 |
134 |
135 |
136 |
137 |
138 |
Scope
139 |
As the Web Platform around HTML5 emerges as a platform for sophisticated application development, security properties of both implementations and specifications become critical. This group provides a forum for technology designers, implementors, and other interested parties to work toward improving specifications and implementations to advance security of the Web overall. The group is, in particular, focused on the security properties of HTML5 and related APIs and technologies.
140 |
141 |
142 |
143 |
144 |
145 | Deliverables
146 |
147 |
As an Interest Group, this group has no formal deliverables. The group may propose additional
148 | standards work to the W3C and may publish Interest Group Notes on topics such as best
149 | practices, analysis of security issues, and design considerations.
150 |
The Group intends to focus its work on three categories of effort:
151 |
Incubation: Discussing ideas for new Recommendation-track work; dispatching
152 | promising ideas to a Community Group or Task Force; proposing drafts to W3C
153 | for Working Group chartering.
154 |
Horizontal Reviews: Assessing W3C drafts for security considerations and/or
155 | publishing questionnaires or other guidance to enable self-review by working groups.
156 |
Web Security Incident Review: Considering reported security incidents as
157 | input, e.g., to correct patterns of error, threat modeling, and new spec development.
158 |
159 |
160 |
161 |
162 |
163 |
164 |
165 |
166 |
Coordination
167 |
Technical coordination with the following Groups will be made, per the W3C Process Document:
168 |
169 |
170 |
171 |
172 |
W3C Groups
173 |
174 |
214 |
W3C Working Groups may ask this Interest Group to provide security review of
215 | specifications.
216 |
217 |
External Organizations
218 |
219 |
As needed
220 |
221 |
222 |
223 |
224 |
225 |
226 |
227 |
228 |
229 |
230 |
231 | Participation
232 |
233 |
234 | Participation in the Web Security Interest Group is open to the public. Any person interested in this topic is welcome to participate in this Interest Group.
235 |
236 | There are no minimum requirements for participation in this group: This IG is composed of the participants in the public-web-security@w3.org mailing list.
237 |
241 | The group encourages questions, comments and issues on its public mailing lists and document repositories, as described in Communication.
242 |
243 |
244 |
245 |
246 |
247 |
248 |
249 | Communication
250 |
251 |
252 | Technical discussions for this Interest Group are conducted in public.This group primarily conducts its work on the public mailing list public-web-security@w3.org.
253 |
254 |
255 | Information about the group (including details about deliverables, issues, actions, status, participants, and meetings) will be available from the Web Security Interest Group home page.
256 |
257 |
266 |
267 |
268 |
269 |
270 | Decision Policy
271 |
272 |
273 | This group will seek to make decisions through consensus and due process, per the W3C Process Document (section 3.3). 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.
274 |
275 | 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 may call for a group vote, and record a decision along with any objections.
276 |
277 |
278 | To afford asynchronous decisions and organizational deliberation, any resolution (including publication decisions) taken in a face-to-face meeting or teleconference will be considered provisional.
279 |
280 | A call for consensus (CfC) will be issued for all resolutions (for example, via email and/or web-based survey), with a response period from one week to 10 working days, depending on the chair's evaluation of the group consensus on the issue.
281 |
282 | If no objections are raised on the mailing list by the end of the response period, the resolution will be considered to have consensus as a resolution of the Interest Group.
283 |
284 |
285 | All decisions made by the group should be considered resolved unless and until new information becomes available, or unless reopened at the discretion of the Chairs or the Director.
286 |
287 |
288 | This charter is written in accordance with the W3C Process Document (Section 3.4, Votes), and includes no voting procedures beyond what the Process Document requires.
289 |
290 |
291 |
292 |
293 |
294 |
295 |
Patent Disclosures
296 |
The Interest Group provides an opportunity to
297 | share perspectives on the topic addressed by this charter. W3C reminds
298 | Interest Group participants of their obligation to comply with patent
299 | disclosure obligations as set out in Section
300 | 6 of the W3C Patent Policy. While the Interest Group does not
301 | produce Recommendation-track documents, when Interest Group
302 | participants review Recommendation-track specifications from Working
303 | Groups, the patent disclosure obligations do apply. For more information about disclosure obligations for this group,
304 | please see the W3C
305 | Patent Policy Implementation.
321 | This charter 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.
322 |
144 | Teleconferences:topic-specific calls may be held or something else
145 |
146 | Face-to-face: we will meet during the W3C's annual Technical Plenary week; additional face-to-face meetings may be scheduled by consent of the participants, usually no more than 3 per year.
147 |
148 |
149 |
150 |
151 |
152 |
153 |
Motivation and Background
154 |
155 | This Group is intended to address several use cases:
156 |
157 |
158 |
New ideas and dimensions: a new human step may impact
159 | the Web, e.g., "autonomous L4/L5 cars", "one continent
160 | forking the technology stack of the Internet and the Web",
161 | "sustainable blockchain", "6G Networks";
162 |
New people: a welcoming point for Members/people who are unfamiliar
163 | with our processes and systems, to understand the organization;
164 |
New workshops: a relevant topic needs alignment around the
165 | next steps for W3C, e.g., "generative AI", "Digital Identity on
166 | the Web";
167 |
Monitoring industry trends: monitor other SDOs by leveraging the
168 | knowledge of W3C Members and enrolling them to monitor outside
169 | organizations, and report back on regular basis;
170 |
Publishing Report: Create public analyses of trends that affect
171 | the Web, seeking rough consensus or presentation of
172 | competing perspectives. The analyses would summarize
173 | the trending topic, outline the promise and pitfalls that are
174 | being discussed, point to relevant W3C efforts, and indicate
175 | the degree of consensus in the group on the value of the topic
176 | for the Web;
177 |
Chartering: there is a charter but we need to measure the interest
178 | from the W3C community at large and make it fit in the larger
179 | picture, e.g., Real Estate IG.
180 |
181 |
182 |
183 |
184 |
Scope
185 |
186 | The goal of Exploration Interest Group provides a platform to help
187 | the W3C community explore emerging Web-related technology trends,
188 | consider how the community could collaborate to shape these trends
189 | for the benefit of the Web users, accelerate chartering investigations
190 | and endeavors, and continually strengthen the innovation of W3C.
191 |
192 |
193 |
194 | Work with W3C Members and the W3C Team to propose, prioritize, and
195 | assist in organizing Workshops or other events. Topics may come
196 | from discussions within CGs, TPAC Breakout Sessions, Workshops
197 | and Liaison Reports, etc.
198 |
199 |
200 | Work with W3C Members and W3C Team to prioritize potential
201 | work areas, to facilitate creation of Community Groups, to
202 | coordinate among Community Groups, and to advise on how to
203 | transition work from CG to WG;
204 |
205 |
206 | Work with W3C Members and the W3C Team to monitor W3C Liaisons,
207 | invite insightful SDOs experts, and provide a platform to report
208 | back on potential areas of investigations;
209 |
210 |
211 | Discuss how to continue improving the exploration and
212 | investigation process, and propose improvements to the W3C Advisory Board and the
213 | W3C Team.
214 |
215 |
216 |
217 |
218 |
219 |
220 |
221 |
222 | Deliverables
223 |
224 |
225 |
Updated document status is available on the group publication status page. [or link to a page this group prefers to use]
226 |
227 |
228 | Non-normative documents may be created such as reports on
229 | exploration and investigations.
230 |
231 |
232 |
233 |
234 |
Success Criteria
235 |
236 |
How do we measure success ?
237 |
238 |
239 |
240 |
241 |
Coordination
242 |
243 |
244 | This Group is expected to coordinate with any relevant group...
245 |
275 | To be successful, this Interest Group is expected to have 6 or
276 | more active participants for its duration. The Chairs
277 | are expected to contribute a quarter of a working day per week
278 | towards the Interest Group. There is no minimum requirement for
279 | other Participants.
280 |
281 |
282 | The group encourages questions, comments and issues on its public mailing lists and document repositories, as described in Communication.
283 |
284 |
285 | The group also welcomes non-Members to contribute through its public communication channels.
286 |
296 | Technical discussions for this Interest Group are conducted in public: the meeting minutes from teleconference and face-to-face meetings will be archived for public review, and technical discussions and issue tracking will be conducted in a manner that can be both read and written to by the general public. Working Drafts and Editor's Drafts of specifications will be developed in public repositories and may permit direct public contribution requests. (Does the IG plan to write EDs and WDs?)
297 | The meetings themselves are not open to public participation, however.
298 |
299 |
300 | Information about the group (including details about deliverables, issues, actions, status, participants, and meetings) will be available from the Exploration Interest Group home page.
301 |
302 |
303 | Most Exploration Interest Group teleconferences will focus on discussion of particular specifications, and will be conducted on an as-needed basis.
304 |
305 |
306 | This group primarily conducts its technical work pick one, or both, as appropriate: on the public mailing list public-[email-list]@w3.org (archive)
307 | or on GitHub issues.
308 | The public is invited to review, discuss and contribute to this work.
309 |
310 |
311 | The group may 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 participant requests such a discussion.
312 |
313 |
314 |
315 |
316 |
317 |
318 |
319 | Decision Policy
320 |
321 |
322 | This group will seek to make decisions through consensus and due process, per the W3C Process Document (section 5.2.1, Consensus). 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.
323 |
324 | However, if a decision is necessary for timely progress and consensus is not achieved after careful consideration of the range of views presented, the Chairs may call for a group vote and record a decision along with any objections.
325 |
326 |
327 | To afford asynchronous decisions and organizational deliberation, any resolution (including publication decisions) taken in a face-to-face meeting or teleconference will be considered provisional.
328 |
329 | A call for consensus (CfC) will be issued for all resolutions (for example, via email, GitHub issue or web-based survey), with a response period from [pick a duration within:] one week to 10 working days, depending on the chair's evaluation of the group consensus on the issue.
330 |
331 | If no objections are raised by the end of the response period, the resolution will be considered to have consensus as a resolution of the Interest Group.
332 |
333 |
334 | All decisions made by the group should be considered resolved unless and until new information becomes available or unless reopened at the discretion of the Chairs.
335 |
The Interest Group provides an opportunity to
346 | share perspectives on the topic addressed by this charter. W3C reminds
347 | Interest Group participants of their obligation to comply with patent
348 | disclosure obligations as set out in Section
349 | 6 of the W3C Patent Policy. While the Interest Group does not
350 | produce Recommendation-track documents, when Interest Group
351 | participants review Recommendation-track specifications from Working
352 | Groups, the patent disclosure obligations do apply. For more information about disclosure obligations for this group,
353 | please see the licensing information.
370 | This charter has been created according to section 3.4 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.
371 |
372 |
373 |
374 |
375 | Charter History
376 |
377 |
Note:Display this table and update it when appropriate. Requirements for charter extension history are documented in the Charter Guidebook (section 4).
The mission of the Web-based Signage Working Group is to provide APIs that enable a web application to get the device information and to control the device via a user agent in a digital signage terminal device.
120 | Teleconferences: topic-specific calls may be held
121 |
122 | Face-to-face: we will meet during the W3C's annual Technical Plenary week; additional face-to-face meetings may be scheduled by consent of the participants, no more than 3 per year.
123 |
124 |
125 |
126 |
127 |
128 |
129 |
Scope
130 |
This Working Group will define APIs for user agents ("UA"s hereafter) embedded in digital signage terminal devices ("devices" hereafter).
131 |
132 |
Web-based signage is a digital signage using web technologies. Web-based signage terminal functions are performed by a web application loaded on a UA. The web application is called a Web-based Signage Player (“player” hereafter), which shows digital signage contents in accordance with the order provided by the digital signage server. The player also should have terminal management functions such as terminal configuration, logging, and reporting as well as content management. Usually, once a player is loaded on a UA, it works automatically.
133 |
134 |
Two types of users exist for UAs of the devices. They are a device operator who remotely operates devices and audiences who watch the devices. The device operator, not always a human being but a server function, has access to UAs of devices. The operator typically does not have access to the devices physically but wants to control the devices beyond the network. On the contrary, audiences, who are anonymous and in the general public, do not have control over devices.
135 |
136 |
The signage UA should provide API for the player to be used by a device operator.
137 |
138 |
The Working Group will define the prior required APIs for the operator to manage the signage UA via web console of the controlling device. Basically, the APIs are classified to the following functions:
139 |
140 |
Get the device information
141 |
Control the device
142 |
143 |
144 |
145 |
These operations require protection mechanism to prevent unauthorized accesses.
146 |
147 |
The specifications produced by this Working Group will address security and privacy considerations because the device UAs controlled by the device operator rather than the audiences watching the devices. The considerations need to address the combination of both the UAs and the controlling device.
148 |
149 |
Members of the Working Group should review other working groups' deliverables that identified as being relevant to the Working Group's mission.
150 |
151 |
152 |
Out of Scope
153 |
The following features are out of scope, and will not be addressed by this Working Group.
154 |
155 |
156 |
This Working Group will not define or mandate hardware specification of devices.
157 |
This Working Group will not define the APIs for generic UAs but them for embedded UAs in devices.
158 |
This Working Group will not also define the security configuration because it depends on the device hardware configuration.
159 |
160 |
161 |
162 |
163 |
Success Criteria
164 |
In order to advance to Proposed Recommendation, each specification is expected to have at least two independent implementations of each of feature defined in the specification.
165 |
Each specification should contain a section detailing any known security or privacy implications for implementers, Web authors, and end users.
166 |
167 |
168 |
169 |
170 |
171 |
172 |
173 | Deliverables
174 |
175 |
176 |
Draft state indicates the state of the deliverable at the time of the charter approval. Expected completion indicates when the deliverable is projected to become a Recommendation, or otherwise reach a stable state.
177 |
178 |
179 |
180 | Normative Specifications
181 |
182 |
183 | The working group will deliver the following W3C normative specifications:
184 |
185 |
186 |
Power Status Management
187 |
188 |
This function consists of Power Status Control and Power Status Scheduling. This enables web applications to access the device’s power management system. Consulting the power status mode of the device, there are stand-by mode (display off and UA stopped) and display-off mode (only display off) in addition to running mode (display on and UA running). Power Status Control provides the function of changing the power status mode of the device to such modes for saving power. Resuming from stand-by mode, it needs a scheduled return, which is provided by Power Status Scheduling. By studying the use cases, the function will be consulted for enhancement.
189 |
Draft state:[No draft]
190 |
191 |
Contextual Information
192 |
193 |
The function consists of Signage Operational Information and Signage Functional Information. The information provided by this function is used for the device management and the content management for signage services. Signage Operational Information provides the unique information of the device such as hardware information (serial number, manufacture name, or model name), which is used for the device identification. Signage Functional Information allows us to get the functional information of the device such as resolution and size of display used for fitting the contents to display. The information obtained for the remote management may be enriched by use case discussion.
The Working Group is strongly encouraging the participants to create and maintain use cases and requirements document for each specification. In addition, use cases regarding the web-based signage service are expected to be discussed in Web-based Signage Business Group.
206 |
Implementation guidelines:
207 |
The group may provide informative guidelines for implementers to encourage its implementation.
208 |
209 |
210 | Other non-normative documents may be created such as:
211 |
212 |
213 |
Primers
214 |
Non-normative group notes
215 |
216 |
217 |
218 |
219 |
220 | Milestones
221 |
222 |
223 |
Milestones
224 |
225 |
226 |
Specification
227 |
FPWD
228 |
CR
229 |
PR
230 |
Rec
231 |
232 |
233 |
234 |
235 |
Remote Management API
236 |
Q1 2017
237 |
Q3 2017
238 |
Q1 2018
239 |
Q3 2018
240 |
241 |
242 |
243 |
244 |
Note: The actual production of some of the deliverables may follow a different timeline. The group documents any schedule changes on the group home page.
245 |
246 |
247 |
248 |
249 |
250 |
251 |
Coordination
252 |
For all specifications, this Working Group will seek horizontal review for accessibility, internationalization, performance, privacy, and security with the relevant Working and Interest Groups, and with the TAG. Invitation for review must be issued during each major standards-track document transition, including FPWD and CR, and should be issued when major changes occur in a specification.
253 |
254 |
Additional technical coordination with the following Groups will be made, per the W3C Process Document:
The Web-based Signage Working Group intends to have its deliverables reviewed by the Web and TV Interest Group from the perspective of using a TV set as a device of Web-based signage.
The goal of the Web of Things Interest Group is to accelerate the development of open markets of applications and services based on the role of Web technologies for a combination of the Internet of Things (IoT) with the Web of data. The Web-based Signage Working Group intends to collaborate with Web of Things Interest Group to create standard in the view point of a device as one of Things for remote management.
Digital Signage Consortium studies and develops the digital signage services and systems with its member companies including location owners (buildings, railways), content and service providers, and system integrators.
DSMA consists over 200 member companies dedicated to the digital signage industry, including end users, system integrators, content developers and manufacturers. DSMA is the organizer of the annual Digital Signage Asia Forum presented at the InfoComm China event.
278 |
279 |
280 |
281 |
282 |
283 |
284 |
285 |
286 |
287 |
288 | Participation
289 |
290 |
291 | To be successful, this Working Group is expected to have 10 or more active participants for its duration, including representatives from the key implementers of this specification, and active Editors and Test Leads for each specification. The Chairs, specification Editors, and Test Leads are expected to contribute half of a day per week towards the Working Group. There is no minimum requirement for other Participants.
292 |
293 |
294 | The group encourages questions, comments and issues on its public mailing lists and document repositories, as described in Communication.
295 |
296 |
297 | The group also welcomes non-Members to contribute technical submissions for consideration, with the agreement from each participant to Royalty-Free licensing of those submissions under the W3C Patent Policy.
298 |
299 |
300 |
301 |
302 |
303 |
304 |
305 | Communication
306 |
307 |
308 | Technical discussions for this Working Group are conducted in public. Meeting minutes from teleconference and face-to-face meetings will be archived for public review, and technical discussions and issue tracking will be conducted in a manner that can be both read and written to by the general public. Working Drafts and Editor's Drafts of specifications will be developed on a public repository, and may permit direct public contribution requests.
309 |
310 |
311 | Information about the group (including details about deliverables, issues, actions, status, participants, and meetings) will be available from the Web-based Signage Working Group home page.
312 |
313 |
314 | Most Web-based Signage Working Group teleconferences will focus on discussion of particular specifications, and will be conducted on an as-needed basis.
315 |
316 |
317 | This group primarily conducts its technical work on the public mailing list public-[email-list]@w3.org (archive). The public is invited to post messages to this list.
318 |
319 |
320 | The group may 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 participant requests such a discussion.
321 |
322 |
323 |
324 |
325 |
326 |
327 |
328 | Decision Policy
329 |
330 |
331 | This group will seek to make decisions through consensus and due process, per the W3C Process Document (section 3.3). 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.
332 |
333 | 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 may call for a group vote, and record a decision along with any objections.
334 |
335 |
336 | To afford asynchronous decisions and organizational deliberation, any resolution (including publication decisions) taken in a face-to-face meeting or teleconference will be considered provisional.
337 |
338 | A call for consensus (CfC) will be issued for all resolutions (for example, via email and/or web-based survey), with a response period from one week to 10 working days, depending on the chair's evaluation of the group consensus on the issue.
339 |
340 | If no objections are raised on the mailing list by the end of the response period, the resolution will be considered to have consensus as a resolution of the Working Group.
341 |
342 |
343 | All decisions made by the group should be considered resolved unless and until new information becomes available, or unless reopened at the discretion of the Chairs or the Director.
344 |
345 |
346 | This charter is written in accordance with the W3C Process Document (Section 3.4, Votes), and includes no voting procedures beyond what the Process Document requires.
347 |
348 |
349 |
350 |
351 |
352 |
353 |
354 | Patent Policy
355 |
356 |
357 | 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.
358 |
359 | For more information about disclosure obligations for this group, please see the W3C Patent Policy Implementation.
360 |
377 | This charter 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.
378 |
The mission of the Service Workers Working Group
73 | is to enable Web applications to take advantage of persistent background processing, including hooks
74 | to enable bootstrapping of web applications while offline.
75 |
76 |
79 |
80 |
81 |
82 |
83 |
84 | Start date
85 |
86 |
87 | [dd month yyyy the date when the group call for participation starts]
88 |
129 | Teleconferences: Teleconferences will be held approximately monthly.
130 |
131 | Face-to-face: The Working Group will meet during the W3C's annual Technical Plenary week;
132 | additional face-to-face meetings will be scheduled by consent of the participants,
133 | 2 or 3 times per year.
134 |
135 |
136 |
137 |
138 |
139 |
140 |
Scope
141 |
Web Applications traditionally assume that the network is reachable, which is not always the case.
142 | The Working Group will specify event-driven services between the network layer and the application,
143 | allowing it to handle network requests gracefully even while offline.
144 |
145 |
152 |
153 |
Each specification should contain a section detailing any known security or privacy implications
161 | for implementers, Web authors, and end users.
162 |
Each specification should have an associated testing plan developed in parallel,
163 | and complete by the time the specification reaches
164 | Candidate Recommendation; by Recommendation, there should be test suite for each deliverable, sufficiently broad to demonstrate interoperability.
165 |
Each specification should have implementation reports showing adoption, fostering the ready availability of multiple, independent, interoperable implementations, including in browsers, authoring, and validation tools, and usage on the Web.
166 |
167 |
If a critical mass of key stakeholders and implementers of this technology do not join the group, its charter should be re-examined by the W3C.
168 |
169 |
170 |
171 |
172 |
173 |
174 |
175 | Deliverables
176 |
177 |
178 |
More detailed milestones and updated publication schedules are available on the
179 | group publication status page.
180 |
181 |
Draft state indicates the state of the deliverable at the time of the charter approval.
182 | Expected completion indicates when the deliverable is projected to become a Recommendation,
183 | or otherwise reach a stable state.
184 |
185 |
186 |
187 | Normative Specifications
188 |
189 |
190 | The Working Group will deliver the following W3C normative specifications:
191 |
This specification defines an API that uses Service Workers to permit both one-off and periodic synchronisation of data,
215 | for applications that use non-local data storage.
216 |
217 |
218 |
219 |
The Working group may produce multiple versions of each deliverable, reflecting developments
220 | in how much of the relevant technology is interoperably implemented.
221 |
222 |
223 | The working group intends to use a parallel specification-editing and -testing approach,
224 | where all normative specification changes are generally expected to have a corresponding test change, either
225 | in the form of new tests or modifications to existing tests, or must include the rationale for
226 | why test updates are not required for the proposed update.
227 |
228 |
229 |
230 |
231 |
232 |
233 |
234 | Other Deliverables
235 |
236 |
237 | Other non-normative documents may be created such as:
238 |
239 |
240 |
Use case and requirement documents;
241 |
Test suite and implementation report for the specification;
242 |
Primer or Best Practice documents to support web developers when designing applications.
243 |
244 |
245 |
246 |
247 |
Timeline
248 |
249 |
June 2017: First teleconference
250 |
August-September 2017: First face-to-face meeting
251 |
October 2017: Service Workers 1 Candidate Recommendation
252 |
October 2017: FPWD for Service Workers 2
253 |
2019: Service Workers 2
254 |
March 2019: Proposal for rechartering or closing the Working Group
255 |
256 |
257 |
258 |
259 |
260 |
Coordination
261 |
For all specifications, this Working Group will seek
262 | horizontal review
263 | for accessibility, internationalization, performance, privacy, and security with the
264 | relevant Working and Interest Groups, and with the
265 | TAG.
266 | Invitation for review must be issued during each major standards-track document transition,
267 | including FPWD
268 | and CR,
269 | and should be issued when major changes occur in a specification.
270 |
271 |
Additional technical coordination with the following Groups will be made,
272 | per the W3C Process Document:
This group enables improved client-side application development on the Web,
279 | including application programming interfaces (APIs) for client-side development.
301 | To be successful, this Working Group is expected to have 6 or more active participants
302 | for its duration, including representatives from the key implementors of this specification,
303 | and active Editors and Test Leads for each specification.
304 | The Chairs, specification Editors, and Test Leads are expected to contribute
305 | half of a working day per week towards the Working Group.
306 | There is no minimum requirement for other Participants.
307 |
308 |
309 | The group encourages questions, comments and issues on its public mailing lists and document repositories,
310 | as described in Communication.
311 |
312 |
313 | The group also welcomes non-Members to contribute technical submissions for consideration,
314 | subject to contributors' agreement to the terms of the
315 | W3C Patent Policy.
316 |
317 |
318 |
319 |
320 |
321 |
322 |
323 | Communication
324 |
325 |
326 | Technical discussions for this Working Group are conducted in
327 | public:
328 | meeting minutes from teleconference and face-to-face meetings will be archived for public review,
329 | and technical discussions and issue tracking will be conducted in a manner that can be both
330 | read and written to by the general public.
331 | Working Drafts and Editor's Drafts of specifications will be developed on a public repository,
332 | and may permit direct public contribution requests.
333 | The meetings themselves may not open to public participation, however.
334 |
335 |
336 | Information about the group including details about deliverables, issues, actions, status, participants, and meetings
337 | will be available from the Service Workers Working Group home page.
338 |
339 |
340 | Working Group teleconferences will focus on discussion of particular issues,
341 | and will be conducted on an as-needed basis.
342 |
343 |
344 | This group primarily conducts its technical work
345 | on GitHub issues.
346 | The public is invited to review, discuss, and subject to agreement to the terms of the
347 | W3C Patent Policy contribute to this work.
348 |
349 |
350 |
351 |
352 |
353 |
354 |
355 | Decision Policy
356 |
357 |
358 | This group will seek to make decisions through consensus and due process, per the
359 | W3C Process Document (section 3.3).
360 | For technical decisions, an editor or other participant typically makes an initial proposal,
361 | which is then refined in discussion with members of the group and other reviewers,
362 | and consensus emerges with little formal voting being required.
363 |
364 | If consensus is not achieved after careful consideration of the range of views presented
365 | but a decision is necessary for timely progress, the Chairs may call for a vote,
366 | in accordance with the W3C Process Document (Section 3.4, Votes)
367 | and the process for asynchronous resolution described in the following paragraphs
368 | in which case they will record a decision along with any objections.
369 |
370 |
371 | To afford asynchronous decisions and organizational deliberation, any resolution including
372 | requests for transition of document states decisions
373 | taken in a face-to-face meeting or teleconference will be considered provisional.
374 |
375 |
376 | Any resolution taken in a face-to-face meeting or teleconference is to be considered provisional
377 | until 10 (ten) working days after the publication of the resolutions in meeting minutes
378 | on the working group's mailing list.
379 |
380 |
381 | A call for consensus (CfC) will be issued for all resolutions not proposed at a teleconference or face to face meeting
382 | with a response period of at least one week, based on the chair's evaluation of the group consensus on the issue.
383 |
384 |
385 | If no objections are raised on the mailing list by the end of the response period,
386 | the resolution will be considered to have consensus as a resolution of the Working Group.
387 |
388 |
389 | All decisions made by the group should be considered resolved unless and until new information becomes available,
390 | or unless reopened at the discretion of the Chairs or the Director.
391 |
392 |
393 | This charter is written in accordance with the W3C Process Document (Section 3.4, Votes), and includes no voting procedures beyond what the Process Document requires.
394 |
395 |
396 |
397 |
398 |
399 |
400 |
401 |
402 | Patent Policy
403 |
404 |
405 | This Working Group operates under the
406 | W3C Patent Policy
407 | (5 February 2004 Version). To promote the widest adoption of Web standards,
408 | W3C seeks to issue Recommendations that can be implemented according to this policy,
409 | on a Royalty-Free basis.
410 |
411 | For more information about disclosure obligations for this group, please see the
412 | W3C Patent Policy Implementation.
413 |
433 | This charter has been created according to
434 | section 5.2
435 | of the Process Document.
436 | In the event of a conflict between this document or the provisions of any charter and the W3C Process,
437 | the W3C Process shall take precedence.
438 |
This charter [proposal] brings the Service Worker specification to a new Working Group, and proposes the
454 | Background Synchronization specification a W3C Recommendation-track deliverable, according to the
455 | W3C Process Document (section 5.2.3).
The mission of the Verifiable Credentials Working Group is to maintain the Verifiable Credentials Data
74 | Model specification and related Working Group Notes.
Teleconferences: On an as-needed basis, up to once every quarter
120 | Face-to-face: none
121 |
122 |
123 |
124 |
125 |
126 |
127 |
128 |
129 |
Scope
130 |
The Working Group will maintain the Verifiable Credentials Data
131 | Model specification, which provides a mechanism to express a
132 | verifiable credential on the Web in a way
133 | that is cryptographically secure, privacy respecting, and machine-verifiable.
134 |
135 |
136 |
Out of Scope
137 |
The Working Group will not:
138 |
139 |
Define browser-based APIs for interacting with verifiable credentials. This work may be performed by a future Working Group if there is interest, but is not required for the Working Group to be successful.
140 |
Define a new protocol for attribute exchange. This work may be performed by a future Working Group if there is interest, but is not required for the Working Group to be successful.
141 |
Attempt to lead the creation of a specific style of supporting infrastructure, other than a data model and syntax(es), for a verifiable credentials ecosystem.
142 |
Attempt to address the larger problem of "Identity on the Web/Internet".
143 |
144 |
145 |
146 |
147 |
148 |
149 |
150 | Deliverables
151 |
152 |
153 |
154 |
155 | Normative Specifications
156 |
157 |
158 | The Working Group will maintain the following W3C normative specification:
159 |
Each substantive change should consider updating the section detailing all known
196 | security and
197 | privacy implications for implementers, Web authors, and end users.
198 |
To promote interoperability, all changes made to specifications should have tests.
199 |
200 |
201 |
202 |
Coordination
203 |
204 |
This group is expected to coordinate with the Credentials Community Group
205 | on consensus-based proposals related to content changes for Verifiable Credentials Working Group Deliverables. The Chairs of
206 | this group may choose to reject proposals that are incompatible with this Charter.
207 |
208 |
209 |
For all specifications, this Working Group will seek horizontal review for
210 | accessibility, internationalization, performance, privacy, and security with the relevant Working and
211 | Interest Groups, and with the TAG.
212 | Invitation for review must be issued during each major standards-track document transition, including
213 | FPWD. The
214 | Working Group is encouraged to engage collaboratively with the horizontal review groups throughout development of
215 | each specification. The Working Group is advised to seek a review at least 3 months before
216 | CR and is encouraged
217 | to proactively notify the horizontal review groups when major changes occur in a specification following a review.
218 |
219 |
Additional technical coordination with the following Groups will be made, per the W3C Process Document:
Develop technical and policy mechanisms to improve the security of and enable secure cross-site communications for applications on the Web. For security reviews, coordination is expected through the public-web-security mailing list.
236 |
237 |
238 |
This group will also collaborate with future W3C Working Groups developing authentication protocols.
Ensure that the mobile driving licenses being modeled and expressed by the ISO SC17 WG10 community are compatible with the work of the Verifiable Credentials WG.
251 |
252 |
If the Working Group perceives the need for IETF review, W3C will arrange discussion through its IETF liaison.
253 |
254 |
255 |
256 |
257 |
258 |
259 |
260 | Participation
261 |
262 |
263 | To be successful, this Working Group is expected to keep the participants who contributed to the Recommendation, including representatives from the key implementors of this specification, and active Editors and Test Leads for each specification. The Chairs are expected to contribute half of a working day per quarter towards the Working Group. There is no minimum requirement for other Participants.
264 |
265 |
266 | The group encourages questions, comments and issues on its public mailing lists and document repositories, as described in Communication.
267 |
268 |
269 | The group also welcomes non-Members to contribute technical submissions for consideration upon their agreement to the terms of the W3C Patent Policy.
270 |
282 | Technical discussions for this Working Group are conducted in public: the meeting minutes from teleconference will be archived for public review, and technical discussions and issue tracking will be conducted in a manner that can be both read and written to by the general public. Working Drafts and Editor's Drafts of specifications will be developed on a public repository and may permit direct public contribution requests.
283 | The meetings themselves are not open to public participation, however.
284 |
285 |
286 | Information about the group (including details about deliverables, issues, actions, status, participants, and meetings) will be available from the Verifiable Credentials Working Group home page.
287 |
288 |
289 | Most Verifiable Credentials Working Group teleconferences will focus on discussion of particular specifications, and will be conducted on an as-needed basis.
290 |
291 |
292 | This group primarily conducts its technical work in GitHub issues.
293 | The public is invited to review, discuss and contribute to this work.
294 |
295 |
296 | The group may 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 participant requests such a discussion.
297 |
298 |
299 |
300 |
301 |
302 |
303 |
304 | Decision Policy
305 |
306 |
307 | This group will seek to make decisions through consensus and due process, per the W3C Process Document (section 3.3). 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.
308 |
309 | However, if a decision is necessary for timely progress and consensus is not achieved after careful consideration of the range of views presented, the Chairs may call for a group vote and record a decision along with any objections.
310 |
311 |
312 | To afford asynchronous decisions and organizational deliberation, any resolution (including publication decisions) taken in a teleconference will be considered provisional.
313 |
314 | A call for consensus (CfC) will be issued for all resolutions (for example, via email and/or web-based survey), with a response period from one week to 10 working days, depending on the chair's evaluation of the group consensus on the issue.
315 |
316 | If no objections are raised on the mailing list by the end of the response period, the resolution will be considered to have consensus as a resolution of the Working Group.
317 |
318 |
319 | All decisions made by the group should be considered resolved unless and until new information becomes available or unless reopened at the discretion of the Chairs or the Director.
320 |
321 |
322 | This charter is written in accordance with the W3C Process Document (Section 3.4, Votes) and includes no voting procedures beyond what the Process Document requires.
323 |
324 |
325 |
326 |
327 |
328 |
329 |
330 | Patent Policy
331 |
332 |
333 | This Working Group operates under the W3C Patent Policy (Version of 5 February 2004 updated 1 August 2017). 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.
334 |
335 | For more information about disclosure obligations for this group, please see the W3C Patent Policy Implementation.
336 |
353 | This charter 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.
354 |
The mission of the Pointer Events Working Group is to provide methods to enable simple device-independent input from pointing devices such as mouse, pen, and multi-touch screen.
129 | Teleconferences: topic-specific calls may be held
130 |
131 | Face-to-face: we will meet during the W3C's annual Technical Plenary week; additional face-to-face meetings may be scheduled by consent of the participants, no more than 3 per year.
132 |
133 |
134 |
135 |
136 |
137 |
138 |
Scope
139 |
Web browsers can receive input in a variety of ways including mouse, touch, and pen input. A “pointer” is an abstract form of input that can be any point of contact on a input surface made by a mouse cursor, pen, finger, or multiple fingers.
140 |
141 |
Pointer Events provide support for handling mouse, touch, and pen input for web sites and web applications through DOM Events. For example, a content creator using Pointer Events would only have use a single model, rather than separate code paths for mouse events, touch events, and pen-tablet events, making authoring content much more efficient and inclusive.
142 |
143 |
This Working Group seeks to enhance the features delivered in the Pointer Events Level 1 Recommendation by exploring changes, such as:
144 |
145 |
Addition of direction-specific values for finer-grained control of panning touch behaviors
Additional clarifications of API behavior and performance optimizations
148 |
149 |
150 |
151 |
Out of Scope
152 |
The following features are out of scope, and will not be addressed by this working group.
153 |
154 |
155 |
Gestures. Examples of out-of-scope gesture functionality and APIs include, but are not limited to, the following:
156 |
157 |
Comparisons between pointers to determine an action (e.g., panning for scrollable regions, pinch for zooming, press-and-hold for a mouse right-click).
158 |
Comparisons between time stamps of pointers to determine an action.
159 |
Comparisons between combinations of pointers and/or their time stamps to determine an action.
160 |
Determining an action based on comparison to a threshold (e.g., scroll speed based on a pressure threshold, panning based on distance threshold, press-and-hold based on a timing threshold).
161 |
APIs or functionality processing data that is indicative of a confidence level that a pointer is associated with a gesture.
162 |
163 |
164 |
165 |
Higher level APIs used to convey user intent.
166 |
167 |
High-level representational events, which are in the scope of the Web Events and IndieUI working groups.
168 |
169 |
170 |
171 |
Input targeting methods and disambiguation.
172 |
173 |
The algorithms and underlying systems used to determine target elements and pointer location.
174 |
Algorithms to determine unintended input (e.g. palm rejection).
175 |
176 |
177 |
178 |
Equipment used to detect input events.
179 |
180 |
Sensors, algorithms, and systems used to detect physical interactions and convert them into input events.
181 |
182 |
183 |
184 |
Ink and handwriting APIs.
185 |
186 |
187 |
188 |
189 |
Success Criteria
190 |
In order to advance to Proposed Recommendation, each specification is expected to have at least two independent implementations of each of feature defined in the specification.
191 |
192 | Each specification should contain a section detailing any known security or privacy implications for implementers, Web authors, and end users.
193 |
Draft state indicates the state of the deliverable at the time of the charter approval. Expected completion indicates when the deliverable is projected to become a Recommendation, or otherwise reach a stable state.
206 |
207 |
208 |
209 | Normative Specifications
210 |
211 |
212 | The working group will deliver the following W3C normative specifications:
213 |
This specification builds upon the Pointer Events Level 1 specification. This specification defines a unified interface for web applications to access event information related to pointing devices. This includes mouse, pen, multi-touch screen, and related input mechanisms. While device-specific information such as pressure or contact geometry might be included in the events, web developers can program against the events without needing to know what type of device created them.
231 | Other non-normative documents may be created such as:
232 |
233 |
234 |
Use case and requirement documents;
235 |
Test suite and implementation report for the specification;
236 |
Primer or Best Practice documents to support web developers when designing applications.
237 |
238 |
239 |
240 |
241 |
242 |
243 |
244 |
Coordination
245 |
For all specifications, this Working Group will seek horizontal review for accessibility, internationalization, performance, privacy, and security with the relevant Working and Interest Groups, and with the TAG. Invitation for review must be issued during each major standards-track document transition, including FPWD and CR, and should be issued when major changes occur in a specification.
246 |
247 |
Additional technical coordination with the following Groups will be made, per the W3C Process Document:
254 | The Touch Events community group was formed by members of the Web Events Working Group (responsible for the Touch Events specification) and the Pointer Events Working Group (responsible for the Pointer Events spec). The group's focus is to determine differences in touch event behavior between browsers.
255 |
258 | This Group provides specifications that enable improved client-side application development on the Web, including application programming interfaces (APIs) for client-side development and markup vocabularies for describing and controlling client-side application behavior.
259 |
262 | The mission of the Accessible Platform Architectures Working Group (APA WG) is to ensure W3C specifications provide support for accessibility to people with disabilities.
263 |
264 |
265 |
266 |
External Organizations
267 |
268 |
none
269 |
270 |
271 |
272 |
273 |
274 |
275 |
276 |
277 |
278 | Participation
279 |
280 |
281 | To be successful, this Working Group is expected to have 6 or more active participants for its duration, including representatives from the key implementors of this specification, and active Editors and Test Leads for each specification. The Chairs, specification Editors, and Test Leads are expected to contribute half of a day per week towards the Working Group. There is no minimum requirement for other Participants.
282 |
283 |
284 | The group encourages questions, comments and issues on its public mailing lists and document repositories, as described in Communication.
285 |
286 |
287 | The group also welcomes non-Members to contribute technical submissions for consideration, with the agreement from each participant to Royalty-Free licensing of those submissions under the W3C Patent Policy.
288 |
289 |
290 |
291 |
292 |
293 |
294 |
295 | Communication
296 |
297 |
298 | Technical discussions for this Working Group are conducted in public. Meeting minutes from teleconference and face-to-face meetings will be archived for public review, and technical discussions and issue tracking will be conducted in a manner that can be both read and written to by the general public. Working Drafts and Editor's Drafts of specifications will be developed on a public repository, and may permit direct public contribution requests.
299 |
300 |
301 | Information about the group (including details about deliverables, issues, actions, status, participants, and meetings) will be available from the Pointer Events Working Group home page.
302 |
303 |
304 | Most Pointer Events Working Group teleconferences will focus on discussion of particular specifications, and will be conducted on an as-needed basis.
305 |
306 |
307 | This group primarily conducts its technical work on the public mailing list public-pointer-events@w3.org (archive). The public is invited to post messages to this list. Additional discussion is conducted on Github.
308 |
309 |
310 | The group may 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 participant requests such a discussion.
311 |
312 |
313 |
314 |
315 |
316 |
317 |
318 | Decision Policy
319 |
320 |
321 | This group will seek to make decisions through consensus and due process, per the W3C Process Document (section 3.3). 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.
322 |
323 | 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 may call for a group vote, and record a decision along with any objections.
324 |
325 |
326 | To afford asynchronous decisions and organizational deliberation, any resolution (including publication decisions) taken in a face-to-face meeting or teleconference will be considered provisional.
327 |
328 | A call for consensus (CfC) will be issued for all resolutions (for example, via email and/or web-based survey), with a response period from one week to 10 working days, depending on the chair's evaluation of the group consensus on the issue.
329 |
330 | If no objections are raised on the mailing list by the end of the response period, the resolution will be considered to have consensus as a resolution of the Working Group.
331 |
332 |
333 | All decisions made by the group should be considered resolved unless and until new information becomes available, or unless reopened at the discretion of the Chairs or the Director.
334 |
335 |
336 | This charter is written in accordance with the W3C Process Document (Section 3.4, Votes), and includes no voting procedures beyond what the Process Document requires.
337 |
338 |
339 |
340 |
341 |
342 |
343 |
344 | Patent Policy
345 |
346 |
347 | 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.
348 |
366 | This charter 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.
367 |