Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.


Table of Contents
excludeCHARTER - Human Experience Working Group

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.

...

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 " in the same sense as hardware or software. It is 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 a currency of social interaction, informed directly by our human experiences. 

...

Scope

The scope of the Human Experience Working Group (HXWG) is naturally that of the Human Trust layers of the ToIP stacks stack (Layers 3 and 4) as opposed to Technical Trust .   (which is the main focus of Layers 1 and 2).  

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 HXWG 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 The HXWG 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. 

...

Purpose

The purpose of this working group the HXWG 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. 

...

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.

...

Deliverables

Following are the general categories of deliverables that fall under the HXWG charter. Specific deliverables will be identified as the HXWG moves forward.

  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.

3) Quarterly sprints

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

...

Intellectual Property Rights (Copyright, Patent, Source Code)

The HXWG inherits its IPR terms from the JDF Charter. These include:

...

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. 

...

  • Apache 2.0, available

...

...

8. Non-Working Group Participant Feedback and Participation

...

  • .