Skip to content

Commit

Permalink
Merge pull request #245 from bcgov/credential_governance_template_upd…
Browse files Browse the repository at this point in the history 
…ates

Update credential_template.md
  • Loading branch information
@krobinsonca
krobinsonca authored Feb 25, 2025
2 parents fd4bec2 + 75a8dd5 commit 13ca0be
Showing 1 changed file with 78 additions and 89 deletions.
167 changes: 78 additions & 89 deletions docs/governance/credential_template.md
View file
Original file line number Diff line number Diff line change
@@ -1,114 +1,103 @@
# _Name(s) of the Credential(s)_ – Credential Documentation
# [Issuer and Name(s) of the Credential(s)] – Credential Documentation

## 1. About this Document

This document describes the _Name(s) of the Credential(s)_ to help potential verifiers determine whether it is suitable for their needs. The intended audience includes policy analysts, privacy specialists, solution architects, developers, and data architects.
## 1 About this Document
This document describes the [Issuer and Name(s) of the Credential(s)] to help potential verifiers determine whether it is suitable for their needs. The intended audience includes policy analysts, privacy specialists, solution architects, developers, and data architects.

### 1.1 Version History
| Ver. | Date | Notes |
|------|-------------|-------------|
| 1.0 | [Insert date] | [Insert notes] |

## 2 Credential Overview
[Insert paragraph summarizing what the credential(s) is, what it’s for, who it’s for (i.e., who is likely to have and use one), and other notable info.]

- **Credential**: [Name(s) of the Credential(s)]
- **Schema**: [Name of the schema; technical details in section 6]
- [If the schema is documented separately, include a link here]
- **Issuer**:
- **Name**: [Name of issuer]
- **Description**: [Brief description of issuer]
- **Website**: [Issuer website]
- **Contact info**: [Issuer contact information]

## 3 Governance & Legal
### 3.1 Governing Authority & Administrative Authority
The governing body with authority to issue and revoke the credential(s) is [Entity Name], including contact information unless an administrative authority is the designated contact.

| Ver. | Date | Notes |
|------|------|-------|
| 1.0 | | |

## 2. Credential Overview

_A paragraph summarizing what the Credential(s) is, its purpose, and other notable information._

### 2.1 Credential Details
- **Reference**: [Trust over IP Glossary - Governing Body](https://glossary.trustoverip.org/#term:governing-body)

| | |
|-------------------------|---------------------------------------------------------------------------------|
| **Name(s) of the Credential(s):** | _Names(s) of the Credential(s)_ |
| **Issuer:** | _Issuer of the Credential(s)_ |
| **Holders:** | _Summary of who is eligible to be issued the Credential(s)_ |
| **Data Source:** | _Summary of the source(s) of the information in the credential(s)_ |
| **Issuer DID:** | _DID of the Issuer_ |
| **Format:** | _Technical format, e.g., AnonCreds, W3C_ |
| **Schema:** | - _Name, version, and address of the Schema_ _Documentation of the Schema, if available_ |
| **Credential Definition:** | - _Name address of the credential definition_ |
| **Data Registry:** | _Registry address_ |
| **OCA:** | _Link to the Overlay Capture Architecture bundle for this credential_ |
If different from the Governing Authority, the administrative body delegated operational responsibilities by the governing authority is [Entity Name], including contact information.

- **Reference**: [Trust over IP Glossary - Administering Body](https://glossary.trustoverip.org/#term:administering-body)

### 2.2 Attribute Summary
### 3.2 Legal
#### 3.2.1 For Verifiers
[Insert or link to a statement limiting the liability of the issuer (and, if different, the governing and administrative authorities) for any harms suffered by parties that accept the credential.]

| Display Name of Attribute | Attribute | Format |
|---------------------------|-----------------|-----------|
| Given Names | `given_names` | string |
| Family Name | `family_name` | string |
| Date of Birth | `birthdate_dateint` | integer |
| ... | ... | ... |
#### 3.2.2 For End Users
[Insert or link to a statement limiting the liability of the issuer (and, if different, the governing and administrative authorities) for any harms suffered by parties issued the credential. This may be presented to end users during issuance.]

## 3. Governance & Legal
## 4 Credential Data, Issuance and Changes
[Optional: Include additional issuer information here if too detailed for the summary table.]

### 3.1 Governing Authority & Administrative Authority
_The governing body with the authority to issue and revoke the credential(s), including contact information unless an administrative authority is intended to be the contact.
[https://glossary.trustoverip.org/#term:governing-body]_

_The Ministry of Citizens’ Services, as the Provincial Identity Information Services Provider as defined in section 69.2 of the Freedom of Information and Access to Information Act, is the governing authority for the BC Person credential._
### 4.1 Data Source(s)
[Describe where the data in the credential comes from and how the issuer ensures its accuracy when collected.]

_If different than the Governing Authority, the administrative body that has been delegated operational responsibilities by the governing authority, including contact information.
[https://glossary.trustoverip.org/#term:administering-body] _
#### 4.1.1 Data Updates
[Describe how and when the issuer receives updates to the credential data. Leave credential updates to the Revocation section.]

_Within the Ministry of Citizens’ Services, the Cybersecurity and Digital Trust Branch and the Service BC Division have operational responsibility for the BC Person credential._
### 4.2 Issuance
[Describe the issuance process sufficiently for a prospective verifier to understand how the issuer ensures the credential is issued only to the correct party. Include how the holder is identified and authenticated, potentially referencing Data Source(s). Specify if the credential is issued to individuals or organizations and what type(s) of wallets (e.g., specific brands or any standards-compliant wallet) it supports.]

### 3.2 Legal
### 4.3 Revocation
[Describe circumstances—specific or general—that would cause the issuer to revoke a credential after issuance. Optionally, include cases where it would be revoked and re-issued.]

#### 3.2.1 For Verifiers
_A statement – included or linked to – limiting the liability of the issuer (and, if different, the governing and administrative authorities) for any harms suffered by parties that accept the credential._
## 5 Credential Definition
### 5.1 Subject
[Specify the type of entity—e.g., a person, company, title—described by the attributes. Explain why a verifier can be confident the holder is the subject, referencing the issuance process if applicable.]

#### 3.2.2 For End Users
_A statement – included or linked to – limiting the liability of the issuer (and, if different, the governing and administrative authorities) for any harms suffered by parties that are issued the credential. This will often be presented to end users during the issuance process._
### 5.2 Attributes
[List all attributes in the credential in a table. Describe each attribute beyond its schema name (e.g., how it’s populated, whether it can be blank). Use subheadings (e.g., “5.2.1 [Subset Name]”) for subsets of attributes if needed.]

_Person credential Terms of Use._
| Display Name | Description | Attribute | Data Type | Format | Rules | Examples | Notes |
|-----------------------|------------------------------|-------------------|-------------------|-----------|---------------|------------------|------------------|
| [Attribute Name] | [Description of data] | [Schema attribute name] | [e.g., String, Integer] | [e.g., YYYYMMDD] | [e.g., Never blank] | [e.g., Sample data] | [Additional info or quirks] |

## 4. Credential Data, Issuance, and Changes
## 6 Implementations
### 6.1 Technical Format
[Specify technical format(s), e.g., AnonCreds, W3C, of the credential.]

### 4.1 Data Source(s)
_Where the data in the credential comes from, and how the issuer ensures that it is correct when collected._
### 6.2 Issuer List
| Environment | Issuer DID |
|-------------------|-----------------------------------|
| [Name] | [DID of the issuer] |

### 4.2 Data Updates
_How and when the Issuer gets updates to the data that goes into the credential. How the credential gets updated should be left for the Revocation section, below._
### 6.3 Schema
| Environment | Ledger | Schema ID |
|-------------------|-----------------------------------|-----------------------------------|
| [Name] | [Link to ledger] | [Schema transaction ID] |

### 4.3 Issuance
_Describes the process for issuing the credential sufficiently that a prospective verifier will have a good sense of how the issuer ensures that the credential is issued to only the correct party. This should include how the prospective holder is identified and authenticated before being issued a credential. This may reference the Data Source(s) section in explaining how the holder will have a credential with correct data._
### 6.4 Credential
[If multiple credential definitions exist, distinguish them by rows with unique names.]

_Also: if the credential is issued to individuals or organizations, indicate what type(s) of wallets (e.g., BC Wallet) the credential will be issued to, or if the credential will be issued to any brand or type of wallet._
| Environment | Ledger | Credential Definition ID | OCA Bundle |
|-------------------|-----------------------------------|-----------------------------------|-----------------------|
| [Name] | [Link to ledger] | [Credential transaction ID] | [OCA Bundle ID] |

### 4.4 Revocation
_Describes the circumstances – either specifically or in general – that would cause the issuer to revoke a credential after it has been issued to the Holder._
### 6.5 OCA Bundle Additional Information
[Document the additional configuration details required to build the Overlay Capture Architecture (OCA) bundle for this credential, such as visual assets, colors, and attribute mappings. Provide the following details as applicable. You can use the [OCA Explorer](https://bcgov.github.io/aries-oca-explorer/) to help build an example OCA bundle based on this information.]

- The credential will be revoked in the following cases:
...
- The credential will be revoked and re-issued in the following cases:
...
- **Logo Image**: [URL to the logo image for the credential display]
- **Background Image Slice**: [URL to the background image slice (e.g., for wallet display)]
- **Full Background Image**: [URL to the full background image]
- **Primary Color**: [Hex code for the primary background color, e.g., "#003366"]
- **Secondary Color**: [Hex code for the secondary background color, e.g., "#fcbc1e"]
- **Main Display Attribute**: [Name of the primary attribute to display prominently, e.g., "given_names"]
- **Secondary Display Attribute**: [Name of the secondary attribute to display, e.g., "family_name"]
- **Issuance Date Field**: [Name of the attribute indicating issuance date, or leave blank if not applicable]
- **Expiry Date Field**: [Name of the attribute indicating expiry date, or leave blank if not applicable]

## 5. Credential Definition
## 7 Example Proof Requests
[Optional: Include one or more proof requests to illustrate credential use by a verifier, with a plain text explanation of each.]

### 5.1 Subject
_The type of entity – e.g., a person, company, title – that is described by the attributes._

_The subject of a Person credential is the individual to whom it was issued, i.e., its holder. See the Credential Assurance section, above, for why a verifier can be confident that the holder of a Person credential is the subject of the credential._

### 5.2 Attributes
_A list of all the attributes in the credential, with a table describing each attribute. Subheadings and notes may be used to provide information that applies to a group of attributes, e.g., “Name” to describe Given Names and Family Name, “Address” to describe the set of address attributes. Repeat the table for each individual attribute_

| **Field** | **Description** |
|--------------------------|-----------------------------------------------------------------------------------------------------------------------|
| **Display Name** | _Name displayed in the wallet next to the data value (e.g. Birthdate)_ |
| **Description** | _Describes the data that will be in the attribute (e.g. The individual's documented birth date recorded from valid identification.)_ |
| **Attribute** | _Name of attribute in schema or credential (e.g. `birthdate_dateint`)_ |
| **Format** | _How the data is presented (e.g., minimum or maximum characters, how multiple values are delimited, date format is YYYYMMDD)_ |
| **Rules** | _Things such as whether the attribute can be blank or not, and how data is handled if the source system data has more characters than the maximum characters defined in the Format_ |
| **Examples** | _One to three samples of the data that a verifier could find in this attribute (e.g. 19711225, 19711013, 19580816)_ |
| **Notes** | _Additional information about the data that may (or not) be present in the attribute, in particular any “quirks” in the data that could affect a verifier trying to process the data or compare it to other records (including common attributes, such as family_name, in other credentials that may be part of the same proof request but have come from different issuers)._ |

| **Field** | **Description** |
|--------------------------|-----------------------------------------------------------------------------------------------------------------------|
| **Display Name** | |
| **Description** | |
| **Attribute** | |
| **Format** | |
| **Rules** | |
| **Examples** | |
| **Notes** | |
---

0 comments on commit 13ca0be

Please sign in to comment.