W3C logo W3C Community and Business Groups

DRAFT W3C Trust & Permissions Community Group Charter DRAFT

This is a temporary location whilst the charter is being drafted and before the CG is launched. This document was derived from the CG charter template.

Goals

{TBD: describe the mission and goals of the Community Group. This should be a brief description describing the reason the group has been formed.}

As the Open Web Platform expands, new capabilities are likely to require new ways of managing permissions. This Community Group was formed to explore and evaluate such ways based upon experience with native and hybrid platforms, and drawing upon research studies. This follows on from the Paris meeting on trust and permissions held on 3-4 September 2014

Some platforms, e.g. Android, ask users upfront for permission when an app is installed or first run, whereas others like iOS ask users for permission when the application is attempting to use a given capability. Rather than asking the user for permission in advance, another approach is to invite the user to continue or to cancel an action after it has occurred, i.e. asking for forgiveness rather than permission. In some cases, the user's actions can be taken as implicitly granting permission. A further approach is for users to delegate decisions on permissions to a trusted 3rd party. Usability can be increased if apps are aware of which permissions have been granted or revoked. Monitoring can be used to determine when apps are using capabilities in ways suggestive of fingerprinting. What is needed to arrive at a consensus for a cross vendor solution?

Scope of Work

{TBD: Describe topics that are in scope. For specifications that the CLA patent section applies to, it is helpful to describe the scope in a way that it is clear what types of technologies will be defined in specifications, as opposed to adoption by reference or underlying technology not defined in the proposed spec. Key use cases are often helpful in describing scope. If no specifications will be defined in the group that the CLA patent section applies to, the charter should clearly state that. A clear scope is particularly important where patent licensing obligations may apply.}

The scope of this Community Group is limited to:

Should this charter limit work leading to proposals for specifications to a closed set of work items? If so what can we agree on for the initial charter (given that the CG will be able to update the charter if it so chooses)?

Here trusted UI is used in the sense introduced by Roesner et al. for user interface controls that implicitly grant permission for some action or actions, and can only be initiated by explicit user interactions. In principle, applications could embed trusted UI by reference to external components that the browser deems trustworthy following a security audit by browser vendors or trusted third parties.

Likewise, trust delegation could be based upon the origin (e.g. user's having asserted that they trust all apps from a given host name), or based upon locating attestations claiming the trustworthiness for a given app, origin or host name. One possible technique is for the apps themselves to provide links to such attestations on sites that the user asserts are trustworthy for such attestations. Trust could be based upon in-depth audits by specialists, or on crowd-based reputation mechanisms. This is something for discussion.

Out of Scope

{TBD: Identify topics known in advance to be out of scope}

Any thing we want to put here?

Deliverables

{TBD: Provide a brief description of each specification the group plans to produce. Where an estimate is possible, it can be useful to provide an estimated schedule for key deliverables. As described below, the group may later modify the charter deliverables. }

This includes work on best practices, use cases, requirements and proposed specifications that could be taken up by W3C Working Groups.

Community Group Reports that are Specifications

{TBD: Provide a brief description of each Community Group Report the group plans to publish. The description should be enough for those considering participation to know the general types of technologies that will be defined in the report.}

Examples would include proposals for trusted UI and trust delegation.

Community Group Reports that are not Specifications {TBD: Include only as necessary}

{TBD: Describe Community Group Reports that are not Specifications (e.g,. primers).} The group MAY produce other Community Group Reports within the scope of this charter but that are not Specifications covered by the CLA.

This would include best practices, use cases and requirements

Test Suites and Other Software {TBD: Include only as necessary}

{TBD: State whether test suites or any other software will be created for any Specifications. For information about contributions to W3C test suites, please see Test the Web Forward, and take note of W3C's test suite contribution policy and licenses for W3C test suites. For other software contributions, clearly state which licenses will govern contributions and distribution.}

This doesn't seem to be necessary, unless we want the CG to produce test suites for the specifications it proposes (if any).

Dependencies or Liaisons

{TBD: List any significant dependencies on other groups (inside or outside W3C) or materials. }

This Community Group will review and offer guidance on how trust and permissions are handled in APIs defined by W3C Working Groups, including but not limited to:

This Community Group may in some cases agree to review APIs defined by W3C Community and Business Groups.

Community and Business Group Process

Terms of in this charter that conflict with those of the Community and Business Group Process are void.

Work Limited to Charter Scope

The group will not publish Community Group Reports that are Specifications on topics other than those listed under "Community Group Reports that are Specifications" above. See below for how to modify the charter. The CLA applies to these Community Group Reports.

Contribution Mechanics

For these Reports, Community Group participants agree to send contributions to either the group “contrib” list or to the general group list, with subject line starting "“[short-name-for spec]". When meeting discussion includes contributions, contributors are expected to record those contributions explicitly on the mailing list as described.

Chair Selection

Participants in this group choose their Chair(s) and can replace their Chair(s) at any time using whatever means they prefer. However, if 5 participants (no two from the same organization) call for an election, the group must use the following process to replace any current Chair(s) with a new Chair, consulting the Community Development Lead on election operations (e.g., voting infrastructure and using RFC 2777).

  1. Participants announce their candidacies. Participants have 14 days to announce their candidacies, but this period ends as soon as all participants have announced their intentions. If there is only one candidate, that person becomes the Chair. If there are two or more candidates, there is a vote. Otherwise, nothing changes.
  2. Participants vote. Participants have 21 days to vote for a single candidate, but this period ends as soon as all participants have voted. The individual who receives the most votes —no two from the same organization— is elected chair. In case of a tie, RFC2777 is used to break the tie. An elected Chair may appoint co-Chairs.

Participants dissatisfied with the outcome of an election may ask the Community Development Lead to intervene. The Community Development Lead, after evaluating the election, may take any action including no action.

Decision Process

This group will seek to make decisions when there is consensus. When the group discusses an issue on the mailing list and there is a call from the group for assessing consensus, after due consideration of different opinions, the Chair should record a decision and any objections. Participants may call for an online vote if they feel the Chair has not accurately determined the consensus of the group or if the Chair refuses to assess consensus. The call for a vote must specify the duration of the vote which must be at least 7 days and should be no more than 14 days. The Chair must start the vote within 7 days of the request. The decision will be based on the majority of the ballots cast. It is the Chair’s responsibility to ensure that the decision process is fair, respects the consensus of the CG, and does not unreasonably favor or discriminate against any group participant or their employer.

Transparency

The group will conduct all of its technical work on its public mailing list. Any decisions reached at any meeting are tentative. Any group participant may object to a decision reached at an online meeting within 7 days of publication of the decision on the mail list. That decision must then be confirmed on the mail list by the Decision Process above.

Amendments to this Charter

The group can decide to work on a proposed amended charter, editing the text using the Decision Process described above. The decision on whether to adopt the amended charter is made by conducting a 30-day vote on the proposed new charter. The new charter, if approved, takes effect on either the proposed date in the charter itself, or 7 days after the result of the election is announced, whichever is later. A new charter must receive 2/3 of the votes cast in the approval vote to pass. The group may make simple corrections to the charter such as deliverable dates by the simpler group decision process rather than this charter amendment process. The group will use the amendment process for any substantive changes to the goals, scope, deliverables, decision process or rules for amending the charter.