Merge pull request trustoverip#2 from vinomaster/master

Workflow model

UTILITY_LIST.md

@@ -2,7 +2,7 @@
 This document serves as a community list of **Public Identity Utilities**.
 
 ## Getting Started
-See the [Utility Project Lifecycle Management Guide](./UTILITY_WORKFLOW.md).
+See the [Utility Project Lifecycle Management Guide](./workflow/UTILITY_WORKFLOW.md).
 
 ## Utility Directory
 
@@ -14,4 +14,4 @@ See the [Utility Project Lifecycle Management Guide](./UTILITY_WORKFLOW.md).
 | [LSSI](https://lissi.id/) | UNKNOWN | UNKNOWN| TBD |
 | [Germany Main Incubator - Minestry of Economic Affairs](https://main-incubator.com/) | UNKNOWN | UNKNOWN| TBD |
 | [Sovrin MainNet](https://www.sovrin.org/) | Running | [Hyperledger Indy](https://www.hyperledger.org/use/hyperledger-indy)|  [SaturnV]()|
-| [Bedrock Business Utility]() | LF Project Pre-Launch | [Hyperledger Indy](https://www.hyperledger.org/use/hyperledger-indy)|  [SaturnV]()| 
+| [Bedrock Business Utility]() | LF Project Pre-Launch | [Hyperledger Indy](https://www.hyperledger.org/use/hyperledger-indy)|  [SaturnV]()|

workflow/UTILITY_WORKFLOW.md

@@ -0,0 +1,108 @@
+# Utility Project Lifecycle Management
+
+This document provides introductory concepts for  the ToIP Utility Foundry Working Group ("UFWG").
+
+The objective is to help:
+
+* the UFWG members establish a baseline framework for the purpose and scope of the WG.
+* interested public identity utilities ("Utility Projects") begin create and operate a Utility.
+
+Specifically, this document provides a catalyst for the discussion of foundational utility concepts to help the working group develop an initial scope for the establishment and lifecycle management of utilities.
+
+This document addresses four topics:
+
+1. What is a Utility?
+0. What is a Utility Project”?
+0. How would we describe the lifecycle management of a Utility Project?
+0. Provide exemplar stories to help visual the lifecycle management workflow concepts.
+
+## Concepts
+The UFWG needs to establish some foundational
+Ecosystem terms for submission to the ToIP Glossary (See Concepts and Terminology WG). This section provides initial working drafts for several key terms.
+
+### What is a Utility?
+In the context of ToIP, a *Public Identity Utility* ("Utility") refers to an organization that maintains the infrastructure for a public identity verification service. While a Utility will generally be publicly accessible for read access, write access may be restricted by the governance model of the Utility. Utilities may be operated by a consortium of private sector entities, government monopolies or a combination of both.
+
+A ToIP Layer 1 Utility is unique because it requires a community of stakeholders to collaborate on the operation and maintenance of the necessary decentralized infrastructure necessary to provide a public identity verification service. A key aspect of the Utilities infrastructure is interoperable with a  ToIP Layer 2 protocol.
+
+[See proposed Glossary Term](https://github.com/trustoverip/concepts-and-terminology-wg/issues/20.)
+
+### What is a Utility Project
+A formalized collaborative activity, managed by members of a Utility, that leverages ToIP guidance to establish and maintain a public identity verification service.  [See proposed Glossary Term](https://github.com/trustoverip/concepts-and-terminology-wg/issues/21.)
+
+## Utility Foundry Workflow
+The UFWG needs to publish guidance for the lifecycle management of Utility Projects. This guidance must consider:
+
+* Utility Project Requirements
+* Lifecycle Management of a Utility Project
+* Decision Tree Guidance for each lifecycle swim-lane
+
+The following workflow diagram depicts the conceptual swim-lanes of a lifecycle management process for the establishment and maintenance of a Utility Project.
+
+The objective of the UFWG is to expanded each swim-lane into a decision-tree for a variety of process questions/answers.
+
+![swimlanes](./img/workflow-swimlanes.png)
+
+### Learn
+Before prospective stakeholders embark on the creation of a Utility Project, they must first gather some fundamental knowledge about concepts, processes and challenges.
+
+Such education based activity will be an ongoing activity since stakeholders within the Utility Project will come and go.
+
+Initially, key decision topics will include:
+
+1. Why is a *Public Identity Utility* needed by the stakeholders?
+2. Why a legal entity structure is required for a public utility?
+3. What are the differences between legal entity creation approaches (i.e.: Linux Foundation Non-Profit, NGO)
+4. What regulatory compliance, legal, risk mitigation decisions will beed to be considered?
+5. What are the key progress factors that will trigger a decision to convene?
+
+### Convene
+One or more prospective stakeholders will typically emerge as the early convener(s) of a Utility Project. The Convener will help organize an initial set of prospective stakeholders. This group will gather to address some important topics:
+
+1. Why do we need a Utility?
+2. What is unique about the desired Utility?
+3. Who will participate?
+4. What are the common stakeholder motivators?
+5. What are the common stakeholder requirements?
+
+### Define
+Once the prospective stakeholders agree to proceed, the next phase of the process will focus on critical elements such as:
+
+* Articulating the scope of management and how the Utility Project will be governed.
+* Making decisions about DID Methods and ledger technology
+* Documenting sustainability requirements
+* Outlining criteria for the selection of a Utility Service Provider
+
+### Create
+Now the hard work begins! The legal entity that will be the public identity utility needs to be created. This can be done under the umbrella of the Linux Foundation or under the non-profit or  non-government organization (NGO) requirements of a country or region. This new entity will require a governance framework along with any additional legal instruments (contracts) for participating members. Templates and guidance from the ToIP GFWG will be used to aid this activity. The templates will also be used to formalize policies for Utility write-access and budgetary considerations.
+
+### Implement
+A Utility is a key component to ToIP infrastructure. As such, an implementation plan will be established and executed to stand up the Utility. This plan will include:
+
+1. Publishing a governance framework
+2. Onboarding members
+3. Selecting a USP
+4. Aiding members with the selection of node hosting providers
+5. Establishing technical project
+
+### Maintain
+As a public service, the Utility must be monitored for performance and reliability. The stakeholders will need to:
+
+* Accommodate the operation of a number of ledger environments (dev, test, production)
+* Run membership campaigns
+* Monitor USP performance
+
+## Examples
+Our **Utility Foundry Workflow** is a *work-in-progress*. Each workflow step will eventually be expanded into decision tree guidelines. Before we tackle this activity,  further modeling by example should be undertaken by UFWG members. Specifically, we need to:
+
+* Request that volunteers submit example utility  project stories to the ```./stories``` folder using the ```./stories/_stories_template.md```.
+* Solicit feedback on proposed workflow swim-lanes and definitions
+* Expand on the decision points for swim-lane?
+
+### Stories
+As the UFWG refines the * Utility Foundry Workflow Model*, sample descriptive experiences or hypothetical cases will be leveraged by the UFWG to validate our workflow model.
+
+1. [Bedrock Business Utility](./stories/bbu.md)
+
+### Utility Projects
+Refer to the list of [Utility Projects](../UTILITY_LIST.md).

workflow/stories/_stories_template.md

@@ -0,0 +1,43 @@
+## Utility Case Study
+
+| Story Name | Case Study Type |
+| --- | --- |
+| xxxxxxx | Actual - Proposed - Hypothetical|
+
+>Use this table to classify this story as either hypothetical, proposed or actual.
+
+
+### Background Context
+>enter content here
+
+### Pertinent Concepts
+
+>enter content here
+
+### Stakeholders / Persona
+>enter content here
+
+### User Stories
+>enter content here
+
+### Utility Foundry Workflow
+
+![swimlanes](./img/workflow-swimlanes.png)
+
+### Learn
+>enter content here
+
+### Convene
+>enter content here
+
+### Define
+>enter content here
+
+### Create
+>enter content here
+
+### Implement
+>enter content here
+
+### Maintain
+>enter content here

workflow/stories/bbu.md

@@ -0,0 +1,77 @@
+## Utility Case Study
+
+| Story Name | Case Study Type |
+| --- | --- |
+| Bedrock Business Utility | Actual|
+
+>DISCLAIMER: This document represents a hi-;level summation of actual activity. A detailed synopsis of activities will be required to understand actual workflow decisions.
+
+### Background Context
+The Bedrock Consortium is a collection of international private sector companies that operate the Bedrock Business Utility (BBU), an independent self-governed non-profit legal entity that serves as a public identity utility and operates as a self-sustainable directed fund project under The Linux Foundation.
+
+The BBU is intended to serve organizations that desire to participate in digital trust ecosystems and require an enterprise grade governance framework that will:
+
+* Enforce permissioned-writes with contractual instruments that will conform to privacy regulations such as GDPR
+* Maintain financial sustainability of the consortium members without the use of cryptographic tokens
+* Establish a governing board so that no single organization owns the Identity Utility Network
+* Require adherence to specified open standards and protocols
+
+### Pertinent Concepts
+
+* Self-sustainability: Leveraging klessons learned from the [Sovrin Foundation](http://sovrin.org), a business model that was not rooted in philanthropic supported infrastructure must be established.
+* Self-governed: As a decentralized public service provider, the Utility must be governed as a legal entity with a transparanert governing model.
+
+### Stakeholders / Persona
+The following subjects are stakeholders to story:
+
+* Dan (Convener): Digital Identity leader at a large technology company.
+* Christine (Steward): Digital Identity leader at a large consulting firm.
+
+### User Stories
+1. Dan and Christine share common business needs for a public identity utility and decide to collaboratively explore the viability of a Utility.
+2. Dan runs an exploratory campaign with industry competitors and clients to identify prospective stakeholders in a consortium.
+3. Dan convenes a working group, represented by sponsoring businesses, to establish a governance framework.
+4. The Working Group runs a RFP Process to help validate budgetary requirements and the selection of a Utility Service Provider ("USP").
+5. The Working Group collaborates with the Linux Foundation on the establishment of a *LF Governance Network, Inc*.
+6. The Working Group formalizes the launch of a Utility.
+
+### Utility Foundry Workflow
+
+![swimlanes](./img/workflow-swimlanes.png)
+
+### Learn
+
+* While Dan and Christine had an operational understanding of how a Utility would work, then=y needed to educate prospective stakeholders.
+* Clients of Dan and Christine shared a common need - a trusted and enterprise reliable utility service for identify verification that was easy to maintain and use. They desired a minimum viable utility ("MVU")
+* The employers of Dan and Christine did not desire to own and operate the Utility, they desired a non-profit and open solution.
+4. Both stakeholder companies were deeply concerned about GDPR/CCPA privacy risks associated with participation in such a Utility from an infrastructure perspective.
+5. Dan and Christine agreed the requirements for convening project would be to get 5-10 companies to provide (a) an executive sponsor willing to be a board member if the Utility materialized; (b) a working group resource willing to work on the creation of a governance framework.
+
+### Convene
+The Bedrock Consortium was informally formed with representatives from nine (9) prospective companies. The identification of these prospective nine required numerous emails and educational sessions to establish interest and identify common requirements.
+
+The Bedrock Consortium established a Governance Framework Working Group ("GFWG") with Dan as the Convener.
+
+### Define
+Using the [Sovrin Governance Framework](https://sovrin.org/library/sovrin-governance-framework/) and a model, the GFWG collaborated on the:
+
+* Creation of an online governance framework that can be easily navigated and maintained via GitHub
+* Articulation of scope of management and how the Utility Project will be governed using proven  Linux Foundation open source project models.
+* Decided on the use of Hyperledger Indy as the ledger technology
+* Accepted the contribution of a BBU specific DID Method (```did:bbu```)
+* Modeled budgetary sustainability requirements for a MVU of 25 Stewards growing no larger than 60 Stewards.
+* Outlining criteria for the selection of a Utility Service Provider.
+
+### Create
+* Published the BBU Governance Framework (a living document)
+* Working with the Linux Foundation to launch the Utility Project:
+    * Created a *Briefing Package* to be used to solicit Bedrock Consortium members.
+    * Run exploratory member invitation sessions
+    * Created the Bedrock Technical Project
+* Ran a RFP Process for a USP.  
+
+### Implement
+TBD
+
+### Maintain
+TBD