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

Compare with Current View Page History

« Previous Version 4 Next »

This document is contains core components of the Principal Document or the Yoma Ecosystem Governance Framework from the ToIP Metamodel.  It is used to define governance framework (GF) components in our experimental agile approach to GF development.

Introduction - TBC

This section is a non-normative general introduction to the GF that orient first-time readers as to the overall context of the GF. It:

  1. SHOULD have a reference to the ToIP Foundation, the ToIP Stack, and the ToIP Governance Template from which it was derived.
  2. MAY include an Acknowledgements section to acknowledge the contributors to the GF.

Purpose

The Yoma Ecosystem Governance Framework (YEGF) governs the principles, rules, policies and accountabilities for the administration and operation of the Yoma digital marketplace for youth across the world to build and transform their futures by actively engaging in social impact tasks and learning & earning opportunities. 

Scope

The YEGF includes the following Entities

  • Youth Participant - An Individual human subscribing to the Yoma Platform
  • Opportunity Provider - An Organisation or Individual providing Education, Employment or Impact Opportunities to the Yoma marketplace
  • Technology Provider - An Organisation providing hardware or software technology services that form part of the Yoma Infrastructure 
  • Incentive Provider - An Organisation or Individual providing economic value in the form of money, services or digital assets which can be exchanged with other Entities in the Yoma Ecosystem
  • Marketplace Participant - An Organisation or Individual providing goods or services which can be exchanged for Incentives within the Yoma ecosystem.
  • Yoma Ecosystem Infrastructure - the set of Things including hardware and software components that are used by other Entities in the ecosystem to interact, the Yoma Ecosystem Governance Authority, the Yoma Member Directory, and the Yoma Governance Framework. 
  • Yoma Infrastructure Operator - An Organisation that builds, administers and operates the Yoma Infrastructure
  • Yoma Ecosystem Governance Authority - The Organisation that maintains and enforces the Ecosystem Governance Framework
  • Local Yoma Ecosystem - An Organisation that makes use of Yoma Ecosystem Infrastructure and which has localised features to its Governance Framework
  • Yoma Verified Registry - The publicly available and verifiable list of Issuer and Verifier Organisations.




Objectives - TBC

This states the high-level outcomes desired by the Governance Authority through its execution of its Governance Framework. It:

  1. SHOULD specify tangible, achievable results (e.g. SMART criteria and Fit-for-purpose criteria).
  2. SHOULD specify the intended overall outcomes of the Rules and Policies in the GF.
  3. MUST align with its Purpose.
  4. MUST only contain outcomes that the GF has the authority and mechanisms to achieve within its Scope.
  5. SHOULD consider its Principles.


  1. Be open and accessible to all youth to access the marketplace and participate in governance
  2. Enable all identity rights holders to have agency, control of their identity data, and to protect their data
  3. Provide incentives for all stakeholders to participate in the marketplace

  4. Enable experiential and individualized learning pathways for youth participants, facilitating the link between action and learning 

  5. Create a fair and trusted marketplace of opportunities with a focus on youth and SDG impact 
  6. Build an open source governance model that is easy for similar ecosystems to adopt, scalable and extensible to accommodate local implementations of Yoma.

Principles

The YEGF will inherit the Principles of SSI all additional principles or language derived from the Yoma Vision, Mission & Values as well as youth values definition sessions  which prioritised Self Development,  Fairness, Community and Accessibility. They are grouped using the human-centric groupings of Agency, Control and Protection as defined by the Sovrin Governance Framework Working Group.

AGENCY

1, Youth Agency & Empowerment First  The Yoma ecosystem shall prioritise the empowerment, capacity building and agency of youth as primary Identity Rights Holders within the ecosystem. All key decisions are made in consultation with young people keeping their best interests in mind

2. Representation and Uniqueness  The Yoma ecosystem shall provide the means for any entity—human, legal, natural, physical or digital—to be represented by any number of digital identities. The Yoma ecosystem shall strive to recognize the uniqueness of every identity rights holder and to provide customizable and localized journeys to match the uniqueness of its users.

3. Control & Agency  The Yoma ecosystem shall empower entities who have natural, human, or legal rights in relation to their identity (“Identity Rights Holders”) to control usage of their digital identity data and exert this control by employing and/or delegating to agents and guardians of their choice, including individuals, organizations, devices, and software.

4. Ethics, Fairness and Inclusion  The Yoma ecosystem shall not exclude or discriminate against identity rights holders whether Individual or Organisation within its governance scope.  All stakeholders within the Yoma Ecosystem shall operate with mutual respect, integrity, and equity to all.  The Yoma ecosystem is open to all who share Yoma’s values.

5. Usability, Accessibility, and Consistency  The Yoma ecosystem shall maximize usability and accessibility of agents and other SSI components for identity rights holders, including consistency of user experience.

CONTROL

6. Interoperability  The Yoma ecosystem shall enable digital identity data for an entity to be represented, exchanged, secured, protected, and verified interoperably using open, public, and royalty-free standards.  

7. Decentralization  The Yoma ecosystem shall not require reliance on a centralized system to represent, control, or verify an entity’s digital identity data.  

8. Participation  The Yoma ecosystem shall not require an identity rights holder to participate.  

9. Portability  The Yoma ecosystem shall not restrict the ability of identity rights holders to move or transfer a copy of their digital identity data to the agents or systems of their choice.

PROTECTION

10. Security  The Yoma ecosystem shall empower identity rights holders to secure their digital identity data at rest and in motion, to control their own identifiers and encryption keys, and to employ end-to-end encryption for all interactions.  

11. Verifiability and Authenticity The Yoma ecosystem shall empower identity rights holders to provide verifiable proof of the authenticity of their digital identity data

12.  Privacy and Minimal Disclosure  The Yoma ecosystem shall empower identity rights holders to protect the privacy of their digital identity data and to share the minimum digital identity data required for any particular interaction.  

13. Transparent  The Yoma ecosystem shall empower identity rights holders and all other stakeholders to easily access and verify information necessary to understand the incentives, rules, policies, and algorithms under which agents and other components of the ecosystem operate.  

14. Community and Sustainability  Financial, environmental and social sustainability is core to the Yoma Ecosystem both in terms of its operations and the impact it seeks to have on the communities in which it operates.

Primary Policies - TBC as part of agile approach

This section contains the Policies that apply to the GF as a whole and not just in the context of a particular Controlled Document. It:

  1. SHOULD include the Policies that:
    1. Apply generally to governance of the entire Trust Community;
    2. Apply to the structure of the GF, e.g., what Controlled Documents must be specified by whom and applied to whom.
    3. Guide the development of more specific Policies within the Controlled Documents.
  2. SHOULD NOT include Policies that apply only within the context of a specific category addressed by one of the Controlled Documents.
  3. MUST include Responsible Use Policies that apply generally to infrastructure governed by the GF.
  4. MUST include any Regulatory Compliance Policies that are not specified within particular Controlled Documents.

Revisions - TBC

This section specifies the policies for how revisions to the GF are governed. It does not include Governance Policies for the Governance Authority or interdependent Governance Authorities (those are defined in Controlled Documents in the Governance Rules category). It:

  1. MUST state the full legal identity and contact information for the primary Governance Authority or interdependent Governance Authorities.
  2. MUST include policies specifying how any revisions to the GF are identified, developed, reviewed, and approved.
  3. SHOULD include at least one public review period for any GF that will be available to the public.

Extensions - TBC

This section applies to GFs that permit extensions via the incorporation of other GFs (a common feature especially of some ecosystem GFs). It:

  1. MUST state whether the GF can be extended.
  2. MUST specify the requirements an Extension Governance Framework must meet in order to be approved.
  3. MUST specify the process for an Extension Governance Framework to be approved.
  4. MUST define an authoritative mechanism for registration and activation of an approved Extension Governance Framework.
  5. MUST define the requirements for notification of the Trust Community about an approved Extension Governance Framework.

Schedule of Controlled Documents - TBC as part of agile approach

This is a listing of all Controlled Documents in the GF. It:

  1. MUST include authoritative references to all Controlled Documents in the GF.
  2. MUST identify the exact version of each Controlled Document with a unique, permanent DID or DID URL.
  3. SHOULD include a Web link to each Controlled Document in the Web version of the GF.
  4. SHOULD include a brief description of the purpose and scope of each Controlled Document to make it easy for readers to navigate the GF.

Controlled Documents - TBC as part of agile approach

Each Controlled Document covers a specific area of the GF. The following are categories of Controlled Documents where each category MAY include zero or more Controlled Documents.

Glossary - TBC as part of agile approach

See this wiki page

The Glossary provides a common basis for terminology. It:

  1. SHOULD be a single Controlled Document (even if it is organized by categories or other heuristics).
  2. SHOULD provide a common reference for all possibly ambiguous terms used throughout the GF.
  3. SHOULD reference the ToIP Glossary—or tagged subset(s) of the ToIP Glossary—for all terms defined there.
  4. SHOULD list all terms alphabetically (by language) for easy reference.[Rieks: OED (lexico), cambridge, wikipedia, etc, say that glossary IS already an alphabetically sorted list of words]
  5. MAY tag terms by category or usage.
  6. MAY specify that terms specific to one Controlled Document are defined in that Controlled Document.

Risk Assessment, Trust Assurance, and Certification - TBC as part of Agile

This category includes policies for managing risk, including how parties can be certified against the GF. Controlled Documents in this category:

  1. SHOULD identify key risks that MAY negatively affect the achievement of the GF's purpose within its scope.
  2. SHOULD include a Risk Assessment process output that provides an assessment of each key risk that the GF is designed to address and mitigate.
  3. SHOULD assess which Roles and Processes are vulnerable to each risk and how they are affected.
  4. SHOULD include a Risk Treatment Plan (RTP) for how identified risks are treated (e.g. mitigated, avoided, accepted or transferred).
  5. SHOULD include a Trust Assurance Framework that defines how Roles assert compliance with the Policies of the GF and the mechanisms of assurance over those assertions.
  6. SHOULD (if applicable) define the roles of Auditors and Auditor Accreditors and the policies governing their actions.
  7. SHOULD (if applicable) define the roles of Certification Authorities and the Policies governing their actions and relationships with the Governance Authority, Auditors, and Auditor Accreditors.
  8. SHOULD (if applicable) include policies around the developing, licensing, and usage of one or more Trust Marks.

RULES: TBC as part of agile approach

Governance Rules

These are the Rules for governing the GF as a whole. Controlled Documents in this category:

  1. MUST specify the primary Governance Authority or all interdependent Governance Authorities (if any).
  2. MUST include Controlled Documents that specify governance Policies for the primary Governance Authority or all interdependent Governance Authorities (e.g., Charter, Bylaws, Operating Rules, etc.)
  3. SHOULD address any antitrust Policies, intellectual property rights (IPR) Policies, confidentiality Policies, or other regulatory compliance policies under which the stakeholders agree to operate.
  4. SHOULD include any Policies governing enforcement of the GF and how Dispute Resolution will be handled.

Business Rules

These are the Rules governing the business model(s) of the GF and/or sustainability of the Governance Authority. Controlled Documents in this category:

  1. SHOULD clearly explain the exchange(s) of value within the Trust Community for which the GF is designed.
  2. SHOULD define the Policies governing how and when these exchanges of value take place.
  3. SHOULD define how all Members will be accountable for their actions in these exchanges.
  4. SHOULD define how the Governance Authority and the GF are sustainable under these Rules.

Technical Rules

These are the Rules governing technical interoperability. Controlled Documents in this category:

  1. MUST specify how Members of the Trust Community will interoperate technically using the ToIP Technology Stack by reference to ToIP Standard Specifications (TSS).
  2. SHOULD (if necessary) reference one or more specific ToIP Interoperability Profiles (TIPs).
  3. SHOULD specify any technical Policies or Specifications that are specific to this Trust Community.

Information Trust Rules

These are the Rules governing information security, privacy, availability, confidentiality and processing integrity as these terms are defined by the AICPA for service organizations. Controlled Documents in this category:

  1. MUST specify how Members of the Trust Community will ensure the following categories of Information Trust:
    1. Information security
    2. Information privacy
    3. Information availability
    4. Information confidentiality
    5. Information processing integrity
  2. SHOULD specify the relevant Information Trust Policies by reference to:
    1. ToIP Standard Specifications (TSS).
    2. Other regulatory or industry standards.
    3. GF-specific Policies.
    4. Member-specific Policies.

Inclusion, Equity, and Accessibility Rules

These are the Rules governing how the GF enables fair and equal access to all. Controlled Documents in this category:

  1. MUST specify how Members of the Trust Community will enable and promote inclusion, equitability, and accessibility by reference to:
    1. ToIP Standard Specifications (TSS).
    2. Other regulatory or industry standards/guidelines.
    3. GF-specific Policies.
    4. Member-specific Policies.
  2. SHOULD specifically address how the GF is designed to help bridge (or eliminate) the digital divide.

Legal Agreements - TBC as part of agile approach

This category includes any legal agreements or contracts included in the GF. Controlled Documents in this category:

  1. MUST include all legal agreements or contracts between Members and/or the Governance Authority.
  2. SHOULD reference the Glossary document for all terms not defined within.
  3. MUST clearly state the parties to whom these legal agreements apply.
  4. MUST define or reference all relevant accountability and enforcement mechanisms.
  5. SHOULD reference any other relevant Policies in the balance of the GF.

Standards

General Data Protection Regulation of the EU

Technical 

W3C Standards for Accessibility, Verifiable Credentials, Data Model, Decentralized Identifiers


  • No labels