Machine-readable governance files simplify the governance in a decentralized verifiable credential ecosystem: but who develops these files—and how?
Decentralized Ecosystem Governance using machine-readable files is the most effective and efficient way to implement the rules for using verifiable digital credentials in a Trusted Digital Ecosystem. These rules cover everything from who is a trusted issuer of verifiable credentials to the adaptive information flows for managing verification of specific information.
The benefits to using machine readable files, which reside in the agent software for issuing, holding, and verifying credentials, include removing friction in verification (the governance authority doesn’t have to be pinged for each verification) and enabling offline verification (with the rules being cached, verification can occur without an internet connection).
But, practically, how do these machine readable governance files come into existence?
It’s a two-step process. The rules and human governance are determined by whomever is responsible for creating the ecosystem with reference to relevant laws, requirements, and restrictions; then, a technical development group is created to implement those rules.
In the case of a national government, the governing body of the relevant jurisdiction would be in charge. For a community or an association, the board or leading organization would set the rules. For a company, the C-suite or operations would likely be in charge. After these governing bodies determine the rules for the use case, they decide on the team, department, or contractor to implement them.
The development process is collaborative. There will, inevitably, be specific issues and technical details revealed in development that the rule-makers didn’t consider. The result of this collaborative process is a machine-readable governance file.
Next, there should be an acceptance testing process, whereby this governance file is demonstrated as working properly to the governing body. This body can either directly audit or select an auditing group to make sure the code is stable, both initially and at regular subsequent intervals.
There are two main vulnerabilities. First, if no audits are conducted, the code may drift over time as updates are made (and they will need to be made). Second, if a disgruntled tech employee tampers with the file, it would likely have a negative impact. But these risks are similar to any other tech development process or IT system (e.g., domain names, hosting, databases, code repositories).
In the case of looser, ad-hoc, social governance, where no single party is in charge, individuals could assemble, adopt, and adapt their own governance. The tools and formats for these individual efforts will likely be similar, but additional effort will be needed to discover and share these socially created governance structures.
