diff --git a/docs/governance/business/digital-business-card/DBC-cred-doc-v1.md b/docs/governance/business/digital-business-card-v1.md similarity index 100% rename from docs/governance/business/digital-business-card/DBC-cred-doc-v1.md rename to docs/governance/business/digital-business-card-v1.md diff --git a/docs/governance/business/index.md b/docs/governance/business/index.md new file mode 100644 index 00000000..9dd2daad --- /dev/null +++ b/docs/governance/business/index.md @@ -0,0 +1,8 @@ +--- +sidebar_position: 3 +description: Business +--- + +# Business Ecosystem + +* [BC Digital Business Card v1](./digital-business-card-v1.md) diff --git a/docs/governance/index.md b/docs/governance/index.md index 7c83079e..007e4c49 100644 --- a/docs/governance/index.md +++ b/docs/governance/index.md @@ -1,7 +1,9 @@ --- -order: 5 sidebar_position: 1 description: Governance Framework Documentation Repository --- # Governance +Use the menu on the left to navigate through the governance frameworks. You can also use the Search function (Ctrl+K) to search for a relevent term. + +BC Government uses the CANdy Network for some digital trust functionality and adheres to this [CANdy Governance Framework](https://iccs-isac.github.io/Gouvernance-CICN-ICDT-Governance/). diff --git a/docs/governance/mining/index.md b/docs/governance/mining/index.md index 566c69bb..946fef91 100644 --- a/docs/governance/mining/index.md +++ b/docs/governance/mining/index.md @@ -1,6 +1,5 @@ --- -order: 5 -sidebar_position: 1 +sidebar_position: 4 description: Mining --- diff --git a/docs/governance/person/index.md b/docs/governance/person/index.md new file mode 100644 index 00000000..598958f0 --- /dev/null +++ b/docs/governance/person/index.md @@ -0,0 +1,8 @@ +--- +sidebar_position: 2 +description: Person +--- + +# Person Ecosystem + +* [BC Person Credential](./person-cred-doc.md) diff --git a/docs/governance/government/person-cred-doc.md b/docs/governance/person/person-cred-doc.md similarity index 100% rename from docs/governance/government/person-cred-doc.md rename to docs/governance/person/person-cred-doc.md diff --git a/docs/resources/bc-vcpedia/credentials/_pilots/EO100.md b/docs/governance/pilots/EO100.md similarity index 99% rename from docs/resources/bc-vcpedia/credentials/_pilots/EO100.md rename to docs/governance/pilots/EO100.md index c27bb7e0..a95fe8c7 100644 --- a/docs/resources/bc-vcpedia/credentials/_pilots/EO100.md +++ b/docs/governance/pilots/EO100.md @@ -1,7 +1,5 @@ --- -layout: default title: EO100™ Certification -parent: Credentials --- # EO100™ Certification Statement Credential - Draft diff --git a/docs/governance/pilots/_index.md b/docs/governance/pilots/_index.md deleted file mode 100644 index 8b013d6a..00000000 --- a/docs/governance/pilots/_index.md +++ /dev/null @@ -1 +0,0 @@ -# Index diff --git a/docs/resources/bc-vcpedia/credentials/_pilots/bc-business-registration.md b/docs/governance/pilots/bc-business-registration.md similarity index 67% rename from docs/resources/bc-vcpedia/credentials/_pilots/bc-business-registration.md rename to docs/governance/pilots/bc-business-registration.md index 875f37bd..f773e660 100644 --- a/docs/resources/bc-vcpedia/credentials/_pilots/bc-business-registration.md +++ b/docs/governance/pilots/bc-business-registration.md @@ -1,19 +1,15 @@ --- -layout: default title: Governance for Business Registration -parent: Credentials --- Governance for Business Registration Credential (Level 3 according to TrustOverIP Governance model) -Registered Issuers in -|Name|Issuer did| -|---|---| -|BC OrgBook|??| -|BC Registries|??| - "identifiers": [ +``` +"identifiers": [ { "schema_id": "HR6vs6GEZ8rHaVgjg2WodM:2:registration.registries.ca:1.0.42", "cred_def_id": "HR6vs6GEZ8rHaVgjg2WodM:3:CL:41051:tag" } +] +``` \ No newline at end of file diff --git a/docs/resources/bc-vcpedia/applications/_pilots/bc-business-registries.md b/docs/governance/pilots/bc-business-registries.md similarity index 94% rename from docs/resources/bc-vcpedia/applications/_pilots/bc-business-registries.md rename to docs/governance/pilots/bc-business-registries.md index e51a14c7..197e75a9 100644 --- a/docs/resources/bc-vcpedia/applications/_pilots/bc-business-registries.md +++ b/docs/governance/pilots/bc-business-registries.md @@ -1,7 +1,5 @@ --- -layout: default title: Governance for BC Business Registries application (Level 4 according to TrustOverIP Governance model) -parent: Applications --- Governance for BC Business Registries application (Level 4 according to TrustOverIP Governance model) diff --git a/docs/resources/bc-vcpedia/applications/_pilots/bc-climate-action-secretariat.md b/docs/governance/pilots/bc-climate-action-secretariat.md similarity index 99% rename from docs/resources/bc-vcpedia/applications/_pilots/bc-climate-action-secretariat.md rename to docs/governance/pilots/bc-climate-action-secretariat.md index e2c357bf..f09fb2a4 100644 --- a/docs/resources/bc-vcpedia/applications/_pilots/bc-climate-action-secretariat.md +++ b/docs/governance/pilots/bc-climate-action-secretariat.md @@ -1,7 +1,5 @@ --- -layout: default title: BC Climate Action Secretariat (CAS) Governance Framework - Draft -parent: Applications --- ## BC Climate Action Secretariat (CAS) Governance Framework - Draft diff --git a/docs/resources/bc-vcpedia/applications/_pilots/bc-ghg-emissions-verification.md b/docs/governance/pilots/bc-ghg-emissions-verification.md similarity index 99% rename from docs/resources/bc-vcpedia/applications/_pilots/bc-ghg-emissions-verification.md rename to docs/governance/pilots/bc-ghg-emissions-verification.md index b906661e..9c6a88b0 100644 --- a/docs/resources/bc-vcpedia/applications/_pilots/bc-ghg-emissions-verification.md +++ b/docs/governance/pilots/bc-ghg-emissions-verification.md @@ -1,7 +1,5 @@ --- -layout: default title: BC Climate Action Secretariat Ecosystem Governance Framework -parent: Applications --- ## Title: application-bc-ghg-emissions-verification.md diff --git a/docs/resources/bc-vcpedia/applications/_pilots/equitable-origin.md b/docs/governance/pilots/equitable-origin.md similarity index 99% rename from docs/resources/bc-vcpedia/applications/_pilots/equitable-origin.md rename to docs/governance/pilots/equitable-origin.md index 5e377bb9..b18a4539 100644 --- a/docs/resources/bc-vcpedia/applications/_pilots/equitable-origin.md +++ b/docs/governance/pilots/equitable-origin.md @@ -1,7 +1,5 @@ --- -layout: default title: Equitable Origin Governance Framework -parent: Applications --- ## Equitable Origin Governance Framework diff --git a/docs/governance/pilots/index.md b/docs/governance/pilots/index.md new file mode 100644 index 00000000..1752576c --- /dev/null +++ b/docs/governance/pilots/index.md @@ -0,0 +1,7 @@ +--- +sidebar_position: 1 +description: Pilots +--- + +# Pilots +These are governance frameworks either in a pilot test or under development. diff --git a/docs/resources/bc-vcpedia/credentials/_pilots/qube-report.md b/docs/governance/pilots/qube-report.md similarity index 99% rename from docs/resources/bc-vcpedia/credentials/_pilots/qube-report.md rename to docs/governance/pilots/qube-report.md index 52c8de87..fa905df1 100644 --- a/docs/resources/bc-vcpedia/credentials/_pilots/qube-report.md +++ b/docs/governance/pilots/qube-report.md @@ -1,7 +1,5 @@ --- -layout: default title: Qube Monthly Report Primary Governance -parent: Credentials --- # Qube Monthly Report Primary Governance Document diff --git a/docs/governance/pilots/tenure-branch/_category_.yml b/docs/governance/pilots/tenure-branch/_category_.yml deleted file mode 100644 index c3b0c9a3..00000000 --- a/docs/governance/pilots/tenure-branch/_category_.yml +++ /dev/null @@ -1,3 +0,0 @@ -link: - type: 'doc' - id: 'governance/pilots/tenure-branch/governance' diff --git a/docs/resources/bc-vcpedia/applications/_application-bc-mds.md b/docs/resources/bc-vcpedia/applications/_application-bc-mds.md deleted file mode 100644 index 19ff005f..00000000 --- a/docs/resources/bc-vcpedia/applications/_application-bc-mds.md +++ /dev/null @@ -1,200 +0,0 @@ -# BC Mines Digital Services Governance Framework - DRAFT - -# 1. Primary Document - -## 1.1 Introduction - -This document articulates the governance framework for BC Mines Digital Services (MDS) as a participant of the open global community that exchanges verifiable credentials [(layer four application of the Trust Over IP Foundation (ToIP) model)](https://www.trustoverip.org/wp-content/toip-model/) - -The development of this documentation follows the governance framework created by the [Trust over IP Foundation (ToIP)](https://trustoverip.org/) [Governance Metamodel Specification](https://trustoverip.org/wp-content/uploads/ToIP-Governance-Metamodel-Specification-V1.0-2022-12-21.pdf) created by the [Governance Stack Working Group (GSWG)](https://wiki.trustoverip.org/display/HOME/Governance+Stack+Working+Group). - -These materials are made available under and are subject to the [Creative Commons Attribution 4.0 International license](http://creativecommons.org/licenses/by/4.0/legalcode). - -THESE MATERIALS ARE PROVIDED “AS IS.” The Trust Over IP Foundation, established as the Joint Development Foundation Projects, LLC, Trust Over IP Foundation Series ("ToIP"), and its members and contributors (each of ToIP, its members and contributors, a "ToIP Party") expressly disclaim any warranties (express, implied, or otherwise), including implied warranties of merchantability, non-infringement, fitness for a particular purpose, or title, related to the materials. The entire risk as to implementing or otherwise using the materials is assumed by the implementer and user. - -IN NO EVENT WILL ANY ToIP PARTY BE LIABLE TO ANY OTHER PARTY FOR LOST PROFITS OR ANY FORM OF INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES OF ANY CHARACTER FROM ANY CAUSES OF ACTION OF ANY KIND WITH RESPECT TO THESE MATERIALS, ANY DELIVERABLE OR THE ToIP GOVERNING AGREEMENT, WHETHER BASED ON BREACH OF CONTRACT, TORT (INCLUDING NEGLIGENCE), OR OTHERWISE, AND WHETHER OR NOT THE OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. - -***Acknowledgements*** - -This governance framework includes structural elements from the Trust over IP Metamodel that were developed by Governance Stack Working Group of the Trust over IP Foundation, the eSSIF Lab Glossary and Mental Models, were contributed to the Trust Over IP Foundation under the CC BY-SA 4.0 license. There have also been contributions from the Concepts & Terminology Working Group at ToIP, the Human Experience Working Group at ToIP and the Ecosystem Foundry Working Group at ToIP, the work of the Governance Framework Working Group at Sovrin Foundation is also acknowledged in providing support. -## 1.2. Terminology and Notation - -Please reference [Glossary - General Trust Over IP Terms](https://trustoverip.github.io/toip/glossary). - -**Requirements** include any combination of Machine-Testable Requirements and Human-Auditable Requirements. Unless otherwise stated, all Requirements MUST be expressed as defined in [RFC 2119](https://www.rfc-editor.org/rfc/rfc2119). - -- Mandates are Requirements that use a MUST, MUST NOT, SHALL, SHALL NOT or REQUIRED keyword. -- Recommendations are Requirements that use a SHOULD, SHOULD NOT, or RECOMMENDED keyword. -- Options are Requirements that use a MAY or OPTIONAL keyword. - -**Machine-Testable Requirements** are those with which compliance can be verified using an automated test suite and appropriate scripting or testing software. - -**Rules** are Machine-Testable Requirements that are written in a Machine-Readable language and can be processed by a Rules Engine. They are expressed in a structured rules language as specified by the Governance Framework. - -**Human-Auditable Requirements** are those with which compliance can only be verified by an audit of people, processes, and procedures. - -**Policies** are Human-Auditable Requirements written using standard conformance terminology. The Policies used in the Governance Framework will use the standard terminology detailed in RFC 2119 keywords. Note that all RFC 2119 keywords have weight from an auditing perspective. An implementer MUST explain why a SHOULD or RECOMMENDED requirement was not implemented and SHOULD explain why a MAY requirement was implemented. - -**Specifications** are documents containing any combination of Machine-Testable Requirements and Human-Auditable Requirements needed to produce technical interoperability. - -## 1.3. Localization - -The standard language for this governing framework (GF) is English. - -## 1.4 Governing Authority - -[Mines Digital Services (MDS)](https://digital.gov.bc.ca/learning/case-studies/monitoring-mining-operations-in-bc/) is the governing authority responsible for this Governance Framework (GF). The contact information for Mines Digital Services during the pilot phase of development is - -* **Name:** Rebecca Stevenson -* **Title:** Product Owner -* **Organization:** Mines Digital Services -* **Email:** rebecca.stevenson@gov.bc.ca - -## 1.5. Administering Authority - -[Energy and Mines Digital Trust (EMDT)](https://digital.gov.bc.ca/case-studies/emdt) is the Administering Authority on behalf of The Major Mines Office (MMO) during the pilot phase of development. - -The contact information for EMDT is: -* **Name:** Kyle Robinson -* **Title:** Senior Strategic Advisor, Digital Trust Ecosystems -* **Organization:** Briartech Consulting Inc. -* **Email:** [kyle.robinson@briartech.ca](mailto:kyle.robinson@briartech.ca) - -## 1.6 Purpose - -The purpose of this governance framework is to describe the rules/policies/procedures for verifiable credential exchanges involving (MDS)](https://digital.gov.bc.ca/learning/case-studies/monitoring-mining-operations-in-bc/) with the open global community. The purpose of the rules is to enable all actors to understand agreed upon standards, terminology and processes that allow the community to interact with MMO in a trusted manner. - -## 1.7 Scope - -(MDS)](https://digital.gov.bc.ca/learning/case-studies/monitoring-mining-operations-in-bc/) is a participant in an open ecosystem and the focus of this framework is to describe the process MMO uses for digital exchanges on Indy networks. - -## 1.8 Objectives - -1) To develop a governance framework outlining legislation, administrative processes, and criteria for credentials issued by the MMO within British Columbia. -2) Develop, modernize and improve aspects of the current Mines Act Permitting Process. -3) Support digital business interaction/automation within the BC Mine Permitting Process ecosystem. - -## 1.9 Principles - -[The BC Public Service](https://www2.gov.bc.ca/gov/content/careers-myhr/about-the-bc-public-service/ethics-standards-of-conduct/corporate-values) has one overarching corporate value, __Integrity__, and 6 core corporate values: Curiosity, Service, Passion, Teamwork, Accountability, and Courage. __Integrity__ is placed above all the other values as a quality that affirms the [Standards of Conduct for the BC Public Service](https://www2.gov.bc.ca/gov/content/careers-myhr/about-the-bc-public-service/ethics-standards-of-conduct/standards-of-conduct). - -## 1.10 General Requirements -MDS updates and manages this credential governance framework. -Legislation and regulations govern the disposition, administration and management of mines in BC. These can be found in [The Mines Act](https://www.bclaws.gov.bc.ca/civix/document/id/complete/statreg/96293_01). - -- **[BC Mine Information](https://mines.nrs.gov.bc.ca/)** -- **[BC Mine Authorizations](https://mines.nrs.gov.bc.ca/authorizations)** -- (MDS)](https://digital.gov.bc.ca/learning/case-studies/monitoring-mining-operations-in-bc/) - -## 1.11. Revisions - -Version 1.0. - -## 1.12. Extensions - -There are no extensions to this Governance Framework. - -## 1.13. Schedule of Controlled Documents - -TBD - -# 2. Controlled Documents - -## 2.1. Glossary -[ToIP Core Glossary](https://trustoverip.github.io/toip/glossary) - -[BC Mines Act Definitions](https://www.bclaws.gov.bc.ca/civix/document/id/complete/statreg/96293_01#section1) - -* **Credential Holders**: These are the mining operators within BC -* **Major Mines**: Moderate- to large- scale mineral and coal mining operations, including sand and gravel pits, quarries, and placer mines. -* **Coordinated Authorizations** are referred by the Chief Permitting Officer (CPO) to manage projects that require multiple permits – for example, a Mines Act permit to construct and operate an outfall and an [EMA (Environmental Management Act)](https://www.bclaws.gov.bc.ca/civix/document/id/complete/statreg/03053_01) permit to discharge from it. There are three different routes for a project to come into the coordinated -authorizations process: - 1. Any new mineral or coal mine project, whether or not reviewable under the [Environmental -Assessment Act (EAA)](https://www2.gov.bc.ca/gov/content/environment/air-land-water/water/laws-rules/environmental-assessment-act); - 2. A mine project that is an extension, expansion, or re-start requiring multiple -authorizations; - 3. Any project that the CPO determines would benefit from the coordinated authorizations -process due to its complexity. -* **Major Mines Office (MMO)** All construction and operations permit applications for coal and mineral mines are managed by the Ministry's Major Mines Office (MMO) and must be submitted through the MMO’s intake email permrecl@gov.bc.ca. -* **Mine Manager** the person authorized to act on behalf of the mine operations. This person is responsible for secure access to MineSpace portal. -* **Mines Digital Services (MDS)** System designed for easier access for the public, industry and government to see what's happening in the mining industry across British Columbia. -* **MineSpace** A part of the MDS system, developed specifically for industry. It is intended to make it easier for businesses to manage applications, see their inspection history and submit reports. -* **CORE** A central digital repository for all major mine record information. - -## 2.2. Risk Assessment -[The Major Mines Office (MMO)](https://mines.nrs.gov.bc.ca/authorizations) is the the primary authority for determining management of risk assessment. - -## 2.3. Trust Assurance and Certification -[The Major Mines Office (MMO)](https://mines.nrs.gov.bc.ca/authorizations) is governed by standards and assurances outlined under [The Mines Act](https://www.bclaws.gov.bc.ca/civix/document/id/complete/statreg/96293_01) - -## 2.4. Governance Requirements -Governance Requirements stem from the [The Major Mines Office (MMO)](https://mines.nrs.gov.bc.ca/authorizations) - -## 2.5. Business Requirements - -## 2.5.1. Establishment of Connection - -1. The Mine Manager of the interested mining company MUST access the MineSpace portal in order to request a single-use invitation link to connect (*note, trust assurance is based on the process the Mine Manager must follow in order to access MineSpace portal - includes BCeID, etc*.) -2. The Mine Manager MUST select the option to request an invitation link from the MineSpace portal homepage for the required mining company (not for the mine site, this is the organizational link). Backend note - MineSpace MUST send the invitation request to Traction in order to generate a single-use invitation link. Traction MUST return the invitiation link to MineSpace, the invitation link WILL display within the MineSpace homescreen. -3. MineSpace MUST return the invitation link to the mining company's homepage. -4. The Mine Manager MUST use the invitation link provided within their organizational wallet in order to establish a secure connection. -5. Traction MUST send/request? approval notification to CORE (*further discussion required*) - -## 2.5.2. Major Mines Operating Permit - Digital Credential Request (Existing) -When mining operators wish to obtain a BC Mines Act Permit in BC, they must adhere to the [Mines Act Permiting Process](https://mines.nrs.gov.bc.ca/authorizations). The Mines Act permitting process includes on-site activities, such as the management of water quality, waste and metal leaching and acid rock drainage at the mine, as well as, geotechnical design and reclamation and closure planning. - -1. Using the established connection, MDS CORE MUST offer the credential when a new permit and/or amendment is issued (if the connection exists). -2. For all connections, MDS CORE MUST offer [permit credentials](https://github.com/bcgov/bc-vcpedia/blob/main/credentials/credential-bc-mines-act-permit.md) that have not been offered before. -3. MDS MineSpace MUST provide an Activity Feed Notification for each credential offer to the Mine Manager. -4. MDS CORE MUST provide an activity feed notification for each credential to the Mining Inspector. -5. MDS Traction SHALL offer the credential to the Company’s Organizational Wallet. -6. The Company’s Organizational Wallet SHALL send an email notification of offer to the Mine Manager through secure email. -7. The Mine Manager MUST read and respond to the email notification. -8. The Mine Manager MUST review the credential offer and accept the credential into their Organizational Wallet -9. The Organizational Wallet MUST display offer details to the Mine Manager. -10. The Mine Manager MUST either Accept/Decline the offer. -11. Organizational Wallets MAY display a problem report if the credential is declined. -12. MDS Traction MUST notify MDS CORE-BC Gov if the offer is declined. -13. MDS CORE-BC Gov MUST provide an Activity Feed Notification for Declined Offer to the Mining Inspector. - - -## 2.5.3. Major Mines Operating Permit Application - Current Process - -[The Coordinated Authorizations Process](https://www2.gov.bc.ca/gov/content/industry/mineral-exploration-mining/permitting/coordinated-authorizations/mines-process#:~:text=The%20coordinated%20authorizations%20process%20is,detailed%20information%20on%20the%20process.) is defined by four overarching stages: pre-application, screening, review, drafting and decision. - -There are three different routes for a project to come into the Coordinated Authorizations Process: -- Any new mineral or coal mine project, whether or not reviewable under the [Environmental Assessment Act (EAA)](https://www2.gov.bc.ca/gov/content/environment/air-land-water/water/laws-rules/environmental-assessment-act); -- A mine project that is an extension, expansion, or re-start requiring multiple authorizations; -- Any project that the CPO determines would benefit from the Coordinated Authorizations Process due to its complexity. - -1. A project that meets the above criteria MUST conduct introductions and engagements among the proponent, Provincial Staff, Indigenous Nations and other potentially impacted groups. -2. A project MAY be referred to the Coordinated Authorizations Process by the Chief Permitting Officer (CPO) after step 1 is complete if deemed necessary after introductions and engagements. -3. All Coordinated Authorizations MUST be managed by the [EMLI Major Mines Office (MMO)](https://mines.nrs.gov.bc.ca/authorizations). -4. Mines Act Permit Applications that are particularly complex MUST be referred to an advisory committee made up of Provincial staff, Indigenous nations, and other potentially impacted groups through a [Mine Review Committee](https://www2.gov.bc.ca/gov/content/industry/mineral-exploration-mining/permitting/coordinated-authorizations/mine-mrc) (MRC) by the CPO as part of the Coordinated Authorizations Process. -5. Application MUST be formally submitted to indigenous nations for review. -6. The MRC MAY subject the application to public engagement activities if required. -7. The MRC MUST provide recommendations to SDMs (Statutory Decision Makers) to support the decision-making process. The intended outcome of the coordinated authorizations process is durable decisions that reflect the interests of all parties involved. -8. Complex projects MUST be coordinated by an EMLI project lead and follow a structured permitting process. -9. Reports and draft permits MUST be prepared and reviewed by the proponent and MRC. - - -## 2.6. Technical Requirements (Credential) -*MUST have an Hyperledger Aries compatible business wallet.* - -## 2.7. Information Trust Requirements - -The [Freedom of Information and Protection of Privacy Act](https://www.bclaws.gov.bc.ca/civix/document/id/complete/statreg/96165_00) sets out the access and privacy rights of individuals as they relate to the public sector in British Columbia. - -## 2.8. Inclusion, Equitability, and Accessibility Requirements - -The [Accessible British Columbia Act](https://www.bclaws.gov.bc.ca/civix/document/id/complete/statreg/21019) informs [**AccessibleBC**](https://www2.gov.bc.ca/gov/content/governments/about-the-bc-government/accessibility/legislation/accessiblebc) - -The [Diversity & Inclusion Strategy for the BC Public Service](https://www2.gov.bc.ca/gov/content/careers-myhr/about-the-bc-public-service/diversity-inclusion/diversity-inclusion-strategy) outlines the committments of BC govenment in supporting inclusion, equitability and access throughout the province. - -The [Declaration on the Rights of Indigenous Peoples Act (Declaration Act)](https://www.bclaws.gov.bc.ca/civix/document/id/complete/statreg/19044) establishes the United Nations Declaration on the Rights of Indigenous Peoples (UN Declaration) as BC’s framework for reconciliation that respects the human rights of Indigenous Peoples. - -## 2.9. Legal Agreements -TBD - -# End of Document - diff --git a/docs/resources/bc-vcpedia/applications/_pilots/PwC.md b/docs/resources/bc-vcpedia/applications/_pilots/PwC.md deleted file mode 100644 index 5f255a74..00000000 --- a/docs/resources/bc-vcpedia/applications/_pilots/PwC.md +++ /dev/null @@ -1,160 +0,0 @@ ---- -layout: default -title: PricewaterhouseCoopers (PwC) Governance Framework -parent: Applications ---- - -## PricewaterhouseCoopers (PwC) Governance Framework - -# 1. Primary Document - -## 1.1. Introduction - -This document articulates the governance framework for PricewaterhouseCoopers (PwC) as an actor involved in the verifiable credential exchanges [(layer four application of the Trust Over IP Foundation (ToIP) model)](https://www.trustoverip.org/wp-content/toip-model/). - -The development of this documentation follows the governance framework created by the [Trust over IP Foundation (ToIP)](https://trustoverip.org/) [Governance Metamodel Specification](https://trustoverip.org/wp-content/uploads/ToIP-Governance-Metamodel-Specification-V1.0-2022-12-21.pdf) created by the [Governance Stack Working Group (GSWG)](https://wiki.trustoverip.org/display/HOME/Governance+Stack+Working+Group). - -These materials are made available under and are subject to the [Creative Commons Attribution 4.0 International license](http://creativecommons.org/licenses/by/4.0/legalcode). - -THESE MATERIALS ARE PROVIDED “AS IS.” The Trust Over IP Foundation, established as the Joint Development Foundation Projects, LLC, Trust Over IP Foundation Series ("ToIP"), and its members and contributors (each of ToIP, its members and contributors, a "ToIP Party") expressly disclaim any warranties (express, implied, or otherwise), including implied warranties of merchantability, non-infringement, fitness for a particular purpose, or title, related to the materials. The entire risk as to implementing or otherwise using the materials is assumed by the implementer and user. - -IN NO EVENT WILL ANY ToIP PARTY BE LIABLE TO ANY OTHER PARTY FOR LOST PROFITS OR ANY FORM OF INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES OF ANY CHARACTER FROM ANY CAUSES OF ACTION OF ANY KIND WITH RESPECT TO THESE MATERIALS, ANY DELIVERABLE OR THE ToIP GOVERNING AGREEMENT, WHETHER BASED ON BREACH OF CONTRACT, TORT (INCLUDING NEGLIGENCE), OR OTHERWISE, AND WHETHER OR NOT THE OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. - -***Acknowledgements*** - -This governance framework includes structural elements from the Trust over IP Metamodel that were developed by Governance Stack Working Group of the Trust over IP Foundation, the eSSIF Lab Glossary and Mental Models, were contributed to the Trust Over IP Foundation under the CC BY-SA 4.0 license. There have also been contributions from the Concepts & Terminology Working Group at ToIP, the Human Experience Working Group at ToIP and the Ecosystem Foundry Working Group at ToIP, the work of the Governance Framework Working Group at Sovrin Foundation is also acknowledged in providing support. - -## 1.2. Terminology and Notation - -[Glossary - General Trust Over IP Terms](https://trustoverip.github.io/toip/glossary) - -**Requirements** include any combination of Machine-Testable Requirements and Human-Auditable Requirements. Unless otherwise stated, all Requirements MUST be expressed as defined in [RFC 2119](https://www.rfc-editor.org/rfc/rfc2119). - -- Mandates are Requirements that use a MUST, MUST NOT, SHALL, SHALL NOT or REQUIRED keyword. -- Recommendations are Requirements that use a SHOULD, SHOULD NOT, or RECOMMENDED keyword. -- Options are Requirements that use a MAY or OPTIONAL keyword. - -**Machine-Testable Requirements** are those with which compliance can be verified using an automated test suite and appropriate scripting or testing software. - -**Rules** are Machine-Testable Requirements that are written in a Machine-Readable language and can be processed by a Rules Engine. They are expressed in a structured rules language as specified by the Governance Framework. - -**Human-Auditable Requirements** are those with which compliance can only be verified by an audit of people, processes, and procedures. - -**Policies** are Human-Auditable Requirements written using standard conformance terminology. The Policies used in the Governance Framework will use the standard terminology detailed in RFC 2119 keywords. Note that all RFC 2119 keywords have weight from an auditing perspective. An implementer MUST explain why a SHOULD or RECOMMENDED requirement was not implemented and SHOULD explain why a MAY requirement was implemented. - -**Specifications** are documents containing any combination of Machine-Testable Requirements and Human-Auditable Requirements needed to produce technical interoperability. - -## 1.3. Localization -The standard language for this Governance Framework (GF) is American English. - -## 1.4. Governing Authority - -[PricewaterhouseCoopers (PwC)](https://www.pwc.com/ca/en/) is the Governing Authority responsible for this Governance Framework (GF). -The contact information for PwC during the pilot phase of development is: -* **Name:** Naomi Thomas -* **Title:** Senior Manager, Sustainability and Climate Change -* **Organization:** PricewaterhouseCoopers LLP -* **Email:** [naomi.thomas@pwc.com](mailto:naomi.thomas@pwc.com) - -## 1.5. Administering Authority - -[Energy and Mines Digital Trust (EMDT)](https://digital.gov.bc.ca/case-studies/emdt) is the Administering Authority on behalf of PricewaterhouseCoopers (PwC) during the pilot phase of development. - -The contact information for EMDT is: -* **Name:** Kyle Robinson -* **Title:** Senior Strategic Advisor, Digital Trust Ecosystems -* **Organization:** Briartech Consulting Inc. -* **Email:** [kyle.robinson@briartech.ca](mailto:kyle.robinson@briartech.ca) - -## 1.6. Purpose - -The purpose of this governance framework is to describe the rules/policies/procedures for verifiable credential exchanges involving PricewaterhouseCoopers (PwC) Services Inc. with the open global community. The purpose of the rules is to enable all actors to understand agreed upon standards, terminology and processes that allow the community to interact with PwC in a trusted manner. This will help determine a governing framework and operating model for a global ecosystem that identifies how credentials can be issued, held, and verified. - -## 1.7. Scope - -PricewaterhouseCoopers (PwC) is a participant in an open ecosystem and the focus of this framework is to describe the process PwC uses for digital exchanges on Indy networks. - -## 1.8. Objectives - -_This section states the high-level outcomes desired by the trust community through its adoption of the GF._ - -1. SHOULD specify tangible, achievable results (e.g. SMART criteria and Fit-for-Purpose criteria). -2. MUST only contain outcomes over which the GF has the authority and mechanisms to achieve within its -scope. -3. MUST be consistent with the principles of the GF (below). - -## 1.9. Principles - -See [PricewaterhouseCoopers (PwC) Values](https://www.pwc.com/gx/en/about/purpose-and-values.html) - -## 1.10. General Requirements -TBD - -## 1.11. Revisions - -Version 1.0 - -_TBD - How and when PricewaterhouseCoopers (PwC) would change governance framework_ - -## 1.12. Extensions - -There are no extensions to this Governance Framework. - -## 1.13. Schedule of Controlled Documents - -TBD - -# 2. Controlled Documents - -## 2.1. Glossary - - -## 2.2. Risk Assessment - -TBD - -## 2.3. Trust Assurance and Certification - -TBD - -## 2.4. Governance Requirements - -TBD - -## 2.5. Business Requirements - -### 2.5.1. Establishing connections - -1. PricewaterhouseCoopers (PwC) MUST send an invitation to the other business entity via email to initiate the exchange of information. -2. The receiving party MUST accept invitation in order to establish a secure connection. - -### 2.5.2. Issuance of Third-party GHG Verification Statement - -1. Using the established connection, PwC MUST receive a credential request from the business entity. -2. Continuing from step 1, the business entity will provide the following attributes from the [BC GHG Emissions Report Verification Statement Credential Governance](https://github.com/bcgov/bc-vcpedia/blob/main/credentials/credential-bc-ghg-emissions-verification.md#261-schema-definition) in the credential request: - -reporting_operation, name_of_facility, facility_type, facility_address, facility_longitude, facility_latitude, total_emissions, total_emissions_not_reporting_only, total_emissions_reporting_only, total_co2_from_nonbiomass, total_co2_from_nonbiomass_not_schedule_c, total_co2_from_nonbiomass_in_schedule_c - -3. PwC will receive and review the request -4. Any clarification questions can be asked via the secure messaging function -5. Once all data is entered and correct, PwC will offer the credential to the business entity - -## 2.6. Technical Requirements - -*MUST have an Hyperledger Aries compatible business wallet.* - -## 2.7. Information Trust Requirements - -[PwC's Code of Conduct](https://www.pwc.com/gx/en/about/ethics-business-conduct/code-of-conduct.html#:~:text=We%20take%20appropriate%20measures%20to,%2C%20bullying%2C%20or%20disrespectful%20behaviour.) - -[PwC's Privacy Commitment](https://www.pwc.com/ca/en/privacy-policy.html#:~:text=We%20will%20always%20collect%20your,otherwise%20permitted%20by%20applicable%20law.) - -## 2.8. Inclusion, Equitability and Accessibility Requirement - -TBD - -## 2.9. Legal Agreements - -TBD - -# End of Document diff --git a/docs/resources/bc-vcpedia/applications/_pilots/bc-cas.md b/docs/resources/bc-vcpedia/applications/_pilots/bc-cas.md deleted file mode 100644 index 58d2c39e..00000000 --- a/docs/resources/bc-vcpedia/applications/_pilots/bc-cas.md +++ /dev/null @@ -1,291 +0,0 @@ ---- -layout: default -title: BC CAS Governance Framework - Draft -parent: Applications ---- - -## BC Climate Action Secretariat (CAS) Governance Framework - Draft - -# Primary Document - -## Introduction - -The Climate Action Secretariat (CAS), within the BC Ministry of Environment, drives change to achieve British Columbia's greenhouse gas emission reduction targets. The Climate Action Secretariat Verifiable Credentials Ecosystem Governance Framework is a Layer Four Ecosystem Governance Framework of the Trust Over IP Foundation (ToIP). The CAS GHG Emissions Identifier is used as a key component in building a trust layer for identification and verification of GHG emissions that require accounting. The CAS Carbon Intensity Identifier establishes a separate key component in building a trust layer for identification and verification of Carbon Intensity accounting. The Ecosystem will assist in the development of the CAS __________________ Credential Pilot Project. - -## Terms of Use - -These materials are made available under and are subject to the Creative Commons Attribution 4.0 International license (http://creativecommons.org/licenses/by/4.0/legalcode). - -THESE MATERIALS ARE PROVIDED “AS IS.” The Trust Over IP Foundation, established as the Joint Development Foundation Projects, LLC, Trust Over IP Foundation Series ("ToIP"), and its members and contributors (each of ToIP, its members and contributors, a "ToIP Party") expressly disclaim any warranties (express, implied, or otherwise), including implied warranties of merchantability, non-infringement, fitness for a particular purpose, or title, related to the materials. The entire risk as to implementing or otherwise using the materials is assumed by the implementer and user. - -IN NO EVENT WILL ANY ToIP PARTY BE LIABLE TO ANY OTHER PARTY FOR LOST PROFITS OR ANY FORM OF INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES OF ANY CHARACTER FROM ANY CAUSES OF ACTION OF ANY KIND WITH RESPECT TO THESE MATERIALS, ANY DELIVERABLE OR THE ToIP GOVERNING AGREEMENT, WHETHER BASED ON BREACH OF CONTRACT, TORT (INCLUDING NEGLIGENCE), OR OTHERWISE, AND WHETHER OR NOT THE OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. - -## Acknowledgements - -The Climate Action Secretariat (CAS) ecosystem contains structural elements from the Trust over IP Metamodel that were developed by Governance Stack Working Group of the Trust over IP Foundation, the eSSIF Lab Glossary and Mental Models, were contributed to the Trust Over IP Foundation under the CC BY-SA 4.0 license. There have also been contributions from the Concepts & Terminology Working Group at ToIP, the Human Experience Working Group at ToIP and the Ecosystem Foundry Working Group at ToIP, the work of the Governance Framework Working Group at Sovrin Foundation is also acknowledged in providing support. - -## Terminology and Notation - -ToIP Governance Requirements Glossary - -**Requirements** include any combination of Machine-Testable Requirements and Human-Auditable Requirements. Unless otherwise stated, all Requirements MUST be expressed as defined in RFC 2119. - -• Mandates are Requirements that use a MUST, MUST NOT, SHALL, SHALL NOT or REQUIRED keyword. - -• Recommendations are Requirements that use a SHOULD, SHOULD NOT, or RECOMMENDED keyword. - -• Options are Requirements that use a MAY or OPTIONAL keyword. - -**Machine-Testable Requirements** are those with which compliance can be verified using an automated test suite and appropriate scripting or testing software. - -**Rules** are Machine-Testable Requirements that are written in a Machine-Readable language and can be processed by a Rules Engine. They are expressed in a structured rules language as specified by the Governance Framework. - -**Human-Auditable Requirements** are those with which compliance can only be verified by an audit of people, processes, and procedures. - -**Policies** are Human-Auditable Requirements written using standard conformance terminology. The Policies used in the Governance Framework will use the standard terminology detailed in RFC 2119 keywords. Note that all RFC 2119 keywords have weight from an auditing perspective. An implementer MUST explain why a SHOULD or RECOMMENDED requirement was not implemented and SHOULD explain why a MAY requirement was implemented. - -**Specifications** are documents containing any combination of Machine-Testable Requirements and Human-Auditable Requirements needed to produce technical interoperability. - -## Purpose - -The purpose of CAS Ecosystem Rules is to describe the rules/policies/procedures for verifiable credential exchanges involving __________________ with the _____________. The purpose of the rules is to enable all actors to understand agreed upon standards, terminology and processes that allow the CAS system to operate. This will help determine a governing framework and operating model for a global ecosystem that identifies how credentials can be issued, held, and verified by our natural resources business, so that any downstream purchaser, certifier, or financer can be assured of the attested good practices of the BC Industry to prove sustainable resourcing. - -## Localization - -1) The official language of the CAS Ecosystem Governance Framework SHALL be American English. -2) The Governance Framework Website SHALL include introductory remakes in the languages of the G20 countries. -3) For situations in which CAS Governance Framework MAY be needed in another language, CAS will consider this on a case-by-case basis. - - -## Governing Authority - -1) The BC Government Climate Action Secretariat (CAS) as Governing Authority is responsible for the CAS Ecosystem Governance Framework. -2) Information can be accessed here Climate Action Secretariat Of BC -3) LEI (Legal Identity Identifier) ______________ -4) The jurisdiction for this governance framework is the Province of BC -5) The contact information for CAS is -__________________________ -__________________________ -Recommendations for the governing parties in the governance model are contained in the Governance Requirements. This is a controlled document. - -## Purpose - -The purpose of the CAS Ecosystem Governance Framework is to describe the rules/policies/procedures for Scope 1 and 2 GHG Emissions verifiable credential exchanges with CAS. CAS will be using a subset of content from the Scope 1 and 2 GHG Emissions credential called Emissions Presentation Definition v1.0. CAS will also describe the rules/policies/procedures for Carbon Intensity Verifiable Credential exchanges with CAS. - -## Scope - -The following entities are stakeholders in the Trust Community - -**CAS - TOIP Rules** apply to all parties who become members of the CAS Ecosystem. - -**CAS**- CAS (Climate Action Secretariat) is the Governing Authority, The Climate Action Secretariat drives change to achieve British Columbia's greenhouse gas emission reduction targets. - -**Credential issuer** – An organization accredited by CAS to validate __________information and register new __________ and reference data which are sent to ______________ for inclusion in the __________ - -**Legal Entity** – A legal person or structure that is organized under the laws of any jurisdiction that meet the eligibility criteria for registering for a _______________ credential - -**CAS Credential User** – Any user of a CAS GHG credential in any applicable use case. - -**Out of scope** for the CAS Ecosystem Governance Framework are GHG measurements managed by other entities and documents. Although CAS encourages other governance frameworks to make use of the CAS Ecosystem Governance Framework for___________ Credentials, these governance frameworks also are out of scope. - -## Objectives - -The objectives of the CAS Ecosystem Governance Framework for a____________ credential is the following: -Account for _______________Credentials -- CAS wants to account for __________________ and __________________ -- Expand the capacity for _________________ accounting through cryptographically verifiable credentials -- Attract investors through ________________standard reporting -Incentivize Compliance -- The CAS governing framework seeks to incentivize compliance with GHG accounting rules amongst participants. -- The CAS governing framework seeks to incentivize compliance with Carbon Intensity accounting rules amongst participants. -- Enable a chain of trust through legal entities, credential issuers and governance authorities. -- Support further levels of delegated identifiers and associated Verifiable Credentials to provide scalability. -Enable new Use Cases -- The establishment of a CAS Governance Framework will incentivize wider adoption of decentralized trust technology for verifiable credentials - -## Principles - -1) Sustainability -2) Stewardship -3) Public good -4) Transparency -5) Citizen Engagement -6) Digital Sovereignty -7) Security -8) Confidence -9) Synchronization - -## Privacy - -• Privacy and Minimal Disclosure: CAS Ecosystem SHALL protect digital data to ensure the privacy of CAS Ecosystem Members. - -• The CAS Ecosystem SHALL require members explicit intention or consent for each use of digital data. - -• The CAS Ecosystem Members SHALL enjoy all the data rights and protections provided under relevant legislation and policy. - -• CAS Ecosystem Members SHALL fulfill all the data duties and obligations as required by the Governance Framework. - - -## Business Requirements - Terminology - -**Identity (Authentication)** - -- Will be made up of a Verified Credential (VC) for Personal Identity. -- VC Storage Location will take place on a digital Business Wallet with a secure connection. -- Verifiable Credential Proof will be requested by the Line of Business system and the proof will be provided by the Personal Digital wallet. -- The Verifiable credential will be issued from the Company Digital Wallet - -**Delegation** -- Refers to a Verifiable Credential for permission to delegate a specific role. -- The VC Storage Location will be held on the digital wallet, with the VC proof being requested by the Company’s Digital wallet. -- VC Proof is provided by the personal digital wallet and the VC will be issued by the Company Digital wallet. - -**Authorization** -- Allows a verifiable credential to a person giving them a role (such as the issuer of a permit credential). -- VC will be stored on the Personal Digital Wallet, with VC Proof Requested by Line of Business Systems. -- VC Proof will be provided by the digital wallet with the VC issued from a company digital wallet. - -## Business Requirement - CAS and _____________ - - -CAS will have a connection with ________ to facilitate interaction from a business requirement side. There is currently a business agreement between _______________ and CAS. The Business wallet will facilitate a secure connection and is a “registered business”. We want CAS to have a connection to __________ allowing interaction between both parties to support business requirements. - -Verifiable Credentials process will involve the following: - -(a) Mines Act Permit Issuance - -(b) The ___________ profile which includes: - -(i) Reported __________for a Facility. - -(ii) Reported Scope 2 emissions for a facility. - -(iii) Carbon Intensity for a product. - -(c) Registration in the TSM Certification Program - -(d) A proof request only - -(e) TSM protocol External Verification - -(f) Confirmation of TSM Certification Completion - - -Both __________Emission credential and Carbon Intensity will be issued as two separate, distinct credentials by _____________. This is to mitigate data privacy concerns with reporting both measurements under one umbrella. - -Reported ___________data is included in a Layer 3 ToIP governance document outlining standards and business requirements related to CAS (Climate Action Secretariat) acting as an issuer for GHG Emissions Credentials Data. - -Reported _______ data is included in a Layer 3 ToIP governance document outlining standards and business requirements related to CAS acting as an issuer of Carbon Intensity Credentials Data. - -CAS will issue the Carbon Intensity Credential. This Credential will state the carbon intensity per unit of measure. The amount of carbon by weight emitted per unit of energy consumed (CO2 emissions/energy). A common measure of carbon intensity is the weight of CO2 per Btu of energy. - -## Technical Requirements - -1) User/system of business wallet initiates presentation proposal with emissions data -2) CAS wallet auto accepts the proposal -3) CAS reads attributable data and loads into database -A mechanism will be developed to save the raw data and check the validity - -GHG Emissions and Carbon Intensity Credentials - -1. All GHG Emissions Credentials MUST maintain an entity status of Active and a GHG registration status other than Lapsed, Retired, Duplicate, Annulled or Merged -2. All issuers of credentials MUST verify that a Holder’s Automatic Identifier is controlled by the holder -3. All _______ MUST have executed a GHG Emission issuer Qualification Agreement -4. All ________ MUST successfully complete a GHG Emission issuer Qualification -5. CAS MUST publish the GHG Ecosystem Governance Framework on _________and follow the policies in the revision section for all revisions of the CAS Ecosystem Governance Framework -6. GHG Emissions Credentials MUST be revocable following the policies specified in the CAS Ecosystem Governance Framework -7. MUST ensure that third parties comply with the CAS Governance Frameworks when providing ____________services to a __________. -Carbon Intensity Reporting -1. All Carbon Intensity Credentials MUST maintain an entity status of Active and a Carbon Intensity registration status other than Lapsed, Retired, Duplicate, Annulled or Merged -2. All issuers of credentials MUST verify that a Holder’s Automatic Identifier is controlled by the holder -3. All _______ MUST have executed a Carbon Intensity issuer Qualification Agreement -4. All ________ MUST successfully complete a Carbon Intensity issuer Qualification -5. CAS MUST publish the Carbon Intensity Framework on _________and follow the policies in the revision section for all revisions of the CAS Ecosystem Governance Framework -6. Carbon Intensity Credentials MUST be revocable following the policies specified in the CAS Ecosystem Governance Framework -7. MUST ensure that third parties comply with the CAS Governance Frameworks when providing ____________services to a __________. - -## Changing the CAS Rules - -The **CAS Ecosystem Rules** can change for the following reasons: -1. Changes in laws or regulations -2. Changes proposed by the existing community -3. Changes proposed by potential new community members. - -## Revisions - -1. Any **CAS Ecosystem Member** MUST be able to propose a change to, or translation of the **CAS Ecosystem Rules** by contacting the **administrative authority** e.g. by emailing _____________ -2. Any participant in the CAS Ecosystem SHOULD be able to propose a change to the **CAS Rules** by contacting the **administering authority** e.g. by emailing _____________ -3. The administering authority MUST implement a change process as specified in the Governance Requirements controlled document. -4. The **CAS Ecosystem Rules** MUST be revised if_______________ -5. The **CAS Ecosystem Rules** will be reviewed ____________________ -6. Anything in the **CAS Rules** is found to be in breach of the law within the legal jurisdiction of ____________________. -7. There are changes to the legal jurisdiction in which the **administering authority** or the **CAS platform operator** are registered. -8. There are changes in applicable law, for example data protection law, within the legal jurisdiction of the **CAS Rules** which is________________. -9. There are substantive changes to the functionality of the **CAS platform** for example if the **CAS community** employs new **artificial intelligence (AI) techniques.** -10. ____________ are able to become CAS on their own account. -11. **Actions** or **transactions**, especially those associated with risk decisions or the control of **digital data**, which are currently carried out by human actors are replaced with automation and decision-making by **non-human actors**. For example, machine-readable **governance**. -12. The **CAS objectives** change (adding, changing and/or removing them). -13. As a result of a risk assessment process, a new threat or high risk or significant harm is identified which arises from the implementation of the **CAS Rules** or which can be treated through a revision of the **CAS Rules**. -14. A change proposed by a **CAS Ecosystem Member **successfully completes the change process as defined by the **administering authority**. -15. Revisions of the **CAS Rules** SHOULD be compliant with the ToIP Metamodel and MAY be reviewed by **members** of the Trust over IP Foundation. - -## Extensions - -1) CAS welcomes other Governance Frameworks to leverage the CAS Ecosystem Framework but does not anticipate the need at this time to specify formal extensions from other external Governance Frameworks that will leverage the CAS Ecosystem Governance Framework. -2) The CAS Ecosystem Framework is extended by the following internal governance framework: CAS Identifier Governance Frameworks and GHG Emissions Credential Governance Frameworks. -3) Requirements for extension, activation and deactivation are ____________________ notification should be made to the trust community through _____________ methods. - -## Inclusion, Equitability and Accessibility Requirement - -CAS must design the CAS Ecosystem to be able to make credentials available to any legal entity issued a GHG Credential in the CAS Ecosystem. - -## Schedule of Controlled Documents - -DID URLS for all documents will be published with the Draft of the Ecosystem Governance Framework - -This Draft can be viewed at ________________________ - -**Glossary** - -Verifiable Scope 2 and 3 GHG CAS Ecosystem Governance Framework Glossary is a document that lists all defined terms have been referenced in the CAS Documents. -Verifiable Scope 2 and 3 Carbon Intensity Ecosystem Governance Framework Glossary is a document that lists all defined terms that have been reference in the CAS Documents. - -**Risk Assessment** - -Verifiable GHG Emissions Credentials Risk Assessment is a ______________ that assesses certain risk categories regarding the operation of the CAS Ecosystem and Infrastructure. -Verifiable Carbon Intensity Credentials Risk Assessment is a ______________ that assesses certain risk categories regarding the operation of the CAS Ecosystem and Infrastructure. - -**Trust Assurance and Certification** - -Verifiable GHG Emissions Credentials Governance Framework Trust Assurance is a spreadsheet that focuses on MUST statements within other GHG Emissions Governance documents and specifies the services/processes that will be used to evaluate compliance with these statements -Verifiable Carbon Intensity Credentials Governance Framework Trust Assurance is a spreadsheet that focuses on MUST statements within other GHG Emissions Governance documents and specifies the services/processes that will be used to evaluate compliance with these statements - -## Governance Requirements - -**GHG Ecosystem** - -1. The governance of the CAS GHG Ecosystem can be found -at __________________________ -2. The Memorandum of Understanding between the CAS and______________ -can be found at ________________ -3. The Charter of the _______________can be downloaded as a ____________ -4. The Statutes of CAS can be downloaded as a pdf, ______________ -5. The By-laws of ____________ can be downloaded as a pdf,____________ -6. CAS has a Board of independent directors, -7. The CAS standard, ISO 17442-1:2020 Financial services – Legal entity identifier (LEI) – -Part 1: Assignment can be found here: ___________________ - -**Carbon Intensity Ecosystem** - -1. The governance of the CAS Carbon Intensity can be found -at __________________________ -2. The Memorandum of Understanding between the CAS and______________ -can be found at ________________ -3. The Charter of the _______________can be downloaded as a ____________ -4. The Statutes of CAS can be downloaded as a pdf, ______________ -5. The By-laws of ____________ can be downloaded as a pdf,____________ -6. CAS has a Board of independent directors, -7. The CAS standard, ISO 17442-1:2020 Financial services – Legal entity identifier (LEI) – -Part 1: Assignment can be found here: ___________________ -  - diff --git a/docs/resources/bc-vcpedia/applications/_pilots/bc-court-services.md b/docs/resources/bc-vcpedia/applications/_pilots/bc-court-services.md deleted file mode 100644 index e9f167c6..00000000 --- a/docs/resources/bc-vcpedia/applications/_pilots/bc-court-services.md +++ /dev/null @@ -1,50 +0,0 @@ ---- -layout: default -title: BC Court Services -parent: Applications ---- - -``` -{ - "name": "Accredited Lawyer with BC Person Credential", - "names": null, - "version": "1.0.0", - "nonce": "602630794297061505026135", - "requested_attributes": { - "a30a56f6-2475-4eef-bfde-1dda744cd1ab": { - "names": [ - "PPID", - "Given Name", - "Surname", - "Member Status", - "Member Status Code" - ], - "restrictions": [ - { - "schema_name": "Member Card", - "schema_version": "1.5.1", - "issuer_did": "4xE68b6S5VRFrKMMG1U95M" - } - ] - }, - "defbd346-bbfa-4c91-9065-160f07dc4739": { - "names": [ - "family_name", - "given_names" - ], - "restrictions": [ - { - "schema_name": "Person", - "schema_version": "1.0", - "issuer_did": "RGjWbW1eycP7FrMf4QJvX8" - } - ] - } - }, - "requested_predicates": {}, - "non_revoked": { - "from": 0, - "to": 1678898485 - } -} -``` diff --git a/docs/resources/bc-vcpedia/applications/_pilots/bc-law-society.md b/docs/resources/bc-vcpedia/applications/_pilots/bc-law-society.md deleted file mode 100644 index 7a9fc783..00000000 --- a/docs/resources/bc-vcpedia/applications/_pilots/bc-law-society.md +++ /dev/null @@ -1,19 +0,0 @@ ---- -layout: default -title: BC Law Society -parent: Applications ---- - -Coming soon... - -IDIM issues digital identity to lawyers -* Verified Person VC - -Law Society requests proof of digital identity -* Verified Person VC - -Law Society issues membership -* Law Society Membership VC - -Court Services Website authenticates and authorizes with proof request -* Law Society Membership VC diff --git a/docs/resources/bc-vcpedia/applications/_pilots/consumption-of-verification.md b/docs/resources/bc-vcpedia/applications/_pilots/consumption-of-verification.md deleted file mode 100644 index 74804ee2..00000000 --- a/docs/resources/bc-vcpedia/applications/_pilots/consumption-of-verification.md +++ /dev/null @@ -1,198 +0,0 @@ ---- -layout: default -title: Consumption of Verification Statement Governance Document -parent: Applications ---- - -# Consumption of Verification Statement Governance Document -# Introduction - -_____________________will be involved in the development of Verifiable Credentials that will be administered through the Trust Over IP (ToIP) system. Requirements for Emissions Verification statements are outlined in Section 33 of the Greenhouse Gas Emission Reporting Regulation under the Greenhouse Gas Industrial Reporting and Control Act outlining the required "Content of Verifications Statements". Current reporting is made through ______________ submitting a PDF Report outlining an operation's GHG Emissions through the SWIM (Single Window Information Manager). With the creation of an option for submitting a VC, any additional data such as supplementary data that is not included in the developed schema would be manually typed into the SWIM form. - -This governance document outlines a presentation request for minimal data that would satisfy the Reporting Requirements under the above regulation. Verified Credentials would not replace the SWIM system. Instead it would exist as an additional option to submit a proof request for reporting and submitting Verification Statements instead of uploading a PDF. In using this verifiable credential, it is not required to submit word documents through the SWIM system, however submissions would need to include viable proof requests including all of the reporting requirements. - -In the current system, a Large C02 Emitter (Company) completes operations and yearly reporting based on regulatory requirements. An alternative 3rd party then agrees to complete verification of reported emissions. In the event that errors in reports require resubmission,________ reviews re-submitted data and compares results of report with expected results. - -GHG emissions accounting utilize the GHG Protocol as the primary standard. Greenhouse Gas Protocol provides the world's most widely used greenhouse gas accounting standards for companies. _____________ will work in partnership with the Trust Over IP Foundation (TOIP) Ecosystem to issue this governance framework. - -This governance document has been developed in accordance with the ToIP’s Governance Metamodel Specification created by the Governance Stack Working Group (GSWG) as the template for this framework. - -Terminology and Notation -[Glossary - General Trust Over IP Terms](https://trustoverip.github.io/toip/glossary) - -# Localization - -1. The standard language for this governing framework is American English. -1. The governance framework website SHALL include introductory remakes in all the languages of the g20 countries. -  -# Governing Authority - -_________BC is the governing authority and party legally responsible for developing, maintaining and implementing the Governance Framework. -The contact for petitioners and relying parties of this GF is - -* Name ___________ -* Title ____________ -* Organization ___________ -* Email ____________ - -# Purpose - -The purpose of this governance document is to outline the specific presentation request that would be developed for GHG Reporting. This would be based of off emissions information that ______________ could could attest or assure. This information would include attested data such as Reporting Operation Emissions, Total Emissions, Total Co2 from Biomass etc. Scope 1 Greenhouse Gas Emissions from various sources have been unreliably accounted for using various sources. - -Information on GHG Emissions Reporting can now be developed into Verifiable Credential standards, systems and governance to allow a more trustworthy ecosystem. This will be built under this governance framework. The purpose of this governance framework to outline all rules associated with governance, issuance, verification, and revocation of these GHG Reporting credentials. The governance document is applicable to all parties who consume the GHG Reporting Credentials. - -# Scope - -The GF covers the following components: - -# Key Roles - -Issuers: An entity that can accurately report on GHG emissions - -Verifiers: An entity that can accurately attest to reported GHG emissions - -Legal Entity: A legal person or structure that is organized under the laws of any jurisdiction that meets the eligibility criteria for registering for a VC. - -The scope of the Ecosystem Governance Framework is to enable stakeholder to issue, hold and verify Credentials using the ToIP framework to ensure that these activities take place in compliance with Ecosystem Governance Frameworks. - -# Key Processes - -The following processes will participate in this GF as Governed Roles - -* Credential Issuance: Will be made by ___________ upon receiving data from _________ -* Verification: The process by which __________ will verify the originator of GHG credentials -* GHG Receipt: Process whereby GHG emissions credentials of subject mines will be collected by the repository - -# Key Trust Decisions - -The trust decisions made under this GF is the qualification and determination of GHG Emissions Credentials and the determination of Credential Issuance to ___________________ -Out of Scope - -* Any other credential other than GHG Emissions Reporting -* Mines operating in other provinces -* Evaluation of other ESG priorities - -# Objectives - -The objective of this Governance Framework are to define the rules, requirements, processes and artifacts that enable Verifiable Credentials to be applied to Reporting Requirements systems process so that _____________ can ensure compliance with ESG frameworks on a provincial level. -  -# Principles - -The Principles Underlying this GF follow agreed-upon principles for the ________________ - -1. Sustainability -1. Stewardship -1. Public good -1. Transparency -1. Citizen Engagement -1. Digital Sovereignty -1. Security -1. Confidence -1. Synchronization - -# General Requirements - -The General Requirements section is reserved for policies that apply generally to the Governance Framework as a whole and not just in the context of a particular controlled document. - -* All articles concerning GHG emissions must remain private and not sold to third parties. All governing parties shall implement responsible use policies that apply to GHG emission recording. -* Entities must identify themselves using high assurance verifiable credentials when submitting information related to GHG Emissions -* All revised and outdated GHG Credentials must be expunged each year from the credential repository by January 1st -* All governed parties shall abide by a Code of Conduct - -# Revisions - -A key design principle of the ToIP stack model is to “design for change”. In most cases, GFs are “living documents” that need to evolve as their trust community evolves. There, the ToIP governance Architecture Specification has strict requirements for document versioning. - -# Schedule of Controlled Documents - -The following documents are included as appendices: - -1. Glossary -1. Risk Assessment -1. Trust Assurance and Certification -1. Governance Requirements -1. Business Requirements -1. Information Trust Requirements -1. Inclusion, Equity and Accessibility Requirements -1. Legal Agreements - -# Controlled Documents - -# Glossary - -In the field of Digital Identity, trust and governance, a well-defined glossary is essential. Glossaries ensure that all stakeholders – businesses, legal, technical and operational – share a collective understanding of the terms used within a GF. - -A GF includes a glossary that includes terms in the following three general categories - -1. TOIP Core Terms that describe the common components of the TOIP model -1. TOIP Governance Terms are specialized terms used to describe TOIP governance concepts -1. GF Specific Terms are terms needed in the context of this GF. This is included in the __________ Scope 1 GHC Emissions Credential Terms Page. - -# Risk Assessment - -_________________ and ______________ will develop strategies to mitigate risk. There are risks associated with establishing and maintaining a healthy trust community: technical risks, business risks, governance risks, regulatory risks, etc. - -# Trust Assurance and Certification - -While a detailed risk assessment is warranted for this GF, for the first draft of the GF, _____________ has identified the following audit criteria to be assessed by an auditor - -* Availability Controls for ____________ -* Policies and controls for _______________ -* Review of background checks for_______________  - -# Governance Requirements - -Trust in a GF requires a Governing Authority. This trust is rooted in the foundational governance documents for the governing authority itself. This includes - -1. GHG Emissions Credentials based on sound data -1. BC Policies and Regulations - -# Business Requirements - -Many business requirements will flow directly from the objectives. Policies in this section will outline business rules common to any business or industry organization. Business rules will apply in the specific context of the GF in order to govern specific actions taken by specific actors performing specific roles and processes within the ____________ and _________ Trust Community. - -The Business rules for Scope 1 GHC Emissions Credential Issuance are: - -1. ________________________________________ -1. ________________________________________ -1. ________________________________________ - -# Technical Requirements - -The structure of the ToIP stack graphically illustrates that governance is only half of what is required for inter-operability within and between trust communities. The other half is technical interoperability. This is the responsibility of the ToIP technology. The Technical policies for _____________ GF are the following: - -1. The DID for _________ must be ________- -1. The DID for __________ must be __________ -1. The Verifiable Credential format for _______ and ___________ must be -1. All Verifiable Presentations of _________- and _____________ must use privacy preserving standards -1. The User interface for obtaining, processing and presenting __________ and _________ credentials -1. Must be translate into all human languages -1. Must go through proof testing -1. Should ______________ -1. Must ________________ - -# Information Trust Requirements - -The members of the trust community need to mitigate against a common set of threats that could impact members. ___________ will adopt the following information trust policies, across the five Trust Services Criteria: - -1. Information security shall____________ -1. Information availability shall ______________ -1. Information process integrity shall _____________ -1. Information confidentiality shall __________________ -1. Information privacy shall _________________ - -# Inclusion, Equity and Accessibility Requirements - -This final category of requirements is especially important for digital trust communities – important enough that this category of controlled document is REQUIRED in a ToIP – compliant GF. Scope 1 GHG Emissions Credentials GF policies in this category are - -1. ________________________________________ -1. ________________________________________ -1. ________________________________________ - -# Legal Agreements - -Legal agreements will be drafted in accordance with _______________ policies and procedures. These agreements will outline contractual commitments between the governing authority and the governed parties playing various roles. ________________ requires the following legal agreements - -1. ________________________________________ -1. ________________________________________ -1. ________________________________________ diff --git a/docs/resources/bc-vcpedia/applications/_pilots/envirochem.md b/docs/resources/bc-vcpedia/applications/_pilots/envirochem.md deleted file mode 100644 index 341dde40..00000000 --- a/docs/resources/bc-vcpedia/applications/_pilots/envirochem.md +++ /dev/null @@ -1,181 +0,0 @@ ---- -layout: default -title: Envirochem Governance Framework -parent: Applications ---- - -## Envirochem Governance Framework - -# 1. Primary Document - -## 1.1. Introduction - -This document articulates the governance framework for Envirochem as a participant of the open global community that exchanges verifiable credentials [(layer four application of the Trust Over IP Foundation (ToIP) model)](https://www.trustoverip.org/wp-content/toip-model/). - -The development of this documentation follows the governance framework created by the [Trust over IP Foundation (ToIP)](https://trustoverip.org/) [Governance Metamodel Specification](https://trustoverip.org/wp-content/uploads/ToIP-Governance-Metamodel-Specification-V1.0-2022-12-21.pdf) created by the [Governance Stack Working Group (GSWG)](https://wiki.trustoverip.org/display/HOME/Governance+Stack+Working+Group). - -These materials are made available under and are subject to the [Creative Commons Attribution 4.0 International license](http://creativecommons.org/licenses/by/4.0/legalcode). - -THESE MATERIALS ARE PROVIDED “AS IS.” The Trust Over IP Foundation, established as the Joint Development Foundation Projects, LLC, Trust Over IP Foundation Series ("ToIP"), and its members and contributors (each of ToIP, its members and contributors, a "ToIP Party") expressly disclaim any warranties (express, implied, or otherwise), including implied warranties of merchantability, non-infringement, fitness for a particular purpose, or title, related to the materials. The entire risk as to implementing or otherwise using the materials is assumed by the implementer and user. - -IN NO EVENT WILL ANY ToIP PARTY BE LIABLE TO ANY OTHER PARTY FOR LOST PROFITS OR ANY FORM OF INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES OF ANY CHARACTER FROM ANY CAUSES OF ACTION OF ANY KIND WITH RESPECT TO THESE MATERIALS, ANY DELIVERABLE OR THE ToIP GOVERNING AGREEMENT, WHETHER BASED ON BREACH OF CONTRACT, TORT (INCLUDING NEGLIGENCE), OR OTHERWISE, AND WHETHER OR NOT THE OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. - -***Acknowledgements*** - -This governance framework includes structural elements from the Trust over IP Metamodel that were developed by Governance Stack Working Group of the Trust over IP Foundation, the eSSIF Lab Glossary and Mental Models, were contributed to the Trust Over IP Foundation under the CC BY-SA 4.0 license. There have also been contributions from the Concepts & Terminology Working Group at ToIP, the Human Experience Working Group at ToIP and the Ecosystem Foundry Working Group at ToIP, the work of the Governance Framework Working Group at Sovrin Foundation is also acknowledged in providing support. - -## 1.2. Terminology and Notation - -[Glossary - General Trust Over IP Terms](https://trustoverip.github.io/toip/glossary) - -**Requirements** include any combination of Machine-Testable Requirements and Human-Auditable Requirements. Unless otherwise stated, all Requirements MUST be expressed as defined in [RFC 2119](https://www.rfc-editor.org/rfc/rfc2119). - -- Mandates are Requirements that use a MUST, MUST NOT, SHALL, SHALL NOT or REQUIRED keyword. -- Recommendations are Requirements that use a SHOULD, SHOULD NOT, or RECOMMENDED keyword. -- Options are Requirements that use a MAY or OPTIONAL keyword. - -**Machine-Testable Requirements** are those with which compliance can be verified using an automated test suite and appropriate scripting or testing software. - -**Rules** are Machine-Testable Requirements that are written in a Machine-Readable language and can be processed by a Rules Engine. They are expressed in a structured rules language as specified by the Governance Framework. - -**Human-Auditable Requirements** are those with which compliance can only be verified by an audit of people, processes, and procedures. - -**Policies** are Human-Auditable Requirements written using standard conformance terminology. The Policies used in the Governance Framework will use the standard terminology detailed in RFC 2119 keywords. Note that all RFC 2119 keywords have weight from an auditing perspective. An implementer MUST explain why a SHOULD or RECOMMENDED requirement was not implemented and SHOULD explain why a MAY requirement was implemented. - -**Specifications** are documents containing any combination of Machine-Testable Requirements and Human-Auditable Requirements needed to produce technical interoperability. - -## 1.3. Localization -The standard language for this Governance Framework (GF) is American English. - -## 1.4. Governing Authority - -[Envirochem](https://www.envirochem.com/) is the Governing Authority responsible for this Governance Framework (GF). The contact information for Envirochem during the pilot phase of development is: - -* **Name:** Neil Allen -* **Title:** Senior Auditor - HSE Assurance & Management Systems -* **Organization:** Envirochem Services Inc. -* **Email:** [neil.allen@envirochem.com](mailto:neil.allen@envirochem.com) - -## 1.5. Administering Authority - -[Energy and Mines Digital Trust (EMDT)](https://digital.gov.bc.ca/case-studies/emdt) is the Administering Authority on behalf of Envirochem during the pilot phase of development. - -The contact information for EMDT is: -* **Name:** Kyle Robinson -* **Title:** Senior Strategic Advisor, Digital Trust Ecosystems -* **Organization:** Briartech Consulting Inc. -* **Email:** [kyle.robinson@briartech.ca](mailto:kyle.robinson@briartech.ca) -* -## 1.6. Purpose - -The purpose of this governance framework is to describe the rules/policies/procedures for verifiable credential exchanges involving Envirochem Services Inc. with the open global community. The purpose of the rules is to enable all actors to understand agreed upon standards, terminology and processes that allow the community to interact with EnviroChem in a trusted manner. This will help determine a governing framework and operating model for a global ecosystem that identifies how credentials can be issued, held, and verified. - -## 1.7. Scope - -Envirochem is a participant in an open ecosystem and the focus of this framework is to describe the process Envirochem uses for digital exchanges on Indy networks. - -## 1.8. Objectives - -_This section states the high-level outcomes desired by the trust community through its adoption of the GF._ -1. SHOULD specify tangible, achievable results (e.g. SMART criteria and Fit-for-Purpose criteria). -2. MUST only contain outcomes over which the GF has the authority and mechanisms to achieve within its -scope. -3. MUST be consistent with the principles of the GF (below). - -TBD - -## 1.9. Principles - -See [Envirochem's Guiding Values](https://www.envirochem.com/about/) - -## 1.10. General Requirements -TBD - -## 1.11. Revisions -TBD - -## 1.12. Extensions - -There are no extensions to this Governance Framework. - -## 1.13. Schedule of Controlled Documents -TBD - -# 2. Controlled Documents - -## 2.1. Glossary -TBD - -## 2.2. Risk Assessment - -TBD - -## 2.3. Trust Assurance and Certification - -TBD - -## 2.4. Governance Requirements -Envirochem is a private, 100% employee-owned Canadian company. -Envirochem governance is an internal process. - -## 2.5. Business Requirements - -## 2.5.1. Establishment of Connection - -1. Envirochem MUST send an invitation to the other business entity via email to initiate the exchange of information. -2. The receiving party MUST use the invitation in order to establish a secure connection. - -## 2.5.2. Third Party Verification of TSM Protocols - -*Please reference the [**TSM Terms of Reference** governed by the Mining Association of Canada (MAC)](https://mining.ca/wp-content/uploads/dlm_uploads/2021/11/2021-TSM-Verifier-Terms-of-Reference.pdf) for definitions as they pertain to TSM Protocols.* - -1. Using the established connection, Envirochem MUST receive a credential request from the client. -2. Continuing from step 1, the client MUST provide all of the following attributes in the credential request as outlined in the [TSM Protocol Credential GF]( https://github.com/bcgov/bc-vcpedia/blob/main/credentials/credential-tsm-protocol.md) __except any verifier attributes__: - -__Facility Information__: company_name, facility_name, facility_address, country_operation, products_name, operation_type, infrastructure_type - -__Summary of Findings__: summary_tsm_min, indigenous_q1, indigenous_q2, indigenous_q3, indigenous_q4, indigenous_q5, indigenous_summary_min, safety_health_q1, safety_health_q2, safety_health_q3, safety_health_q4, safety_health_q4_pd, safety_health_q5, safety_health_summary_min, corp_crisis_and_communication_preparedness, corp_crisis_and_communication_review, corp_crisis_and_communication_training, labour_forced_q1, labour_child_q2, corp_climate_q1, site_climate_q2, site_climate_q3, climate_summary_min, biodiversity_conservation_q1, biodiversity_conservation_q2, biodiversity_conservation_q3, biodiversity_conservation_summary_min, tailings_management_q1, tailings_management_q2, tailings_management_q3, tailings_management_q4, tailings_management_q5, tailings_management_summary_min, water_stewardship_q1, water_stewardship_q2, water_stewardship_q3, water_stewardship_q4, water_stewardship_summary_min - -4. Envirochem MUST receive and review the request -5. Any clarification questions MAY be asked via the secure messaging function -6. After completion of verification activity, Envirochem MUST update any attribute values as necessary -7. Envirochem SHALL offer the credential to the client -8. Client MAY choose to accept or negotiate the credential to request changes - -## 2.5.3. Green Marine Certification - -_to be completed by Envirochem_ -_[Green Marine Certification](https://green-marine.org/)_ - -## 2.5.4. WorkSafeBC Certification of Recognition (COR) -_to be completed by Envirochem_ -_[WorkSafeBC Certification of Recognition (COR)](https://www.worksafebc.com/en/health-safety/create-manage/certificate-recognition)_ - -## 2.6. Technical Requirements - -*MUST have an Hyperledger Aries compatible business wallet.* - -## 2.7. Information Trust Requirements - -[Envirochem Privacy Policy](https://www.envirochem.com/privacy-policy/) - -## 2.8. Inclusion, Equitability and Accessibility Requirement -TBD - -## 2.9. Legal Agreements -TBD - -# End of Document - - - - - - - - - - - - -  diff --git a/docs/resources/bc-vcpedia/applications/_pilots/ghg-emissions-reporting.md b/docs/resources/bc-vcpedia/applications/_pilots/ghg-emissions-reporting.md deleted file mode 100644 index 8370ef14..00000000 --- a/docs/resources/bc-vcpedia/applications/_pilots/ghg-emissions-reporting.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -layout: default -title: BC GHG Emissions Reporting Governance -parent: Applications ---- - -# BC GHG Emissions Reporting Governance - -https://www2.gov.bc.ca/gov/content/environment/climate-change/industry/reporting -https://www.bclaws.gov.bc.ca/civix/document/id/complete/statreg/249_2015 - -## Key Processes -Authentication to GHG Emissions Reporting Portal -* BC Business Registration? -* Verified Person? - -Wallet Connection -* DIDComm Invitation available from ___ - -Submit Annual Emissions data to Portal - Uses a presentation proposal from the Business Wallet -* [BC GHG Emissions Report Verification Statement Credential]https://github.com/bcgov/bc-vcpedia/blob/main/credentials/credential-bc-ghg-emissions-verification.md -* Self-attested data diff --git a/docs/resources/bc-vcpedia/applications/_pilots/openclimate-governance.md b/docs/resources/bc-vcpedia/applications/_pilots/openclimate-governance.md deleted file mode 100644 index bd97f0f1..00000000 --- a/docs/resources/bc-vcpedia/applications/_pilots/openclimate-governance.md +++ /dev/null @@ -1,294 +0,0 @@ ---- -layout: default -title: OpenClimate Ecosystem Governance Framework -parent: Applications ---- - -# OpenClimate Ecosystem Governance Framework - -# Primary Document - -## Introduction - -The OpenClimate Verifiable Credentials Ecosystem Governance Framework is a Layer Four Ecosystem Governance Framework of the Trust over IP Foundation (ToIP). The OpenClimate GHG Emissions identifier is used as a key component in building a trust layer for identification and verification of GHG emissions that require accounting. This ecosystem will assist in the development of the OpenClimate Corporate GHG Emissions Reporting Credential Pilot Project. OpenEarth Foundation is a research and deployment non-profit using cutting edge digital technologies and multi-stakeholder collaborations to advance open-source platforms that help increase planetary resilience. - -## Terms of Use - -These materials are made available under and are subject to the Creative Commons Attribution 4.0 International license (http://creativecommons.org/licenses/by/4.0/legalcode). - -THESE MATERIALS ARE PROVIDED “AS IS.” The Trust Over IP Foundation, established as the Joint Development Foundation Projects, LLC, Trust Over IP Foundation Series ("ToIP"), and its members and contributors (each of ToIP, its members and contributors, a "ToIP Party") expressly disclaim any warranties (express, implied, or otherwise), including implied warranties of merchantability, non-infringement, fitness for a particular purpose, or title, related to the materials. The entire risk as to implementing or otherwise using the materials is assumed by the implementer and user. - -IN NO EVENT WILL ANY ToIP PARTY BE LIABLE TO ANY OTHER PARTY FOR LOST PROFITS OR ANY FORM OF INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES OF ANY CHARACTER FROM ANY CAUSES OF ACTION OF ANY KIND WITH RESPECT TO THESE MATERIALS, ANY DELIVERABLE OR THE ToIP GOVERNING AGREEMENT, WHETHER BASED ON BREACH OF CONTRACT, TORT (INCLUDING NEGLIGENCE), OR OTHERWISE, AND WHETHER OR NOT THE OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. - -## Acknowledgements - -The **OpenClimate Ecosystem**contains structural elements from the Trust over IP Metamodel that were developed by Governance Stack Working Group of the Trust over IP Foundation, the eSSIF Lab Glossary and Mental Models, were contributed to the Trust Over IP Foundation under the CC BY-SA 4.0 license. There have also been contributions from the Concepts & Terminology Working Group at ToIP, the Human Experience Working Group at ToIP and the Ecosystem Foundry Working Group at ToIP, the work of the Governance Framework Working Group at Sovrin Foundation is also acknowledged in providing support. - -## Terminology and Notation - -**ToIP Governance Requirements Glossary** - -**Requirements** include any combination of Machine-Testable Requirements and Human-Auditable Requirements. Unless otherwise stated, all Requirements MUST be expressed as defined in RFC 2119. - -* Mandates are Requirements that use a MUST, MUST NOT, SHALL, SHALL NOT or REQUIRED keyword. - -* Recommendations are Requirements that use a SHOULD, SHOULD NOT, or RECOMMENDED keyword. - -* Options are Requirements that use a MAY or OPTIONAL keyword. - -**Machine-Testable Requirements** are those with which compliance can be verified using an automated test suite and appropriate scripting or testing software. - -**Rules** are Machine-Testable Requirements that are written in a Machine-Readable language and can be processed by a Rules Engine. They are expressed in a structured rules language as specified by the Governance Framework. - -**Human-Auditable Requirements** are those with which compliance can only be verified by an audit of people, processes, and procedures. - -**Policies** are Human-Auditable Requirements written using standard conformance terminology. The Policies used in the Governance Framework will use the standard terminology detailed in RFC 2119 keywords. Note that all RFC 2119 keywords have weight from an auditing perspective. An implementer MUST explain why a SHOULD or RECOMMENDED requirement was not implemented and SHOULD explain why a MAY requirement was implemented. - -**Specifications** are documents containing any combination of Machine-Testable Requirements and Human-Auditable Requirements needed to produce technical interoperability. - -## Purpose - -The purpose of the OpenClimate Ecosystem Rules is to describe the rules/policies/procedures for verifiable credential exchanges involving Scope 1 GHG Emissions with the OpenClimate Portal. The purpose of the rules is to enable all actors to understand agreed upon standards, terminology and processes that allow the OpenClimate Ecosystem to operate. This will help determine a governing framework and operating model for a global ecosystem that identifies how credentials can be issued, held, and verified by our natural resources business, so that any downstream purchaser, certifier, or financer can be assured of the attested good practices of the BC Industry (in the scope of this pilot) to prove sustainable resourcing. - -## Localization - -1) The official language of the Open Earth GHG Ecosystem Governance Framework SHALL be American English. -2) The Governance Framework Website SHALL include introductory remakes in the languages of the G20 countries. -3) For situations in which Open Climate Ecosystem Governance Framework MAY be needed in another language, Open Earth will consider this on a case-by-case basis. - -## Governing Authority - -1) The OpenEarth Foundation (OEF) as Governing Authority is responsible for the OpenClimate Ecosystem Governance Framework. -2) The contact information for OpenEarth is: - - martin@openearth.org - - joaquin@openearth.org -__________________________ -Recommendations for the governing parties in the governance model are contained in the Governance Requirements. This is a controlled document. - - -## Purpose - -The purpose of the Open Climate Ecosystem Governance Framework is to describe the rules/policies/procedures for Scope 1 GHG Emissions verifiable credential exchanges with the OpenClimate Portal. OpenClimate will be using a subset of content from the Scope 1 GHG Emissions credential called Emissions Presentation Definition v1.0. - -## Scope - -The following entities are stakeholders in the Trust Community - -**The OpenEarth - TOIP Rules** apply to all parties who become members of the Open Earth Ecosystem. - -**OpenEarth**- OpenEarth Foundation is the Governing Authority, a research and deployment non-profit using cutting edge digital technologies and multi-stakeholder collaborations to advance open-source platforms that help increase planetary resilience. - -**Credential Issuer**– An organization accredited by OpenEarth to validate company, facility and their related GHG emissions information and register new companies and reference data which are sent to OpenClimate for inclusion in the OpenClimate Independent Emission Inventory. - -**Legal Entity** – A legal person or structure that is organized under the laws of any jurisdiction that meet the eligibility criteria for registering for a Scope 1 GHG Emissions credential - -**OpenClimate Credential User** – Any user of an OpenClimate GHG credential in any applicable use case. - -**Out of scope** for the OpenClimate Ecosystem Governance Framework are GHG measurements managed by other entities and documents. Although OpenClimate encourages other governance frameworks to make use of the Open Climate Ecosystem Governance Framework for Scope 1 GHG Emissions Credentials, these governance frameworks also are out of scope. - -### Key Roles: -* Validator: The Credential Issuer that validates that the data shared by the company is true according to a certain methodology. -* Company: The legal entity that is reporting their climate data - -## Key Processes: - -**User and Company Invitation** -- An organization will be created in the OpenClimate platform - - If the organization already exists in the platform, this step can be skipped -- A user will be invited into the platform by providing their name and email -- The user will receive an email to the registered email address with a link that will lead to the issuance of two credentials, a Verified Email Credential and a Verified Employee Credential, to be stored in their Personal Wallet. - -**User Identity & Authentication** -- Will be made up of two separate Verified Credentials (VC) for Personal Identity, a Verified Email Credential and a Verified Employee Credential - - The Verified Email Credential MUST be issued by the OpenClimate platform upon invitation of the user - - The Verified Employee Credential SHOULD be issued by the Company to which the user belongs, but MAY be issued by the OpenClimate platform -- Identity VC Storage Location MUST take place on a Personal Wallet with a secure connection. -- Verifiable Credential Proof will be requested by the OpenClimate platform for authentication and the proof will be provided by the Personal Digital wallet - -**Business Registration & Authentication** - -- Will be made up of a Verified Credential (VC) for BC Business Registration. -- VC Storage Location SHOULD take place on a Business Wallet with a secure connection - - Some organizations MAY use a Personal Wallet for Emissions VC storage but it is not recommended -- Verifiable Credential Proof will be requested by the OpenClimate platform and the proof will be provided by the Business or Personal Wallet, linking the Business Wallet to the user - -**Emissions presentation** - -- Will be made up of a Verified Credential (VC) for Scope 1 GHG Emissions -- VC Storage Location SHOULD take place on a Business Wallet with a secure connection that has been already registered in the OpenClimate platform as a user’s linked Business Wallet - - Some organizations MAY use a Personal Wallet for Business Registration VC storage but it is not recommended -- Verifiable Credential Proof MAY be requested by the OpenClimate platform and the proof will be provided by the Business or Personal Wallet -- Verifiable Credential Proof MAY be presented directly by the Company by sharing a proof presentation to the OpenClimate platform following the correct proof presentation definition - -## Key Trust Decisions - -#### Trusted Issuers -The list of Trusted Issuers of the Scope 1 GHG emissions credential is available at - -| Issuer Name | Wallet DID | Ledger | -|-------------|------------|--------| -| BC Gov Climate Action Secretariat| dskhfk23948 | BCovrin | - -#### Supporting Governance Frameworks -The OpenClimate Platform adheres to the following Governance Frameworks to ensure interoperability: -* Layer 3 - [Scope 1 GHG Emissions Credential Governance Framework (Primary Document)](https://github.com/bcgov/bc-vcpedia/wiki/Scope-1-GHG-Emissions-Credential-Governance-Framework-(Primary-Document)) -* Layer 2 - [BC Gov Traction Agency Governance Framework](https://github.com/bcgov/bc-vcpedia/wiki/(Traction-Showcase-Layer-2)-BC-Gov-Traction-Agency-Governance-Framework) - - -## Objectives - -The objectives of the OpenClimate Ecosystem Governance Framework for a Scope 1 GHG Emissions credential is the following: -Account for Scope 1 GHG Emissions Credentials -- Open Climate wants to account for Corporate GHG emissions -- Expand the capacity for Corporate GHG emissions-accounting through cryptographically verifiable credentials at the facility or point-source level -- Enable companies to attract investors and signal low carbon products through GHG emissions standard reporting -Incentivize Compliance -- The OpenClimate Ecosystem Governance Framework seeks to incentivize compliance with GHG accounting rules amongst participants. -- Enable a chain of trust through legal entities, credential issuers and governance authorities. -- Support further levels of delegated identifiers and associated Verifiable Credentials to provide scalability. -- Enable an integrated nested accounting framework through the use of facility-level emissions reporting so as to include corporate data in subnational and national emissions inventories -Enable new Use Cases -- The establishment of an OpenClimate Governance Framework will incentivize wider adoption of decentralized trust technology for verifiable credentials - -## Principles - -1) Sustainability -2) Stewardship -3) Public good -4) Transparency -5) Citizen Engagement -6) Digital Sovereignty -7) Security -8) Confidence -9) Synchronization - -## Privacy - -* Privacy and Minimal Disclosure: The OpenClimate Ecosystem SHALL protect digital data to ensure the privacy of OpenClimate Ecosystem Members. -* The OpenClimate Ecosystem SHALL require members explicit intention or consent for each use of digital data. -* The OpenClimate Ecosystem Members SHALL enjoy all the data rights and protections provided under relevant legislation and policy. -* OpenClimate Ecosystem Members SHALL fulfill all the data duties and obligations as required by the Governance Framework. - - - -## Business Requirement - OpenClimate and The Company - -OpenClimate will have a connection with the Business Wallet of Copper Mountain Mine to facilitate interaction from a business requirement side. There is currently a business agreement between Copper Mountain Mine and OpenClimate. The Business wallet will facilitate a secure connection and is a “registered business”. - -Verifiable Credentials process will involve the following: - -(a) Scope 1 GHG Emissions credential - -Reported GHG emissions data is included in a Layer 3 ToIP governance document outlining standards and business requirements related to CAS (Climate Action Secretariat) acting as an issuer for GHG Emissions Credentials Data. - - -## Technical Requirements - -1) User/system of business wallet initiates presentation proposal with emissions data -2) OC wallet auto accepts the proposal -3) OC reads attributable data and loads into database - -A mechanism will be developed to save the raw data and check the validity - -1. All GHG Emissions Credentials MUST maintain an entity status of Active and a GHG registration status other than Lapsed, Retired, Duplicate, Annulled or Merged -2. All issuers of credentials MUST verify that a Holder’s Automatic Identifier is controlled by the holder -3. All _______ MUST have executed a GHG Emission issuer Qualification Agreement -4. All ________ MUST successfully complete a GHG Emission issuer Qualification -5. Open Earth MUST publish the GHG Ecosystem Governance Framework on OpenEarth.org and follow the policies in the revision section for all revisions of the OpenClimate Ecosystem Governance Framework -6. GHG Emissions Credentials MUST be revocable following the policies specified in the OpenClimate Ecosystem Governance Framework -7. MUST ensure that third parties comply with the Open Earth Governance Frameworks when providing ____________services to a __________. - - -### Presentation definitions -DIF-compliant Presentation Definitions following (https://identity.foundation/presentation-exchange/) that are used are registered at the following locations: -1. Educational Achievement Query v1.0, where id is: ______ and the definition is at: -1. ______ , where the id is: ______ and the definition is at: - -#### Example Proof Request -``` - proof_req = { - "requested_attributes": [ - { - "name": "degree", - "restrictions": [{"cred_def_id": faber.cred_def_id}], - }, - { - "name": "date", - "restrictions": [{"cred_def_id": faber.cred_def_id}], - }, - ], - "requested_predicates": [ - { - "name": "age", - "p_type": ">", - "p_value": 18, - "restrictions": [{"cred_def_id": faber.cred_def_id}], - } - ], - } -``` - - - -## Changing the OpenClimate Rules - -The **OpenClimate Ecosystem Rules** can change for the following reasons: -1. Changes in laws or regulations -2. Changes proposed by the existing community -3. Changes proposed by potential new community members. - - -## Revisions - -1. Any OpenClimate Ecosystem Member MUST be able to propose a change to, or translation of the OpenClimate Ecosystem Rules by contacting the administrative authority e.g. by emailing martin@openearth.org -2. Any participant in the OpenClimate Ecosystem SHOULD be able to propose a change to the OpenClimate Rules by contacting the administering authority e.g. by emailing martin@openearth.org -3. The administering authority MUST implement a change process as specified in the Governance Requirements controlled document. -4. The OpenClimate Ecosystem Rules SHOULD be reviewed if an issuer of Scope 1 GHG Emissions Credentials Data requests it -5. The OpenClimate Ecosystem Rules MUST be reviewed if anything in the OpenClimate Rules is found to be in breach of the law within the legal jurisdiction of the USA or Canada. -6. The OpenClimate Ecosystem Rules MUST be reviewed if there are changes to the legal jurisdiction in which the administering authority or the OpenClimate platform operator are registered. -7. The OpenClimate Ecosystem Rules MUST be reviewed if there are changes in applicable law, for example data protection law, within the legal jurisdiction of the Open Earth Rules which is the USA. -8. The OpenClimate Ecosystem Rules MUST be reviewed if there are substantive changes to the functionality of the OpenClimate platform. -9. The OpenClimate Ecosystem Rules MUST be reviewed if the actions or transactions, especially those associated with risk decisions or the control of digital data, which are currently carried out by human actors are replaced with automation and decision-making by non-human actors. For example, machine-readable governance. -10. The OpenClimate Ecosystem Rules MUST be reviewed if the OpenClimate objectives change (adding, changing and/or removing them). -11. The OpenClimate Ecosystem Rules MUST be reviewed as a result of a risk assessment process, a new threat or high risk or significant harm is identified which arises from the implementation of the Open Earth Rules or which can be treated through a revision of the Open Earth Rules. -12. The OpenClimate Ecosystem Rules MUST be reviewed a change proposed by an OpenClimate Ecosystem member successfully completes the change process as defined by the administering authority. -13. Revisions of the OpenClimate Rules SHOULD be compliant with the ToIP Metamodel and MAY be reviewed by members of the Trust over IP Foundation. -14. If any revisions to the rules are made, they should be communicated to participants, users and trusted issuers and the governing authority of the Scope 1 GHG Governance Framework authority through email. - -## Extensions - -1) OpenEarth welcomes other Governance Frameworks to leverage the OpenClimate Ecosystem Framework but does not anticipate the need at this time to specify formal extensions from other external Governance Frameworks that will leverage the OpenClimate Ecosystem Governance Framework -2) The Open Climate Ecosystem Framework is extended by the following internal governance framework: OpenEarth Identifier Governance Frameworks and GHG Emissions Credential Governance Frameworks. - - -## Inclusion, Equitability and Accessibility Requirements - - -OpenEarth must design the OpenClimate Ecosystem to be able to make credentials available to any legal entity issued a GHG Credential in the OpenClimate Ecosystem. - -## Schedule of Controlled Documents - -DID URLS for all documents will be published with the Draft of the Ecosystem Governance Framework -This Draft can be viewed at ________________________- - -**Glossary** -Verifiable Scope 2 and 3 GHG Open Climate Ecosystem Governance Framework Glossary is a document that lists all defined terms have been referenced in the Open Earth Documents - -**Risk Assessment** -Verifiable GHG Emissions Credentials Risk Assessment is a ______________ that assesses certain risk categories regarding the operation of the Open Climate Ecosystem and Infrastructure - -**Trust Assurance and Certification** -Verifiable GHG Emissions Credentials Governance Framework Trust Assurance is a spreadsheet that focuses on MUST statements within other GHG Emissions Governance documents and specifies the services/processes that will be used to evaluate compliance with these statements - -**Governance Requirements** -1. The governance of the Open Earth GHG Ecosystem can be found -at __________________________ -2. The Memorandum of Understanding between the Open Earth and______________ -can be found at ________________ -3. The Charter of the _______________can be downloaded as a ____________ -4. The Statutes of Open Earth can be downloaded as a pdf, ______________ -5. The By-laws of ____________ can be downloaded as a pdf,____________ -6. Open Climate has a Board of independent directors, -7. The Open Climate standard, ISO 17442-1:2020 Financial services – Legal entity identifier (LEI) – -Part 1: Assignment can be found here: ___________________ - diff --git a/docs/resources/bc-vcpedia/credentials/_pilots/bc-ghg-emissions-verification.md b/docs/resources/bc-vcpedia/credentials/_pilots/bc-ghg-emissions-verification.md deleted file mode 100644 index 99aa37d5..00000000 --- a/docs/resources/bc-vcpedia/credentials/_pilots/bc-ghg-emissions-verification.md +++ /dev/null @@ -1,187 +0,0 @@ ---- -layout: default -title: BC GHG Emissions Report Verification -parent: Credentials ---- - -# BC GHG Emissions Report Verification Statement Credential - DRAFT - -# 1. Primary Document - -## 1.1. Introduction -This document articulates the governance framework for the BC Greenhouse Gas (GHG) Emissions Report Verification Statement credential. GHG Emissions reporting is required in British Columbia (BC) as per the Greenhouse Gas Industrial Reporting and Control Act, **[GREENHOUSE GAS EMISSION REPORTING REGULATION](https://www.bclaws.gov.bc.ca/civix/document/id/complete/statreg/249_2015)**. - -BC Regulation [249/2015: GREENHOUSE GAS EMISSION REPORTING REGULATION](https://www.bclaws.gov.bc.ca/civix/document/id/complete/statreg/249_2015) sets out reporting requirements that are developed in accordance with various standard setting bodies. Section 33 specifically references the [International Accreditation Forum ((IAF)](https://iaf.nu/en/home/). Other sections within the regulation also refer to provisions being drafted in accordance with the [International Organization for Standardization (ISO)](https://www.iso.org/home.html), [Western Climate Initiative (WCI)](http://westernclimateinitiative.org/) the [Canadian Standards Association (CSA)](https://www.csagroup.org/) and the [National Institute of Standards and Technology (NIST)](https://www.nist.gov/). - -Current guidelines for reporting are described here: https://www2.gov.bc.ca/gov/content/environment/climate-change/industry/reporting/verify - -The development of this documentation follows the governance framework created by the [Trust over IP Foundation (ToIP)](https://trustoverip.org/) [Governance Metamodel Specification](https://trustoverip.org/wp-content/uploads/ToIP-Governance-Metamodel-Specification-V1.0-2022-12-21.pdf) created by the [Governance Stack Working Group (GSWG)](https://wiki.trustoverip.org/display/HOME/Governance+Stack+Working+Group). - -These materials are made available under and are subject to the [Creative Commons Attribution 4.0 International license](http://creativecommons.org/licenses/by/4.0/legalcode). - -THESE MATERIALS ARE PROVIDED “AS IS.” The Trust Over IP Foundation, established as the Joint Development Foundation Projects, LLC, Trust Over IP Foundation Series ("ToIP"), and its members and contributors (each of ToIP, its members and contributors, a "ToIP Party") expressly disclaim any warranties (express, implied, or otherwise), including implied warranties of merchantability, non-infringement, fitness for a particular purpose, or title, related to the materials. The entire risk as to implementing or otherwise using the materials is assumed by the implementer and user. - -IN NO EVENT WILL ANY ToIP PARTY BE LIABLE TO ANY OTHER PARTY FOR LOST PROFITS OR ANY FORM OF INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES OF ANY CHARACTER FROM ANY CAUSES OF ACTION OF ANY KIND WITH RESPECT TO THESE MATERIALS, ANY DELIVERABLE OR THE ToIP GOVERNING AGREEMENT, WHETHER BASED ON BREACH OF CONTRACT, TORT (INCLUDING NEGLIGENCE), OR OTHERWISE, AND WHETHER OR NOT THE OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. - -***Acknowledgements*** - -This governance framework includes structural elements from the Trust over IP Metamodel that were developed by Governance Stack Working Group of the Trust over IP Foundation, the eSSIF Lab Glossary and Mental Models, were contributed to the Trust Over IP Foundation under the CC BY-SA 4.0 license. There have also been contributions from the Concepts & Terminology Working Group at ToIP, the Human Experience Working Group at ToIP and the Ecosystem Foundry Working Group at ToIP, the work of the Governance Framework Working Group at Sovrin Foundation is also acknowledged in providing support. - -## 1.2. Terminology and Notation - -[Glossary - General Trust Over IP Terms](https://trustoverip.github.io/toip/glossary) - -**Requirements** include any combination of Machine-Testable Requirements and Human-Auditable Requirements. Unless otherwise stated, all Requirements MUST be expressed as defined in [RFC 2119](https://www.rfc-editor.org/rfc/rfc2119). - -- Mandates are Requirements that use a MUST, MUST NOT, SHALL, SHALL NOT or REQUIRED keyword. -- Recommendations are Requirements that use a SHOULD, SHOULD NOT, or RECOMMENDED keyword. -- Options are Requirements that use a MAY or OPTIONAL keyword. - -**Machine-Testable Requirements** are those with which compliance can be verified using an automated test suite and appropriate scripting or testing software. - -**Rules** are Machine-Testable Requirements that are written in a Machine-Readable language and can be processed by a Rules Engine. They are expressed in a structured rules language as specified by the Governance Framework. - -**Human-Auditable Requirements** are those with which compliance can only be verified by an audit of people, processes, and procedures. - -**Policies** are Human-Auditable Requirements written using standard conformance terminology. The Policies used in the Governance Framework will use the standard terminology detailed in RFC 2119 keywords. Note that all RFC 2119 keywords have weight from an auditing perspective. An implementer MUST explain why a SHOULD or RECOMMENDED requirement was not implemented and SHOULD explain why a MAY requirement was implemented. - -**Specifications** are documents containing any combination of Machine-Testable Requirements and Human-Auditable Requirements needed to produce technical interoperability. - -## 1.3. Localization - -The standard language for this governing framework is American English. -  -## 1.4. Governing Authority - -[BC Climate Action Secretariat (CAS)](https://www2.gov.bc.ca/gov/content/environment/climate-change) is the Governing Authority and party legally responsible for developing, maintaining and implementing the Governance Framework (GF). -The contact for petitioners and relying parties of this GF during the pilot phase of the project is: -* **Name:** Kyle Robinson -* **Title:** Senior Strategic Advisor, Digital Trust Ecosystems -* **Organization:** Briartech Consulting Inc. -* **Email:** [kyle.robinson@briartech.ca](mailto:kyle.robinson@briartech.ca) - -## 1.5. Administering Authority -[Energy, Mines and Digital Trust (EMDT)](https://digital.gov.bc.ca/case-studies/emdt) is the Administering Authority on behalf of the Tenure and Resource Stewardship Branch during the pilot phase of development. - -## 1.6. Purpose - -This BC Greenhouse Gas (GHG) Emissions Report Verification Statement credential under the governing authority of CAS reports emissions information as required by the Greenhouse Gas Industrial Reporting and Control Act, [GREENHOUSE GAS EMISSION REPORTING REGULATION](https://www.bclaws.gov.bc.ca/civix/document/id/complete/statreg/249_2015). The purpose of this governance framework is to outline the process associated with governance, issuance, verification, and revocation of a GHG Emissions Report Verification Statement credential. - -## 1.7. Scope - -The governance framework only covers the BC GHG Emissions Verification Statement Credential. - -## 1.8. Objectives -TBD - -_This section states the high-level outcomes desired by the trust community through its adoption of the GF._ - -1. SHOULD specify tangible, achievable results (e.g. SMART criteria and Fit-for-Purpose criteria). -2. MUST only contain outcomes over which the GF has the authority and mechanisms to achieve within its -scope. -3. MUST be consistent with the principles of the GF (below). - -## 1.9. Principles - -BC Climate Action Secretariat has identified the following guiding principles in their [Climate Preparedness and Adaptation Strategy 2022-2025](https://www2.gov.bc.ca/assets/gov/environment/climate-change/adaptation/cpas.pdf): - -1) Build a Shared Path to Climate Resilience with Indigenous Peoples -2) Take an Equity Informed Approach -3) Enhance Health and Well Being for All -4) Promote Nature Based Solutions to Enhance Community Resilience -5) Align Emissions Reduction with Climate Adaption -6) Take a Proactive Approach with a Business Case for Adaptation - -## 1.10. General Requirements - -When large emitters of CO2 report annual emissions to the [BC Climate Action Secretariat (CAS)](https://www2.gov.bc.ca/gov/content/environment/climate-change), an Emissions Report Verification Statement must be provided as part of the reporting requirements. - -## 1.11. Revisions -Version 1.0 - -## 1.12. Extensions -There are no extensions to this Governance Framework. - -## 1.13. Schedule of Controlled Documents -N/A - -# 2. Controlled Documents - -## 2.1. Glossary -TBD - -## 2.2. Risk Assessment -TBD - -## 2.3. Trust Assurance and Certification -TBD - -## 2.4. Governance Requirements -TBD - -## 2.5. Business Requirements -The primary use of the BC GHG Emissions Verification Statement Credential is to verify GHG emissions reporting to CAS. - -## 2.6. Technical Requirements - -### 2.6.1 Schema Definition - -Schema Name: ghg.verification.statement - -Schema Version: 1.0 - -This schema definition follows the AnonCreds specification (https://anoncreds-wg.github.io/anoncreds-spec/) - -Attribute | Format | Rules | Notes ---- | --- | --- | --- -verification_body_name | String | Not NULL | Regulation s.33(2)(a) [Verification Body name. Include full legal company name. Trade name may be referenced in parentheses if applicable. ISO 14065 and ISO 17011] -verification_body_address | String | Not NULL | Regulation s.33(2)(a) [Business Address] -accreditation | String | Not NULL | Regulation s.33(2)(h) [Name of member of the International Accreditation Forum (IAF) and associated identification number. ISO14065:2013 ISO14064-3:2019] -accreditation_status | String | Not NULL | Regulation s.33(2)(h) [Affirm accreditation status with the IAF is in good standing. ISO14065:2013 ISO14064-3:2019] -lead_verifier_name | String | Not NULL | Regulation s.33(2)(b) [Lead Verifier’s name ISO14064-1:2018 ISO14064-3:2019] -lead_verifier_email | String | Not NULL | Regulation s.33(2)(b) [Lead Verifier’s business email ISO14064-1:2018 ISO14064-3:2019] -lead_verifier_phone | String | Not NULL | Regulation s.33(2)(b) [Lead Verifier’s telephone ISO14065:2013 ISO14064-3:2019] -audit_standard | String | Not NULL | Regulation s.33(2)(h) [Affirm audit standard used by verifier. ISEA 3410 ISO14064-3:2019] -independent_peer_reviewer_name | String | Not NULL | Regulation s.33(2)(l) [Peer Reviewer’s name ISO14064-3:2019] -independent_peer_reviewer_email | String | Not NULL | Regulation s.33(2)(l) [Peer Reviewer’s business email ISO14064-3:2019] -independent_peer_reviewer_phone | String | Not NULL | Regulation s.33(2)(l) [Peer Reviewer’s telephone ISO14064-3:2019] -reporting_operation | String | Not NULL | Regulation s.33(2)(d) [Legal name of the Reporting Operation ISO14064-1:2018 ISO14064-3:2019] -name_of_facility | String | Not NULL | Regulation s.33(2)(d) [For Single Facility Operations the name of the Facility. Include N/A if not applicable. ISO14064-1:2018 ISO14064-3:2019] -facility_type | String | Not NULL | [Single Facility Operation, Linear Facilities Operation, or Electricity Import Operation. ISO14064-1:2018 ISO14064-3:2019] -facility_address | String | Not NULL | Regulation s.33(2)(d) [For Single Facility Operations, the geographic coordinates and street address of the Facility. Include N/A if not applicable.ISO14064-1:2018 ISO14064-3:2019] -facility_longitude | String | Not NULL | Regulation s.33(2)(d) [For Single Facility Operations, the geographic coordinates and street address of the Facility. Include N/A if not applicable.ISO14064-1:2018 ISO14064-3:2019] -facility_latitude | String | Not NULL | Regulation s.33(2)(d) [For Single Facility Operations, the geographic coordinates and street address of the Facility. Include N/A if not applicable. ISO14064-1:2018 ISO14064-3:2019] -total_emissions | String | Not NULL | Total Emissions Attributable to the Reporting Operation during the Reporting Period. [#] tonnes CO2e ISO14064-2:2019 -total_emissions_not_reporting_only | String | Not NULL | Total Emissions that are not Reporting-Only Emissions Attributable to the Reporting Operation during the Reporting Period. [#] tonnes CO2e. ISO14064-2:2019 -total_emissions_reporting_only | String | Not NULL | Total Reporting-Only Emissions Attributable to the Reporting Operation during the Reporting Period. [#] tonnes CO2e. ISO14064-2:2019 -total_co2_from_nonbiomass| String | Not NULL | Total amount of carbon dioxide from non-Biomass that is Attributable to the Reporting Operation during the Reporting Period. [#] tonnes CO2. ISO14064-2:2019 -total_co2_from_nonbiomass_not_schedule_c | String | Not NULL | Total amount of carbon dioxide from Biomass not listed in Schedule C of the Regulation that is Attributable to the Reporting Operation during the Reporting Period: [#] tonnes CO2. ISO14064-2:2019 -total_co2_from_nonbiomass_in_schedule_c| String | Not NULL | Total amount of carbon dioxide from Biomass listed in Schedule C of the Regulation Attributable to the Reporting Operation during the Reporting Period: [#] tonnes CO2. ISO14064-2:2019 - - - -### 2.6.2. Credential Implementation -Ledger | SCHEMA DEF | CRED DEF | Notes ---- | --- | --- | --- -BCovrin Test | ADCssx1nPW6FQwNHTFTRNW:2:BC_GHG_Emissions_Report_Verification_Statement:1.0 | --- | --- - -## 2.7. Information Trust Requirements -The [Freedom of Information and Protection of Privacy Act](https://www.bclaws.gov.bc.ca/civix/document/id/complete/statreg/96165_00) sets out the access and privacy rights of individuals as they relate to the public sector in British Columbia. - -## 2.8. Inclusion, Equitability, and Accessibility Requirements - -The [Accessible British Columbia Act](https://www.bclaws.gov.bc.ca/civix/document/id/complete/statreg/21019) informs [**AccessibleBC**](https://www2.gov.bc.ca/gov/content/governments/about-the-bc-government/accessibility/legislation/accessiblebc) - -The [Diversity & Inclusion Strategy for the BC Public Service](https://www2.gov.bc.ca/gov/content/careers-myhr/about-the-bc-public-service/diversity-inclusion/diversity-inclusion-strategy) outlines the committments of BC govenment in supporting inclusion, equitability and access throughout the province. - -## 2.9. Legal Agreements -TBD - -# End of Document - - diff --git a/docs/resources/bc-vcpedia/credentials/_pilots/bc-law-society-membership.md b/docs/resources/bc-vcpedia/credentials/_pilots/bc-law-society-membership.md deleted file mode 100644 index ceca5bac..00000000 --- a/docs/resources/bc-vcpedia/credentials/_pilots/bc-law-society-membership.md +++ /dev/null @@ -1,9 +0,0 @@ ---- -layout: default -title: BC Law Society -parent: Credentials ---- - -Issuer DID - -BC Law Society https://www.lawsociety.bc.ca/ diff --git a/docs/resources/bc-vcpedia/credentials/_pilots/bc-petroleum-natural-gas-title.md b/docs/resources/bc-vcpedia/credentials/_pilots/bc-petroleum-natural-gas-title.md deleted file mode 100644 index 59f57bed..00000000 --- a/docs/resources/bc-vcpedia/credentials/_pilots/bc-petroleum-natural-gas-title.md +++ /dev/null @@ -1,195 +0,0 @@ ---- -layout: default -title: BC Petroleum & Natural Gas Title -parent: Credentials ---- - -# BC Petroleum & Natural Gas Title Credential - DRAFT -# 1. Primary Document - -## 1.1 Introduction - -The majority of subsurface petroleum and natural gas (PNG) resources in British Columbia (BC) are owned by the Province. By entering into a tenure agreement with the Province, private industry can develop these resources. Tenure agreements are the mechanism used by the Province to give rights to petroleum and natural gas resources through issuance of Petroleum and Natural Gas Titles. - -Further information can be found on the [BC Government Petroleum and Natural Gas Tenure Site](https://www2.gov.bc.ca/gov/content/industry/natural-gas-oil/petroleum-natural-gas-tenure). - -The following legislation and regulations govern the disposition, administration and management of petroleum and natural gas in BC: - -* [The Petroleum and Natural Gas Act (PNG Act)](https://www.bclaws.gov.bc.ca/civix/document/id/complete/statreg/00_96361_01) -* [The Petroleum and Natural Gas Act Regulations](https://www.bclaws.gov.bc.ca/civix/content/complete/statreg/1922970521/96361/reg96361/?xsl=/templates/browse.xsl) -* [Petroleum and Natural Gas Tenure Policy Guides](https://www2.gov.bc.ca/gov/content/industry/natural-gas-oil/petroleum-natural-gas-tenure/publications) - -The development of this documentation follows the governance framework created by the [Trust over IP Foundation (ToIP)](https://trustoverip.org/) [Governance Metamodel Specification](https://trustoverip.org/wp-content/uploads/ToIP-Governance-Metamodel-Specification-V1.0-2022-12-21.pdf) created by the [Governance Stack Working Group (GSWG)](https://wiki.trustoverip.org/display/HOME/Governance+Stack+Working+Group). - -These materials are made available under and are subject to the [Creative Commons Attribution 4.0 International license](http://creativecommons.org/licenses/by/4.0/legalcode). - -THESE MATERIALS ARE PROVIDED “AS IS.” The Trust Over IP Foundation, established as the Joint Development Foundation Projects, LLC, Trust Over IP Foundation Series ("ToIP"), and its members and contributors (each of ToIP, its members and contributors, a "ToIP Party") expressly disclaim any warranties (express, implied, or otherwise), including implied warranties of merchantability, non-infringement, fitness for a particular purpose, or title, related to the materials. The entire risk as to implementing or otherwise using the materials is assumed by the implementer and user. - -IN NO EVENT WILL ANY ToIP PARTY BE LIABLE TO ANY OTHER PARTY FOR LOST PROFITS OR ANY FORM OF INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES OF ANY CHARACTER FROM ANY CAUSES OF ACTION OF ANY KIND WITH RESPECT TO THESE MATERIALS, ANY DELIVERABLE OR THE ToIP GOVERNING AGREEMENT, WHETHER BASED ON BREACH OF CONTRACT, TORT (INCLUDING NEGLIGENCE), OR OTHERWISE, AND WHETHER OR NOT THE OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. - -***Acknowledgements*** - -This governance framework includes structural elements from the Trust over IP Metamodel that were developed by Governance Stack Working Group of the Trust over IP Foundation, the eSSIF Lab Glossary and Mental Models, were contributed to the Trust Over IP Foundation under the CC BY-SA 4.0 license. There have also been contributions from the Concepts & Terminology Working Group at ToIP, the Human Experience Working Group at ToIP and the Ecosystem Foundry Working Group at ToIP, the work of the Governance Framework Working Group at Sovrin Foundation is also acknowledged in providing support. -## 1.2. Terminology and Notation - -Please reference [Glossary - General Trust Over IP Terms](https://trustoverip.github.io/toip/glossary). - -**Requirements** include any combination of Machine-Testable Requirements and Human-Auditable Requirements. Unless otherwise stated, all Requirements MUST be expressed as defined in [RFC 2119](https://www.rfc-editor.org/rfc/rfc2119). - -- Mandates are Requirements that use a MUST, MUST NOT, SHALL, SHALL NOT or REQUIRED keyword. -- Recommendations are Requirements that use a SHOULD, SHOULD NOT, or RECOMMENDED keyword. -- Options are Requirements that use a MAY or OPTIONAL keyword. - -**Machine-Testable Requirements** are those with which compliance can be verified using an automated test suite and appropriate scripting or testing software. - -**Rules** are Machine-Testable Requirements that are written in a Machine-Readable language and can be processed by a Rules Engine. They are expressed in a structured rules language as specified by the Governance Framework. - -**Human-Auditable Requirements** are those with which compliance can only be verified by an audit of people, processes, and procedures. - -**Policies** are Human-Auditable Requirements written using standard conformance terminology. The Policies used in the Governance Framework will use the standard terminology detailed in RFC 2119 keywords. Note that all RFC 2119 keywords have weight from an auditing perspective. An implementer MUST explain why a SHOULD or RECOMMENDED requirement was not implemented and SHOULD explain why a MAY requirement was implemented. - -**Specifications** are documents containing any combination of Machine-Testable Requirements and Human-Auditable Requirements needed to produce technical interoperability. - -## 1.3. Localization - -The standard language for this governing framework (GF) is English. - -## 1.4 Governing Authority - -[The Tenure and Resource Stewardship Branch (TRSB)](https://www2.gov.bc.ca/gov/content/industry/natural-gas-oil/petroleum-natural-gas-tenure) is the governing authority responsible for this Governance Framework (GF). - -## 1.5. Administering Authority - -[Energy and Mines Digital Trust (EMDT)](https://digital.gov.bc.ca/case-studies/emdt) is the Administering Authority on behalf of the Tenure and Resource Stewardship Branch (TRSB) during the pilot phase of development. - -The contact information for EMDT is: -* **Name:** Kyle Robinson -* **Title:** Senior Strategic Advisor, Digital Trust Ecosystems -* **Organization:** Briartech Consulting Inc. -* **Email:** [kyle.robinson@briartech.ca](mailto:kyle.robinson@briartech.ca) - -## 1.6 Purpose - -The purpose of this Governance Framework (GF) is to define the parameters of a BC Petroleum and Natural Gas Title credential. - -## 1.7 Scope - -This Governance Framework (GF) applies to the BC Petroleum and Natural Gas Title credential from [the Tenure and Resource Stewardship Branch](https://www2.gov.bc.ca/gov/content/industry/natural-gas-oil/petroleum-natural-gas-tenure). - -## 1.8 Objectives - -This GF describes the BC Petroleum and Natural Gas Title credential consisting of all data elements included in a BC Petroleum and Natural Gas Title Document. - -## 1.9 Principles - -[The BC Public Service](https://www2.gov.bc.ca/gov/content/careers-myhr/about-the-bc-public-service/ethics-standards-of-conduct/corporate-values) has one overarching corporate value, __Integrity__, and 6 core corporate values: Curiosity, Service, Passion, Teamwork, Accountability, and Courage. __Integrity__ is placed above all the other values as a quality that affirms the [Standards of Conduct for the BC Public Service](https://www2.gov.bc.ca/gov/content/careers-myhr/about-the-bc-public-service/ethics-standards-of-conduct/standards-of-conduct). - -## 1.10 General Requirements - -The Petroleum and Natural Gas Title Credential MUST be issued by the Ministry of Energy, Mines and Low Carbon Innovation (EMLI) Tenure and Resource Stewardship Branch. When petroleum and natural gas operators wish to obtain a Petroleum and Natural Gas Title in BC, a Petroleum and Natural Gas Title Document must be provided in accordance with the BC Petroleum and Natural Gas Act. - -## 1.11. Revisions - -Version 1.0. - -## 1.12. Extensions - -There are no extensions to this Governance Framework. - -## 1.13. Schedule of Controlled Documents - -TBD - -# 2. Controlled Documents - -## 2.1. Glossary -[ToIP Core Glossary](https://trustoverip.github.io/toip/glossary) - -[BC Petroleum and Natural Gas Act Definitions](https://www.bclaws.gov.bc.ca/civix/document/id/complete/statreg/00_96361_01#section1) - -* **Credential Holders**: BC Petroleum and Natural Gas Operators -* **Title Holder**: A person and/or a company in whose name a PNG title document is recorded in the division records - - -## 2.2. Risk Assessment -TBD - -## 2.3. Trust Assurance and Certification -TBD - -## 2.4. Governance Requirements -The BC Tenure and Resource Stewardship Branch (TRSB) updates and manages this credential governance framework. - -Legislation and regulations govern the disposition, administration and management of petroleum and natural gas. These can be found in the [BC Petroleum and Natural Gas Act (PNG Act)](https://www.bclaws.gov.bc.ca/civix/document/id/complete/statreg/00_96361_01). - -## 2.5. Business Requirements - -The primary use of the Petroleum and Natural Gas Title Credential is to allow holders in BC to comply with required processes and procedures associated with maintaining a Petroleum and Natural Gas Title within the province. The Petroleum and Natural Gas Title Credential will be issued by the Ministry of Energy and Mines, Tenure and Resource Stewardship Branch. All users of the BC Petroleum and Natural Gas Title Credential must adhere to provincial legislation and requirements. - -## 2.6. Technical Requirements (Credential) -The Verifiable Credential format for this credential is AnonCreds specification (https://wiki.hyperledger.org/display/anoncreds) - -## 2.6.1 Schema Definition - -__Schema Name:__ png.title - -__Schema Version:__ 1.0 - -This schema definition follows the AnonCreds specification (https://wiki.hyperledger.org/display/anoncreds) - -Name | Attribute | Format | Rules | Notes ---- | --- | --- | --- | --- | -Title Number | title_number | String | not NULL | A number is used to uniquely identify a title, assigned based on administrative policy by the TRSB. The title number is associated with the Exploration Licence outlined in [Section 126, part 14.126 of the PNG Act](https://www.bclaws.gov.bc.ca/civix/document/id/complete/statreg/96361_01#section126) -Title Type | title_type | String | not NULL | This field specifies the type of title based on the [PNG Act](https://www.bclaws.gov.bc.ca/civix/document/id/complete/statreg/96361_01). Title types can include the following: **1. Lease** ([Part 6](https://www.bclaws.gov.bc.ca/civix/document/id/complete/statreg/96361_01#part6)); **2. Permit** ([Part 5](https://www.bclaws.gov.bc.ca/civix/document/id/complete/statreg/96361_01#part5)); **3. Drilling Licence** ([Part 5.1](https://www.bclaws.gov.bc.ca/civix/document/id/complete/statreg/96361_01#part5.1)), and **4. Storage Reservoir Licence** ([Part 14.130](https://www.bclaws.gov.bc.ca/civix/document/id/complete/statreg/96361_01#section130)). Each title has only one title type. -Issue Date | issue_date | String | not NULL| The date when a title is issued, format is YYYY-MM-DD. Section 64 of the [PNG Act](https://www.bclaws.gov.bc.ca/civix/document/id/complete/statreg/96361_01#section64) -Effective Date | effective_date | String | not NULL | The date when the title becomes effective, format YYYY-MM-DD. This date usually follows after an issuance date and signals the start of a title period. This date does not change. -Term | term | String | not NULL | This describes the length of time (term) granted for each title, expressed in YYYY. This date does not change. -Expiry Date | expiry_date | String | not NULL | Expiry date is defined as effective date plus term, expressed as YYYY-MM-DD. This date signals the end of the title period. -Area | area | String | not NULL | This attribute is the surface area in planned use, measured in hectares. This includes 3 dimensional layers. -Title Holders | title_holders| String | not NULL | The [PNG Act](https://www.bclaws.gov.bc.ca/civix/document/id/complete/statreg/96361_01#section130) describes a "holder of a location" as meaning "in accordance with the context, a permittee, licensee" . In this credential, the term title holder is used to reference a person in whose name a PNG title document is recorded in the division records. Title holders can be registered companies, and/or persons. A Title Holder will hold a percentage (%) interest in the title. Percent interest defines the percentage of interest allotted to each party named in the PNG title document. Percentage of ownership can be divided up to eight digits and should always equal 100% total. Lessee is defined by [the PNG Act](https://www.bclaws.gov.bc.ca/civix/document/id/complete/statreg/96361_01) as "a person in whose name a lease is recorded in the division records". -Tracts | tracts | String | not NULL | A **Tract** is an area of land within a title defined by locations sharing identical rights. This attribute has all of the tract(s) information contained within a title. See *Tracts Appendix* below for a detailed description of the information included. -Caveats | caveats | String | not NULL | Caveats provide information and guidance to the tenure holder that will assist in activity planning by identifying potential access restrictions. Caveats will also flag concerns identified through pre-tenure consultation and may recommend engagement with First Nations, stakeholders, and other agencies as appropriate. Caveats often point to relevant statute and policy and are not binding or enforced by the Ministry. - -__**Tracts Appendix**__ -* **Tract Numbers** On all title documents is a heading which is the Tract Number. Tract Numbers are unique identifying numbers for each tract. Tracts are an administrative device to organize all title locations sharing identical rights into separate groupings. -* **Tract Locations** Following the Tract Number is a description of Tract Location. Tract Location outlines the precise location for a tract listed on a PNG title document using specific attributes from one of two land survey systems currently in use within BC. -* **Tract Rights** Following Tract Location is a description called Tract Rights. This section defines rights as either "Included (I)" or "Excluded (E)". Zone names are coded "Petroleum (P)" "Petroleum Natural Gas (PNG)" (or other relevant codes). Each right will be denoted by its corresponding letter. This section outlines the rights associated with each individual tract listed on a PNG title document. This would be linked with a BC business number (i.e. BC123456). Tract rights are identified using specific Code Lists. There are Stratigraphic Codes (used to define tract rights) and Standard Zone Designations. -* **Tract Notes** Following the description of Tract Rights is a section called Tract Notes. Tract Notes outlines specific notes or points associated with each tract. Definitions of zones used in tract rights reference specific depth intervals in the type well named in the same note. These are used to describe the type wells and the intervals in the type wells that are used to create the type. -* **Stratigraphic Codes** are used to define tract rights and outline the following types of information: 1. Strata Zone Codes; 2. Descriptions; 3. Effective Dates; and 4. Expiry Dates. -* **Standard Zone Designations** Following the Stratigraphic Codes, Standard Zone Designations describe the different ways by which a zone can be designated for use, defining intervals as either feet or meters. Next, the log type is identified followed by the well permit number. These codes outline 1. a standard 5-digit code; 2. descriptions of this code including geographical areas and details; 3. shortened descriptions of these details; 4. effective dates; and 6. expiry dates. -* **List of Stratigraphic Zone Codes used:** - * TT = To Top Of - * TB = To Base Of - * SE = Special Exclusion - * IN = In - * FT = From Top Of - * FB = From Base Of - * DT = Down to Top Of - * DB = Down to Base of - * BT = Below Top Of - * BB = Below Base Of - * AZ = All Zones - -### 2.6.2. Credential Implementation -Ledger | SCHEMA DEF | ---- | --- | -BCovrin Test | 4uVA6nbXMGWYLE6hq99aDa:2:BC Petroleum and Natural Gas Title:1.0 | - -## 2.7. Information Trust Requirements - -The [Freedom of Information and Protection of Privacy Act](https://www.bclaws.gov.bc.ca/civix/document/id/complete/statreg/96165_00) sets out the access and privacy rights of individuals as they relate to the public sector in British Columbia. - -## 2.8. Inclusion, Equitability, and Accessibility Requirements - -The [Accessible British Columbia Act](https://www.bclaws.gov.bc.ca/civix/document/id/complete/statreg/21019) informs [**AccessibleBC**](https://www2.gov.bc.ca/gov/content/governments/about-the-bc-government/accessibility/legislation/accessiblebc) - -The [Diversity & Inclusion Strategy for the BC Public Service](https://www2.gov.bc.ca/gov/content/careers-myhr/about-the-bc-public-service/diversity-inclusion/diversity-inclusion-strategy) outlines the committments of BC govenment in supporting inclusion, equitability and access throughout the province. - -The [Declaration on the Rights of Indigenous Peoples Act (Declaration Act)](https://www.bclaws.gov.bc.ca/civix/document/id/complete/statreg/19044) establishes the United Nations Declaration on the Rights of Indigenous Peoples (UN Declaration) as BC’s framework for reconciliation that respects the human rights of Indigenous Peoples. - -## 2.9. Legal Agreements -TBD - -# End of Document - - diff --git a/docs/resources/bc-vcpedia/credentials/_pilots/verified-email.md b/docs/resources/bc-vcpedia/credentials/_pilots/verified-email.md deleted file mode 100644 index 1caaf4fe..00000000 --- a/docs/resources/bc-vcpedia/credentials/_pilots/verified-email.md +++ /dev/null @@ -1,7 +0,0 @@ ---- -layout: default -title: Verified Email -parent: Credentials ---- - -Governance for Verified User Credential (Level 3 according to TrustOverIP Governance model) diff --git a/docs/resources/bc-vcpedia/credentials/_pilots/verified-employee.md b/docs/resources/bc-vcpedia/credentials/_pilots/verified-employee.md deleted file mode 100644 index f837b5b8..00000000 --- a/docs/resources/bc-vcpedia/credentials/_pilots/verified-employee.md +++ /dev/null @@ -1,7 +0,0 @@ ---- -layout: default -title: Verified Employee -parent: Credentials ---- - -Governance for Verified Employee Credential (Level 3 according to TrustOverIP Governance model) diff --git a/docs/resources/bc-vcpedia/credentials/_pilots/verified-person.md b/docs/resources/bc-vcpedia/credentials/_pilots/verified-person.md deleted file mode 100644 index cf1df5e1..00000000 --- a/docs/resources/bc-vcpedia/credentials/_pilots/verified-person.md +++ /dev/null @@ -1,9 +0,0 @@ ---- -layout: default -title: Verified Person -parent: Credentials ---- - -Governance for Verified Person Credential (Level 3 according to TrustOverIP Governance model) - -Issued by IDIM in BC diff --git a/docs/resources/bc-vcpedia/ledgers/index.md b/docs/resources/bc-vcpedia/ledgers/index.md deleted file mode 100644 index 24372543..00000000 --- a/docs/resources/bc-vcpedia/ledgers/index.md +++ /dev/null @@ -1,3 +0,0 @@ -# Ledgers - -Description here diff --git a/docs/resources/bc-vcpedia/ledgers/ledger-candy.md b/docs/resources/bc-vcpedia/ledgers/ledger-candy.md deleted file mode 100644 index b05e9466..00000000 --- a/docs/resources/bc-vcpedia/ledgers/ledger-candy.md +++ /dev/null @@ -1,5 +0,0 @@ ---- -title: Candy Ledger ---- - -Updated link is https://iccs-isac.github.io/Gouvernance-CICN-ICDT-Governance/ diff --git a/docs/resources/bc-vcpedia/guides/credential-detail_view_(bottom).png b/docs/resources/guides/credential-detail_view_(bottom).png similarity index 100% rename from docs/resources/bc-vcpedia/guides/credential-detail_view_(bottom).png rename to docs/resources/guides/credential-detail_view_(bottom).png diff --git a/docs/resources/bc-vcpedia/guides/credential-detail_view_(top).png b/docs/resources/guides/credential-detail_view_(top).png similarity index 100% rename from docs/resources/bc-vcpedia/guides/credential-detail_view_(top).png rename to docs/resources/guides/credential-detail_view_(top).png diff --git a/docs/resources/bc-vcpedia/guides/credential-ux-guide.md b/docs/resources/guides/credential-ux-guide.md similarity index 100% rename from docs/resources/bc-vcpedia/guides/credential-ux-guide.md rename to docs/resources/guides/credential-ux-guide.md diff --git a/docs/resources/bc-vcpedia/guides/example_credential-simple_view.png b/docs/resources/guides/example_credential-simple_view.png similarity index 100% rename from docs/resources/bc-vcpedia/guides/example_credential-simple_view.png rename to docs/resources/guides/example_credential-simple_view.png diff --git a/docs/resources/bc-vcpedia/guides/example_non-production_credential.png b/docs/resources/guides/example_non-production_credential.png similarity index 100% rename from docs/resources/bc-vcpedia/guides/example_non-production_credential.png rename to docs/resources/guides/example_non-production_credential.png diff --git a/docs/resources/bc-vcpedia/guides/index.md b/docs/resources/guides/index.md similarity index 100% rename from docs/resources/bc-vcpedia/guides/index.md rename to docs/resources/guides/index.md diff --git a/docs/resources/bc-vcpedia/guides/message_from_contact.png b/docs/resources/guides/message_from_contact.png similarity index 100% rename from docs/resources/bc-vcpedia/guides/message_from_contact.png rename to docs/resources/guides/message_from_contact.png