Purpose

This document represents early planning discussions for the ToIP Ecosystem Foundry Working Group (EFWG). The objective is to help the WFWG members establish a baseline framework for the purpose and scope of the WG.

Specifically, this document provides a catalyst for the discussion of foundational ecosystem concepts to help the working group develop an initial scope for the establishment and lifecycle management of ecosystems.

This document addresses five topics:

  1. What is an “Ecosystem”?
  2. What is a "ToIP Ecosystem"?
  3. What is a “ToIP Ecosystem Project”?
  4. How would we describe the lifecycle management of an ToIP Ecosystem Project?
  5. Provide an exemplar use case to help visual the lifecycle management workflow concepts.

Concepts

The EFWG  needs to establish some foundational terms for submission to the ToIP Glossary (See Concepts and Terminology WG). This section provides initial working drafts for several key terms.

V0.1 -What is a TOIP Ecosystem?

A community of stakeholders including suppliers, distributors, customers, competitors, and government agencies involved in the delivery of specific products or services through both competition and cooperation. Each entity in the ecosystem affects and is affected by the others, creating a constantly evolving relationship that derives shared-value through trusted relationships.

******* Suggested Change (SM):

A community of stakeholders that may include any of: business entities, government agencies and individuals forged around a common purpose to deliver or consume specific products and services. Stakeholders relationships may include those of business partners, service providers, customers, consumers and competitors among others. Each entity in the ecosystem influences and is influenced by the others, creating dynamic relationships constrained by formal governance and policies with the overall goal of deriving shared-value through trusted relationships.

V0.2 What is a ToIP Ecosystem?

In the context of the ToIP stack we can have a more technically and legally precise definition of a ToIP ecosystem:

The set of all parties who have rights and responsibilities under a governance framework for applications at Layer Four of the ToIP stack. Note that a ToIP Layer Four ecosystem governance framework may span other ToIP governance frameworks operating at any layer.

V1.0 What is a ToIP Ecosystem?

A community of stakeholders that may include business entities, government agencies, and individuals forged around a common purpose to deliver, consume, or share products and services. Stakeholders relationships may include business partners, service providers, customers, consumers and competitors among others. Each entity in the ecosystem influences and is influenced by the others, creating dynamic relationships managed by formal governance framework policies with the goal of deriving shared-value through trusted relationships.  An Ecosystem represents the set of all parties who have rights and responsibilities under a governance framework for applications at Layer Four of the ToIP stack. Note that a ToIP Layer Four ecosystem governance framework may span other ToIP governance frameworks operating at any layer.

What is an ToIP Ecosystem Project?

A formalized collaborative activity, managed by members of an existing or prospective ToIP Ecosystem, that leverages the guidance of the ToIP Ecosystem Foundry Working Group (EFWG) to establish and maintain an operational implementation of a specific instance of a ToIP-compatible governance framework and a ToIP Interoperability Profile (TIP). Notes:

  • An ecosystem project may have an existing governance authority (GA), or part of its work may be planning the creation of a GA. Note that a GA may be of any size or complexity and may take many legal forms, such as a government agency, a consortia, a non-profit, a corporation, an NGO, a university, a city, etc. A GA may also be set up as a non-profit entity at the Linux Foundation.
  • An ecosystem project may choose to initially organize itself as a Task Force (TF) under the EFWG.
  • An ecosystem project may decide to produce a specific type of ToIP deliverable—an implementation plan for its ecosystem. (A implementation plan template should be a deliverable of the EFWG.)

Ecosystem Foundry Workflow

The EFWG needs to publish guidance for the life cycle management of an Ecosystem Project. This guidance must consider:

  • Ecosystem Project Requirements
  • Life cycle Management of an Ecosystem Project
  • Decision Tree Guidance for each life cycle swim lane


The following workflow diagram depicts the conceptual swim lanes of a life cycle management process for the establishment and maintenance of an Ecosystem Project.

Case Study Example: Chamber of Commerce Business Loyalty Ecosystem

In order to validate and refine the Ecosystem Foundry Workflow Process, a series of use case modeling exercises need to be undertaken. Contained herein is an initial example use case as a discussion starter.

Use Case Concepts

Chamber of Commerce (COC): A chamber of commerce is an association or network of business people designed to promote and protect the interests of its members. A chamber of commerce, sometimes known as a "board of trade," is often made up of a group of business owners that share a locale or interests.

Personas

The following subjects are stakeholders to use case:

  • Ann (Convener) - Chamber of commerce (COC) Director responsible for business on boarding and promoting local businesses through the COC business loyalty program.
  • Nick (issuer verifier) - Owner operator of a new Auto Repair shop. Not yet a member of the COC.
  • Don (issuer verifier) - Doughnut proprietor and member of COC, supports COC loyalty program by providing discounts to the community.
  • Mary (user) - New customer of Nick's Auto repair. A repeat customer of Don's doughnut shop and other businesses in the community.

User Stories

  • Ann and the COC want to digitize their business loyalty program by providing digital credential coupons to replace the existing print based system.
  • Nick wants to join the COC and use the loyalty program to promote his business.
  • Mary takes her car to Nick's Auto for service. She would like to receive a loyalty coupon credential from Nicks shop
  • Mary visits Don’s shop and wants to user her COC credential coupons to obtain discounts

Ecosystem Project Decision Flow

Learn

  • Ann and COC members learn about digital trust Ecosystems (benefits,value,....)
  • Review tools, standards, and best practices
  • Review compliance, legal and risk implications
  • Decision to convene

Convene

  • Ann creates a COC task force (the “Loyalty Program TF”) to help promote local business with a new digital business loyalty trust system. Members include Nicks Auto, Dons Doughnut shop, and other local businesses.
  • Ann’s objective is to leverage chamber membership as a means to drive community support of member businesses. Specifically, as a convener she desires to transform the print based loyalty program to:
    • Reduce friction
    • Expand reach of the COC
    • Increase velocity of COC adoption
  • Based on Ann’s learning activity, she has decided that a ToIP Ecosystem Project is applicable to her COC objectives.

Define


  • The Loyalty Program TF gathers to:
  • Articulate the scope for the management and governance of a new digital  program and dependent systems
    • COC loyalty data requirements for membership and discount coupons
    • Who will COC rely on to provide loyalty tools for the community?
    • Which utility is best fit for the COC program to establish transitory trust between COC members?
    • Define the methods necessary to ensure reliable digital exchange of loyalty:
    • Establish key performance indicators to measure and improve results

Create

  • The Loyalty Program TF decides they will not require the use of a Linux Foundation Ecosystem Project and instead they decide to establish the COC Loyalty Governance (COC-LG) Committee within the COC which is an existing non-profit entity. The COC-LG will manage the ecosystem of trust for the new digital Loyalty Program.
  • The new committee will be self-governed. It will manage all work-products under the existing COC knowledge repository using existing COC tools. 
  • The COC-LG formalizes decisions on policies for utilities, tools and schemas using TOIP governance framework templates.

Note: This section needs to be expanded into a decision-tree for a variety of process questions/answers.

Implement

  • COC-LG decides that a single public identity utility will be trusted for the ecosystem. This decision is captured in the Ecosystem Governance Trust Framework as “the Trusted Utility”.
  • The COC-LG:
    • publishes a loyalty credential and membership schema to the Trusted Utility.
    • employs a local digital wallet provider as their shared standard for the loyalty program. 
    • publishes Ecosystem Governance Trust Framework to the COC Membership.
    • publishes guidance and incentives to the citizen community. Demonstrates how to obtain and use wallets to interact with the COC loyalty program.
    • publishes a Chamber Membership Schema to the Trusted Utility.
    • publishes a Chamber Loyalty Schema to the Trusted Utility.
    • coordinates with vendors to provide education for all Chamber Members to become issuers and verifiers.
  • Members onboard themselves as Issuers and/or Verifiers and implement the loyalty program within their unique business processes.

Grow

  • COC-LG monitors and gathers results of the program and socializes with nearby Chambers.
  • COC-LG creates additional schemas to support new senior citizen and under 18 incentives
  • COC-LG evaluates options to expand the digital trust system into other business certification and licensing programs.

Next steps

While the example is high level, each workflow step will eventually be expanded into decision tree guidelines. Before we tackle this activity,  further modeling by example should be undertaken by EFWG members. Specifically, we need to:

  1. Request that volunteers create other ecosystem project use cases
  2. Solicit feedback on proposed workflow categories and definitions
    • Do we need more or less, should we change the terms of each step? 

What are the decision flows for each step?

  • No labels

6 Comments

  1. Scott Perry

    I think a fundamental step in the process that is not stated is a Risk Assessment.  It looks most applicable in the Define section.  A thorough risk assessment would identify inherent risks and help identify the roles that actors in the ecosystem play in mitigating risk.  It will also help the governance authority in selecting vendors that have control measures to confidently assert the level of assurance that the governance authority seeks to maintain within its objectives.  The Governance Working Group has not published a framework as yet but I suspect that a risk assessment will be a critical element in governance planning.  A solid example in risk assessment guidance from a governance authority is from PCI:  https://www.pcisecuritystandards.org/documents/PCI_DSS_v2_Risk_Assmt_Guidelines.pdf


  2. Scott Whitmire

    I can see adding "Operate" to the lifecycle, but truth be told, only Convene, Create, and Implement are steps, the rest don't have defined end dates. While we're at it, an Ecosystem Project as defined is not so much a project (with a defined end date) as an ongoing consortium. We should get these terms ironed out before we commit them to the ToIP glossary. 

  3. nicholas see

    @kenadler, within the SSI and the enterprise content mgmt contexts u mentioned earlier during the call, i see:

    > the verifier entity as the enterprise content mgmt platform,

    > the issuer of the access credential as the owner of the content/document and

    > the holder as the user wishing to access said content/document


    with the above configuration, the content mgmt platform wld have to be extended (via API hooks) to:

    #1 allow content owners to issue access credentials on said content/document to the holder that is requesting access

    #2 interoperate with the credential wallet of the holder when the holder wishes to access said content/document [ refer to DID Auth architectures 1 to 10 at https://tinyurl.com/y89tahad  ]

    #3 verify  proof requests eminating from the holder before granting/denying access to said content/document

  4. Scott Perry

    In the v1.0 definition of an ecosystem, it states "A community of stakeholders ... forged around a common purpose" I believe that it is too vague and strays from the ToIP objective to secure Internet transaction through the use of verifiable credentials.  In the W3C Data Model the definition of an ecosystem is referred to as "...the roles of the core actors and the relationships between them in an ecosystem where verifiable credentials are expected to be useful." Therefore we should replace "common purpose" with a set of verifiable credentials". 

  5. Steve Magennis

    Great point Scott. The phrase 'common purpose' is probably fine for describing a generic ecosystem, but we are focused on a 'ToIP ecosystem' so it makes a lot of sense that we should articulate some distinction between us and an ecosystem in general.

    I want to float the notion at the risk of igniting a protracted debate, that VCs are a large and important piece of ToIP, but should not be a requirement of a ToIP ecosystem. For example a service using DID:key, DID:peer, DID:uni as a secure and verifiable means of communication without ever issuing, holding or verifying a credential seems like something I think would fall within ToIP.

    I’d like to suggest language along the following lines that certainly include VCs but speaks to the ToIP ecosystem distinction with a stronger emphasis on the ‘why.’

    “A community of [ … ] forged around a common purpose to deliver, consume, or share products and services that leverage trust in cryptography and open protocols to create greater certainty for all participants in the origin, destination and integrity of information transacted and shared over the internet.”

    I think calling out cryptography, open protocols and the internet specifically strikes a good balance between being too specific (e.g. ‘SHA256’) and being overly generalized (e.g. ‘mathematical concepts’) in addressing the ‘how’ and ‘what.’

    I also like the idea of defining the concept of ‘trust at a distance’ as: “greater certainty for all participants in the origin, destination and integrity of information transacted and shared over the internet.”

    Which would collapse the ecosystem definition down to:

    “A community of [ … ] forged around a common purpose to deliver, consume, or share products and services that leverage trust in cryptography and open protocols to enable trust at a distance.”

    btw, I'm a big fan of time boxing healthy discussion and don't want to bog down the process of getting to a workable set of concepts

  6. Karl Kneis

    The proposed definition is intentionally open and inclusive. If the definition is limited to specifications of a data model, DID type, or hinged to specific technical jargon TOIP will provide tactical value to some participants and miss many more that could benefit from it. Many business architectures have no interest in verifiable credentials, DIDs, or cryptography but they all have some idea on the need for digital trust as a core brand principle. If the definition is too tactical or technical we we lose them at the door. Any business concerned with digital trust should have a front door into TOIP.  Any ecosystem can use TOIP and all should consider it.  There is no industry standard for an ecosystem that would cause interpretation conflicts. The framework templates and specifications will provide sufficient alignment with technical and governance objectives of the TOIP mission.