NOTE

• All Trust over IP members are invited to review the proposed charter for this working group below.
• Please make your comments directly on this page (see this tip about how to make comments directly inline) or submit your comments to operations@trustoverip.org or to dluchuk@contractor.linuxfoundation.org by Monday, November 9, 2020.

...

CHARTER 

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 earned 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.   

...

This working group also has latitude to, with express approval from the Steering Committee, establish an in-residence position to offer guidance and recommendations, as well as directly support the implementations of measures, to address inclusion and diversity issues related to the work being done at Trust over IP. 

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: 

1. Improve accessibility and user experience of products and services being made within the ToIP community (and the wider decentralized identity and digital trust community).  

2. Promote inclusion and diversity by ensuring decentralised identity and digital trust technologies are being designed, built and deployed inclusively, with awareness of wider social contexts & human subjectivity. 

3. Challenge the status quo that is predominately white, male, western, centralised and tech-centric models of identity,  trust, risk, privacy and security. 

4. 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

1. 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).
2. Cross pollination in ToIP. The HXWG shall actively seek to inject Human Experience into other ToIP Working Groups and Task Forces 
3. 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

1. 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.
2. Promote inclusion and diversity: Ethnographic user research, user model frameworks, toolkits & field guides for framing challenges & building solutions unique to the ToIP stack.
3. Challenging the status quo: Outside-in definitions through B2C campaign of gathering definitions, experiences and stories about identity, trust, privacy and security.
4. 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. IPR Licensing

In this section, the default choices for each of the three JDF intellectual property rights licensing choices are shown in bold.

1) Copyright Policy 

• Copyright Grant to Project, as set forth in Appendix A, Copyright Policy
• Creative Commons Attribution 4.0, as set forth in Appendix A as expressed in membership documents
• 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. 

• Apache 2.0, available at http://www.apache.org/licenses/LICENSE-2.0.html. 
• 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.

...