owned this note
owned this note
Published
Linked with GitHub
# 4 Areas of Machine Readable Governance
## Summary
1. Who to trust
2. Rules
3. Workflows
4. Trust discovery
## Who to trust
List of schemas in use
List of trusted issuers, verifiers
A machine readable governance file is a great choice for trust because it can be 1) generated from dynamic data sources 2) cached and 3) available offline
Most generic level of governance
## Rules
Roles (permissions), prerequisites, requirements
Role: in order to do X, you need permission/role Y
Prerequisites: before you do X, you need to complete Z (ahead of time); e.g. you need a different credential first
Requirements: in order to do X, please have A, B, and C ready and take steps H, I, J during the process; e.g. you need your birth certificate and passport ready and you will need to verify your email and sign a document
A machine readable governance file is a great choice for rules because it directly ties the rules to the ecosystem they belong to (in addition to the three benefits from "who to trust")
More specific level of governance
## Workflows
Description of processes
Can be described in interaction documents which basically outline the states of a state machine and the transformations between states
Interaction documents start as suggestions but can be referred to in governance as standard procedures, thus making them required
A machine readable governance file is a good place to refer to interaction documents
Very (most?) specific level of governance
## Trust Discovery
Discover governance frameworks, issuers, verifiers, schemas, etc.
How to establish trust in governance
Trust registries should aggregate, share, and (perhaps) rate this information
Trust registries should NOT be the source of truth for the previous sections; each jurisdiction should have one source of truth that applies in their own governance file. The registry is an index and aids discovery.
Help to resolve specificity differences, mediate compromises?
## 5 W's and also How
Another useful way to look at governance is by thinking about the answers to these basic questions:
* What?
* list of schemas
* schema requirements
* credential definitions
* Who?
* list of issuers, verifiers
* roles
* Where?
* goes with who (endpoints, URLs, etc.)
* When?
* sequence
* state
* workflow
* Interaction Documents
* How?
* protocols
* Why?
* governance stamp of authority, proof of authority (how to prove authenticity...)
* legal basis
* documentation
## Sample
Our sample includes who to trust, but needs rules and workflows
```json=
{
"@context": ["https://github.com/hyperledger/aries-rfcs/blob/master/0430-machine-readable-governance-frameworks/context.jsonld"],
"name": "Health Governance",
"version": "0.1",
"description": "Issuance and verification of health credentials. Provides a source of truth for current schemas, issuers, and verifiers",
"last_updated": "2021-06-10",
"docs_uri": "need_to_create",
"data_uri": "need_to_create",
"schemas": ["test_id", "test_result", "trusted_traveler"],
"roles": ["issuer", "verifier"],
"define": [
{
"name": "Government_Organization",
"id": "update_with_did",
"describe": {
"label": "Government",
"sublabel": "Full Government Organization Name",
"website": "issuinggovernmentsite.org",
"email": "credential_manager@issuinggovernmentsite.org"
}
},
{
"name": "Lab_Issuer",
"id": "update_with_did",
"describe": {
"label": "Lab Issuer",
"sublabel": "Full Organization Name",
"website": "issuinglabsite.com",
"email": "credential_manager@issuinglabsite.com"
}
},
{
"name": "Health_Verifier",
"id": "update_with_did_please",
"describe": {
"label": "Health Verifier",
"sublabel": "Verifying Org",
"website": "verifyingorgsite.com",
"email": "verifying_manager@verifyingorgsite.com"
}
}
],
"rules": [
{"when": {"name": "Government_Organization"}, "thus": "issuer"},
{"when": {"name": "Lab_Issuer"}, "thus": "issuer"},
{"when": {"name": "Government_Organization"}, "thus": "verifier"}
{"when": {"name": "Health_Verifier"}, "thus": "verifier"}
]
}
```