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.

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

I think governance.md should be governance.json #8

Open
dhuseby opened this issue May 5, 2019 · 5 comments
Open

I think governance.md should be governance.json #8

dhuseby opened this issue May 5, 2019 · 5 comments

Comments

@dhuseby
Copy link
Owner

dhuseby commented May 5, 2019

I've been thinking about the authentication process for walking through a git history and verifying that the governance rules, DID doc provenance, and commit signatures all check out. I keep wondering how we can specify the governance rules so that an authentication tool can be created. I think the first step is to change the governance doc from a free-form md file to a YAML or JSON file that has both deterministic fields that encode the governance rules as well as free-form text for human consumption.

I'd like to have an array of rules in the governance document that are input parameters to some verification system. If we think of the repo history as a blockchain of transactions, then the governance.json file is the set of "smart contracts" that validate each transaction. Git already has commit hooks so the governance rules could simply be a script that gets run as the commit-msg hook to validate the fully formed commit before it gets finalized. Ideally the script would also be runable by an authentication checking tool that walks history from oldest to newest feeding the raw commit to the script.

The first step in all of this would be to change the governance document to something that scripts/code can parse easily and pull named values from. Since DID documents are JSON-LD, I think the governance document should be as well--if for no other reason than to minimize dependencies in tools.

@dhuseby
Copy link
Owner Author

dhuseby commented May 5, 2019

It is important to point out that the commit validation script/rules must be stored in the repo itself so that the provenance of the rules is also tracked and defended with signatures. Given the rules we have for the "genesis" commit, even that one would pass the checks.

@twshelton
Copy link
Collaborator

I've been thinking along the same lines when considering the DID Update method. Would it be possible to examine each commit to see if changes were made to the .did/ directory and if so apply some rules? For example, if ./did/abcdefg12345.did was renamed to ./did/hijklmno678910.did, could the script validate the signature for the commit against the keys in the original file? If so, we could establish some rules around git file operations and specify what is required to have each commit acceptable under the terms of the governance.md file.

@dhuseby
Copy link
Owner Author

dhuseby commented May 5, 2019

@twshelton I am almost certain that git commit hooks can do this. But since this operation is supposed to go through git did update <committer DID string> we own the context completely. The git did porcelain can do the checks before/while it executes the actual git actions on the repo.

@dhuseby
Copy link
Owner Author

dhuseby commented May 5, 2019

@twshelton as I was catching up on the discussion this morning I started to rethink the on-disk organization of the files. Instead of trying to hide everything in a .did/ hidden folder we should have them be regular files because I think what we're doing here is upgrading open source boilerplate to be DID/governance aware. I explained it at the bottom of this post.

@twshelton
Copy link
Collaborator

Sounds good. I'll go ahead and make the basic corrections to mv .did/ to did/ and change the update method from delete/add to git mv. I'll also change governance.md to governance.json. I'll submit a pull request later with those changes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants