Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Create LSBC Governance #224

Draft
wants to merge 3 commits into
base: main
Choose a base branch
from
Draft

Create LSBC Governance #224

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
d777c25
Create LSBC Governance
krobinsonca Nov 8, 2024
643dc4a
Update governance.md
krobinsonca Nov 8, 2024
6325ef3
Create Professional Credential governance.md
krobinsonca Nov 13, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
190 changes: 190 additions & 0 deletions docs/governance/employment/professional-credential/governance.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,190 @@
---
title: Professional Credential
---

# Professional Credential

# 1. Primary Document

## 1.1 Introduction
This document outlines the Governance Framework (GF) for the Professional Credential, a general purpose digital credential structure designed to represent a professional accreditation from regulatory body. The Professional Credential intends to provide a standardized, secure, and verifiable means of identifying and recognizing professionals who have a completed requirements to receive accreditation. The structure of the credential is designed to encapsulate essential information, such as the professional's identity, the regualtory body issuing the credential, and the current status, ensuring clarity and consistency in its representation across systems and processes.

The Professional Credential is designed to be issued by the regulatory body to the professional upon completion of requirements and revoked or re-issued whenever applicable. This credential serves as a versatile and standardized proof of the professional’s status, allowing issuers and verifiers the flexibility to utilize it according to their specific needs.

***Acknowledgements***:
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).

***No Warranty***:
The Professional Credential is provided “as is”, and the Province of British Columbia (the "Province") disclaims all representations, warranties, conditions, obligations, and liabilities of any kind, whether express or implied, in relation to the Professional Credential, including without limitation implied warranties with respect to merchantability, satisfactory quality, fitness for a particular purpose and non-infringement. Without limiting the general nature of the previous sentence, the Province does not represent or warrant that:
- (a) the Professional Credential will be available;
- (b) your use of the Professional Credential will be timely, uninterrupted or error-free;
- (c) any errors in the Professional Credential will be corrected; or
- (d) the Professional Credential will meet your expectations and requirements.

***Limitation of Liability***:
To the maximum extent permitted by applicable law, under no circumstances will the Province be liable to you, to any other individual or to any entity for any direct, indirect, special, incidental, consequential or other loss, claim, injury or damage, whether foreseeable or unforeseeable (including without limitation claims for damages for loss of profits or business opportunities, use or misuse of, or inability to use, the Professional Credential, interruptions, deletion or corruption of files, loss of programs or information, errors, defects or delays) arising out of or in any way connected with your use of the Professional Credential and whether based on contract, tort, strict liability or any other legal theory. The previous sentence will apply even if the Province has been specifically advised of the possibility of any such loss, claim, injury or damage.

## 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 Governance Framework (GF) is English.

## 1.4 Governing Authority

The Cybersecurity and Digital Trust (CDT) branch serves as the governing authority for this governance framework. Each issuer and verifier of the credential is responsible for defining the specific procedures for its issuance and verification.

The contact information for the CDT is:
* **Name:** Jillian Carruthers
* **Title:** Sr. Executive Director
* **Organization:** Cybersecurity and Digital Trust
* **Email:** jillian.carruthers@gov.bc.ca

## 1.5. Administering Authority

The Cybersecurity and Digital Trust (CDT) branch is the administering authority responsible for this GF.

The contact information for CDT is:
* **Name:** Jillian Carruthers
* **Title:** Sr. Executive Director
* **Organization:** Cybersecurity and Digital Trust
* **Email:** jillian.carruthers@gov.bc.ca

## 1.6 Purpose

The purpose of this GF is to define what the Professional Credential is and who is responsible for the authority and administration of its use.

## 1.7 Scope

A Professional Credential issued according to this GF, provides evidence of an accreditation for a professional.

## 1.8 Objectives

To allow the credential holder evidence they have accreditation in a verifiable credential format that is both secure and tamperproof.

## 1.9 Principles

[The B.C. 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 B.C. 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
N/A

## 1.11. Revisions
Version 1.0.

## 1.12. Extensions
There are no extensions to this GF.

## 1.13. Schedule of Controlled Documents
N/A

# 2. Controlled Documents

## 2.1. Glossary
[ToIP Core Glossary](https://trustoverip.github.io/toip/glossary)

## 2.2. Risk Assessment
In accordance with B.C. government procedures and policies, the standard [Privacy Impact Assessment (PIA)](https://www2.gov.bc.ca/gov/content/governments/services-for-government/information-management-technology/privacy/privacy-impact-assessments) and [Security Threat and Risk Assessment (STRA)](https://www2.gov.bc.ca/gov/content/governments/services-for-government/information-management-technology/information-security/security-threat-and-risk-assessment) processes have been completed for the use of this credential technology.

## 2.3. Trust Assurance and Certification
Development of digital technology is led by [British Columbia’s Digital Code of Practice](https://digital.gov.bc.ca/resources/digital-principles), applicable to all public service employees and professionals involved in and accountable for digital service delivery.

## 2.4. Governance Requirements

The requirements for the Professional Credential are based on the standards and practices used for professionals that are associated with the Provincial Government of BC. These requirements are intended to be general so multiple regulatory bodies can use this common structure. References include the following:

* [BC Procurement Resources (gov.bc.ca)](https://www2.gov.bc.ca/gov/content/bc-procurement-resources)
* [Procurement Services Act (gov.bc.ca)](https://www.bclaws.gov.bc.ca/civix/document/id/complete/statreg/03022_01)
* [CPPM Policy Chapter 6: Procurement (gov.bc.ca)](https://www2.gov.bc.ca/gov/content/governments/policies-for-government/core-policy/policies/procurement)

## 2.5. Business Requirements

The primary use of the Professional Credential is for credential holders to provide evidence they are a verified professional.

## 2.6. Technical Requirements (Credential)
The format for this credential is [AnonCreds specification](https://wiki.hyperledger.org/display/anoncreds).

## 2.6.1 Schema Definition

__Schema Name:__ professional-credential

__Schema Version:__ 1.0

This schema definition follows [the AnonCreds specification](https://wiki.hyperledger.org/display/anoncreds).

| **Name** | **Attribute** | **Format** | **Rules** | **Notes** |
|--------------------------------|-------------------------------------|---------------------------------------------------------------------------|--------------------------------------------------------------------------|---------------------------------------------------------------------------|
| Credential ID | credential_id | Typically UUID or issuer-defined | | A unique identifier for the credential instance |
| Professional ID | professional_id | Text | | Unique identifier for the professional within the issuer’s registry, if applicable |
| Issuance Date | issuance_dateint | Date | (YYYYMMDD) | Date the credential was issued |
| Expiry Date | expiry_dateint | Date | (YYYYMMDD) Common for licenses needing periodic renewal; optional | Date the credential expires, if applicable |
| Issuer Jurisdiction | issuer_jurisdiction | Text | | Jurisdiction of the issuer |
| Credential Type | credential_type | Text | | The type or category of the credential |
| Profession Title | profession_title | Text | | Title of the profession |
| Specialization | specialization | Text | Optional | Any specific area of expertise within the profession, if applicable |
| Professional Level | professional_level | Text | Optional | Certification level, if relevant |
| Scope of Practice | scope_of_practice | Text | Optional | Defines the professional’s permitted practices, if applicable |
| Family Name | family_name | String | optional | Legal family name or mononym(s) of the professional
| Given Names | given_names | String | optional | Legal first and middle name(s) of the professional
| Status | status | Text | | Current status of the credential |
| Compliance Requirements | compliance_requirements | Text | | A record of any ongoing requirements or conditions |
| Jurisdiction Validity | jurisdiction_validity | Text | | Jurisdictions where the credential is valid |
| Code of Conduct | code_of_conduct | Text | Optional | Reference to applicable ethical or professional standards |


| Name | Attribute | Format | Rules | Notes |
| -------------------------------- | -------------------------------- | ------ | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Company Name | company_name | String | optional | Name of the contracting company that holds the contract
| User ID | user_id | String | optional | A unique user ID for the professional
| Email | email | String | optional | Email address belonging to the professional
| Organization | organization | String | optional | Abbreviation or name of the organization this contract is for
| Contract Number | contract_number | String | optional | Contract number the professional is associated to
| Contract Start Date | contract_start_dateint | dateint | optional | (YYYYMMDD) The date when the contract starts, if different dates for each professional on the contract, use the professional-specific start date
| Contract End Date | contract_end_dateint | dateint | optional | (YYYYMMDD) The date when the contract ends, if different dates for each professional on the contract, use the professional-specific start date
| Criminal Record Check Expiry Date | criminal_record_expiry_dateint | dateint | optional | (YYYYMMDD) The date when the criminal record check expires for the professional

### 2.6.2. Credential Implementation
N/A - Each issuer will define their own implementation details

### 2.6.3 Schema Implementation

|Environment|Ledger|Schema ID|Public DID|
|---|---|---|---|
|Production|TODO|TODO|TODO|
|Development|TODO|TODO|TODO|

## 2.7. Information Trust Requirements
Not applicable.

## 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 commitments of BC government 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 B.C.’s framework for reconciliation that respects the human rights of Indigenous Peoples.

## 2.9. Legal Agreements
N/A

# End of Document


Loading