Skip to toolbar

Community & Business Groups

W3C Credentials Community Group Charter

This charter was ratified on September 12th, 2014 by the Credentials Community Group.

A credential is a qualification, achievement, quality, or piece of information about an entity’s background such as a name, government ID, payment provider, home address, or university degree.

The purpose of the Credentials Community Group is to discuss, research, document, prototype and test credential storage and exchange systems for the Web. This work is done in order to make progress toward possible future standardization and interoperability of both low and high-stakes credentials. The goal of this Group is to forge a path for a secure, decentralized system of credentials that would empower both individual people and organizations on the Web to store, transmit, and receive digitally verifiable proof of qualifications and achievements. In addition to documentation, this Group collaborates on and shares various proof-of-concept solutions and components through open source methods, unencumbered by patents or royalties.

In general, this Community Group provides an inclusive venue where credentialing solutions, regardless of their origin, can be incubated, evaluated, refined, and tested. The focus of the group is to promote credentialing innovations based primarily on their technical merit. This approach invites competing technical designs to be submitted and incubated in the same group. The hope is that this strategy will lead to either the merging of the best aspects of each technical design, or a clear differentiation emerging between alternative designs.

Scope of Work

In general, the topics that are “in scope” include anything related to enabling interoperable credentials on the Web. These topics include:

  • Storage formats for digital credentials.
  • Protocols for the storage and transmission of digital credentials.
  • Low-stakes (community-based education, badges, gamification of social events) and high-stakes (P-12, high school or high school equivalent, university degrees, licenses, government-issued IDs, security documents) credentials.
  • Identity as it relates to an entity that claims ownership over a set of digital credentials. The credentials must be capable of identifying an entity and proving that the entity is capable, authorized, or qualified to perform a particular task or operation.
  • Identity and privacy technologies as they relate to ensuring the proper identification and protection of parties engaging in the exchange of credentials.
  • Security as it relates to ensuring the proper end-to-end protection and authenticity of the exchange of credentials as well as the use of these credentials to login, or get authorization to access, a particular website.
  • Base technologies (digital signatures, secure messaging, etc.) that are vital for the proper operation of the solutions deemed in-scope for the Credentials CG. If the technology is not being incubated elsewhere, it may be incubated in the Credentials CG.
  • Legal, regulatory, and policy concerns that affect the successful deployment of any of the use cases or technology concepts.

In general, the topics that are “out of scope” involve anything not directly related to enabling interoperable credentials on the Web. Some examples of these topics are:

  • The relative merits of various economic, political, or sociological theories. (i.e. The focus of this Community Group is on Web-based credentialing methods under any economic, political or sociological scenario.)
  • Marketing or evangelizing of technologies not intended to be released under a license compatible with W3C specifications. Discussion of out-of-scope solutions should be limited to elaborating upon technological advantages/disadvantages.

Work Items

In general, all documents related to credentialing are welcome. If there is someone who will commit to being an editor for a document, the group should agree to accept it as a work item even if it conflicts with previous work adopted by the community. Newly-accepted work items that extend beyond the scope of this Community Group Charter will lead to a reconsideration of the Charter. The Community Group may vote to revise the Charter in order to include new work, or to determine that the proposed work is unrelated to credentialing.

The following specific work items have been included by members of the Credentials Community Group:

  • Identity Credentials – A decentralized read/write identity mechanism for the Web that allows arbitrary Linked Data to be read from and written to an identity URL. This enables things like age verification, education credential exchange, and “Know Your Customer” assertions (required by most national banking regulation) for the Web. It is also designed to provide a one-click Web login mechanism by either integrating with systems like Mozilla Persona and OpenID Connect, or operating in a stand-alone decentralized login mode.
  • Secure Messaging – A secure and verifiable messaging mechanism built using Linked Data principles to produce a distributed Public Key Infrastructure for the Web. This enables credential exchange and the data associated with those credentials to be protected in a way that is easy for Web Developers to understand and implement. This work also includes a Linked Data security vocabulary.
  • HTTP Signatures – A digital signature mechanism for the HTTP protocol that adds origin authentication and message integrity to HTTP requests. The work also includes a complete security audit of the HTTP Signatures specification. This enables a Credentialing Web client to operate as an agent for an entity – unattended operation, automatic verification of credentials, automation of repetitive credentialing tasks, and in general, performing algorithmic transactions. Specifications covering HTTP Signature Nonces and HTTP Signature Trailers are also included in the work, but are a much lower priority since the Credentials work does not depend on that functionality.

Dependencies or Liaisons

Community Group Process

Anything in this charter that conflicts with requirements of the Community and Business Group Process is void.

Choosing a Chair

  • A Chair’s duties include:
    • Driving inclusivity, identifying consensus within the group, and recording decisions.
    • Ensuring compliance with all W3C rules applicable to the group.
    • Being a liaison between the group and all groups with which the group is coordinating.
    • Organizing the smooth operation of the group.
    • Engaging with media, performing outreach, and ensuring the transparent operation of the group.
  • Chairs are elected by the group for a 2 year term. There may be up to two Chairs at any given time. There are no limits to how often chairs can be re-elected by the group.
  • For an individual to run for election, they must be nominated by at least two people (other than themselves or an acting chair) and agree to the nomination. The nomination period lasts 14 days. Once an election date is set, each candidate has one week to submit a position statement about their qualifications to chair the group. The voting poll will stay open for a minimum of 14 days and the candidate with the most votes wins. If there is only one candidate at the end of the 14 day nomination period, that person immediately becomes the chair.
  • Chairs may be removed from their duties through a simple no-confidence vote. The no confidence vote must be requested by at least 3 members of the group and the vote will carry if 2/3rds of the votes cast request that the Chair is removed. A Chair who has been removed may stand for re-election.

Decision process

The decision making process goes through three possible steps and a decision is accepted as soon as it passes the requirements of any of the steps (in the following order):

  1. Working Consensus – When general agreement is found with no members being “strongly opposed” to a particular straw poll. Routine decisions can be made via discussion on the mailing list, without formal votes. If working consensus cannot be reached, then proceed to step 2.
  2. Chair Decision – When working consensus has not yet been reached, the Chair will propose that the matter be discussed further via the mailing list or will convene a conference call. When the group discusses an issue on the mailing list or a conference call, and there is a request from a member for assessing consensus, after due consideration of different opinions, the Chair should record a decision and any objections (with reasons if these have been expressed). If at least 3 members agree to take the matter to a formal vote, then proceed to step 3.
  3. Formal Vote – When all efforts to achieve working consensus fail and the Chair or various members consider that a determination must be made within limited time. Three participants may call to set aside “working consensus” on an specific written issue, and to initiate a simple majority vote. (This includes if they feel the Chair has not accurately determined the votes of the group or if they feel the Chair has refused to assess consensus.) Only members of the Community Group prior to this initial call for a vote may participate in the vote. Within 7 days of such a request, the Chair must announce the start and end dates, and the venue for the vote. Such a vote must be open at least 7 days and should be no more than 14 days, using a structured online voting solution, ensuring that no member votes more than once. In these cases, a decision shall be based on a simple majority of the votes cast (more than 50%).

The Chair is accountable to both the W3C and to Community Group members to ensure that all deliberation and decision processes are fair, respectful, aligned with these guidelines, and neither favouring or discriminating against any participant or their associates (incl. employer).

Transparency

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.
  • Changes to the Dependencies and Liasons list does not constitute an amendment to the charter that requires a rechartering vote.

Leave a Reply

Your email address will not be published. Required fields are marked *

Before you comment here, note that this forum is moderated and your IP address is sent to Akismet, the plugin we use to mitigate spam comments.

*