---
# System prepended metadata

title: Machine Readable Governance

---

# Machine Readable Governance

## Present Implementation
Email credential issuance and verification

### Goals of the Present Implementation for Machine Readable Governance
* List roles of participating parties
* Organization contact information
* List issuers (approved issuers that provide the correct verifiable credentials)
* List validated verifiers (can be trusted to verify credentials according to the governance framework)
* Schemas in use

### Workflow
1. Holder looks up the governance file from a trusted party.
2. Holder finds at least one issuer that offers a validated email credential and has been verified by the governing organization.
3. Holder uses the machine readable governance framework to connect to the issuer.
4. The issuer uses provided information to validate the email and issue the credential according to the governance framework.
5. After receiving the email credential, the holder looks up a list of verifiers that:
    a) have been vetted as safe verifiers of the email credential (i.e., you can trust them not to misuse any data you share with them).
    b) can help them verify that their credential is in working order.

### Sample File
```json=
{
  "@context": ["https://github.com/hyperledger/aries-rfcs/blob/master/0430-machine-readable-governance-frameworks/context.jsonld"],
  "name": "Email Validation",
  "version": "0.1",
  "description": "Issuance and verification of validated email credentials. Provides a source of truth for current schemas, issuers, and verifiers",
  "last_updated": "2021-06-07",
  "docs_uri": "create_or_leave_blank",
  "data_uri": "create_or_leave_blank",
  "schemas": ["email_schema_here"],
  "roles": ["issuer", "verifier"],
  "define": [
    {
      "name": "Email_Issuer",
      "id": "update_with_did_please",
      "describe": {
        "label": "Email Issuer",
        "sublabel": "Issuing Org",
        "website": "issuingorgsite.com",
        "email": "credential_manager@issuingorgsite.com"
        "endpoints": [
          {
            "type": "invitation_request",
            "url": "https://domain_or_ip:port/api/invitations"
          },
          {
            "type": "email_request",
            "url": "https://domain_or_ip:port/api/credentials"
          },
        ]
      }
    },
    {
      "name": "Email_Verifier",
      "id": "update_with_did_please",
      "describe": {
        "label": "Email Verifier",
        "sublabel": "Verifying Org",
        "website": "verifyingorgsite.com",
        "email": "verifying_manager@verifyingorgsite.com"
      }
    }
  ], 
  "rules": [
    {"when": {"name": "Email_Issuer"}, "thus": "issuer"},
    {"when": {"name": "Email_Verifier"}, "thus": "verifier"}
  ]
}
```

### Our Governance Road Map
1. Launch the client's implementation
2. Provide a demo to the Aries Working group
3. Provide a publicly available open source service where anyone can utilize the governance framework for validated emails


## Future Governance Possibilities
https://github.com/hyperledger/aries-rfcs/blob/master/concepts/0430-machine-readable-governance-frameworks/README.md
* Dynamic ecosystem
    * Change the issuers, verifiers, rules, etc. over time
    * Provide for stable versions where all participating parties know what to expect
* Rules for issuers
    * Allowed attribute values
    * Prerequisites
* Rules for holders
    * Caching
    * Pre-requisites
* Rules for verifiers
    * Verifiers can identify approved issuers
    * Allowed presentations
    * Business logic based on presentations
* Workflow Instructions
    * Steps, requirements, and logic for multiple participants
    * Can apply to issuance, presentation, data storage, and business logic dependent on verifiable credentials
* Approved Schemas
    * Can address multi-ledger security concerns
    * Define data formats and conversion standards (e.g. to and from FHIR)
