...
This Working Group Charter establishes the Scope, Principles, Purpose, Activities, Deliverables and intellectual property terms used to develop the materials identified in this Working Group Charter for the Project. Only Project Steering Members, Associates, and Contributors that Joined the Working Group will be bound by its terms and be permitted to participate in this Working Group.
...
1. Introduction
In its mission defining an architecture for internet-scale digital trust, the Trust over IP Foundation rightly acknowledges the critical importance of human trust at the business, legal and social layers. However, trust isn’t a tangible thing like code or cryptography. It’s not something we can directly control and doesn’t follow an instruction set. Trust is essentially a social and psychological construct, a feeling – one that can be defined as 'a confident relationship with the unknown.'
...
Human Trust is more complex than technical trust because it is entirely contextual and relies on offline relationships that cannot be captured as proofs or claims. Human Trust can not be built. It’s up to others – the public, users, citizens – to give, and needs to be earnt through continuously delivering repeatable, reliable experience. Looking through this lens of it being earned, given and received, we can see trust as the currency of social interaction, informed directly by our human experiences.
2. Scope
The scope of the Human Experience Working Group (HXWG) is naturally that of the Human Trust layers of the ToIP stacks as opposed to Technical Trust.
...
The working group aims to actively engage with as diverse an audience as possible, hosting community discussion around the human experience of digital trust and fostering an inclusive environment for the research and curation of human-level trust mechanics as a shared resource for use across domain boundaries.
3. Purpose
The purpose of this working group is to examine the design features of digital systems, their governance and the business processes that support them, which make interactions or actors trustable, in the contextual and subjective experience of those using them. Specifically our purpose is to:
...
Give voice to people by amplifying and articulating human requirements for trusted digital infrastructure and channelling human requirements to other ToIP working groups and the wider community.
4. Principles
- Inclusive by Design. The HXWG’s approach, process, membership and operation shall follow the principles of Inclusive Design to enable the ToIP community to serve the widest possible community of ecosystem participants. We inherit the ‘Inclusive by Design’ principles of section 2.9 from the Sovrin Governance Framework V2.0 (included in this charter as Appendix D).
- Cross pollination in ToIP. The HXWG shall actively seek to inject Human Experience into other ToIP Working Groups and Task Forces
- Respectful by Design. The HXWG recognizes that diversity of participation is not sufficient to give voice to minority or excluded groups, so we need to find ways of enabling communities to own and control the design process and its outcomes for themselves.
5. Example Deliverables
- Improve accessibility and user experience: Design principles, accessibility standards, best practice UX & HCI examples, and novel human interface guidelines for self-sovereign identity and decentralized digital trust infrastructure.
...
- Giving Voice to People: business requirements definitions expressed as user stories; customer councils that enable diverse groups to provide input directly into ToIP community roadmap, deliverables and priorities.
6. HXWG Start-Up Approach
As the scope of the HXWG is very wide we will start by trialing an agile approach to our delivery. Key elements of this process are:
...
- Monthly to project stakeholders
- Quarterly to the community
7. IP Licensing
...
1) Copyright Policy
- Copyright Grant to Project, as set forth in Appendix A, Copyright Policy
...
- Open Web Foundation 1.0. (only for those Working Groups selecting the Open Web Foundation mode for patent licensing).
...
2) Approved Deliverable Patent Licensing.
Each Working Group must specify the patent mode under which it will operate prior to initiating any work on any Draft Deliverable or Approved Deliverable other than source code. The patent mode for this Working Group is:
...
The assurances provided in the selected patent mode are binding on the Working Group Participant’s successors-in-interest. In addition, each Working Group Participant will include in any documents transferring ownership of patents subject to the assurance provisions sufficient to ensure that the commitments in the assurance are binding on the transferee, and that the transferee will similarly include appropriate provisions in the event of future transfers with the goal of binding each successor-in-interest.
...
3) Source Code.
Working Group Participants contributing source code to this Working Group agree that those source code contributions are subject to the Developer Certificate of Origin version 1.1, available at http://developercertificate.org/, and the license indicated below. Source code may not be a required element of an Approved Deliverable specification.
...
- MIT License, available at https://opensource.org/licenses/MIT.
- Mozilla Public License 2.0, available at https://www.mozilla.org/MPL/2.0/.
- Other. ________________________________________
- No source code will be developed.
8. Non-Working Group Participant Feedback and Participation
Upon the Approval of the Working Group Participants, the Working Group can request feedback from and/or allow Non-Working Group Participant participation in a Working Group, subject to each Non-Working Group Participant executing the Feedback Agreement set forth in Appendix B as expressed in membership documents.