Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 11 Next »

NOTE


CHARTER - Human Experience Working Group

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.   

The HXWG will be action-orientated and aim to develop insights & practical resources to enable stakeholders in the ToIP community to improve outcomes for those using the products and services they are building. This includes exploring human behaviors; trust rituals across social and cultural contexts; mapping the objects, actors, mental models and actions at play; developing trust-centric best practices of user experience design; and assembling strategic resources that put people at the center of the design and engineering process. By helping the TolP community build ecosystems, governance frameworks, and products and services using inclusive and respectful design practices, the HXWG can act as the glue between the pillars of technology and governance under the Trust over IP stack.

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. 

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:

1) Inputs to Hopper / Backlog of activities, requirements, questions, design or research projects that we work on.  

    • Member requests or other WG requests.  
    • External third party requests 
    • Working Group Member ideas and projects  

2) Triaging / Prioritisation process against our Purpose and WG resources or capacity.

  • Quarterly sprints

3) Showcases

    • 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:

    • RAND Royalty-Free Mode, as set forth in Appendix A, Patent Policy Option 1. 
    • International Mode, as set forth in Appendix A, Patent Policy Option 2. 
    • Open Web Foundation Agreement 1.0 Mode, as set forth in Appendix A, Patent Policy Option 3. 
    • W3C Mode, as set forth in Appendix A, Patent Policy Option 4.
    • No Patent License. No patent licenses are granted for the Draft Deliverables or Approved Deliverables developed by this Working Group. 

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. 

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.



  • No labels