Note: lists.hyperledger.org will be down for maintenance on Monday, September 26th, starting at 9AM Pacific Time (4PM Monday September 26, 2022 UTC), for approximately one hour.
Re: Gid DID spec work
Dave Huseby <dhuseby@...>
toggle quoted messageShow quoted text
Thanks for poking me this morning. I think you're confused about this. This isn't *Github* this is just Git. There is a Github DID method spec and also a Facebook one that I think suffers from the problem you point out. What HL is interested in is just the Git tool itself and is more about how to store identities with the code so that repos are self-verifying and have air-tight provenance. The effort is trying to accomplish the following:
1) Modify the core Git tool to have an abstracted commit/tag signing system that is not hard coded to GPG and is able to support multiple signing tools. This work could also include teaching Git how to understand and utilize multiple signatures on commits/tags but that's a stretch goal. I have a set of patches that I wrote last year that the intern for the Git DID signing project (https://wiki.hyperledger.org/display/INTERN/Git+signing+with+DIDs) will own, rebase, and oversee getting landed in the Git project.
2) Add a core Git porcelain command called "git did" that takes DID method strings (e.g. "git:did:<repo>:<identity>") and handles the CRUD operations specified in the DID method spec (https://github.com/dhuseby/did-git-spec/blob/master/did-git-spec.md).
3) Standardize how DID documents are stored in a Git repo. What we're really doing is defining a new keyring standard where the identities and key material are stored as DID documents in the filesystem (see DIDDir: https://github.com/dhuseby/did-git-spec/blob/master/did-dir-spec.md). The current proposal is that the keyring is just a Git repository and the files will organized and manipulated in standard ways--think: Maildir except with versioning handled by Git, using the 'git did' porcelain command. By defining the keyring as a repo means that it can be a stand-alone repo in a user's home directory storing private/personal identity information just like a GPG keyring, or it can be part of a repo that contains other data such as code for an open source project.
4) Standardize how governance documents (e.g. license, code of conduct, DCO, governance rules like 2+2 reviews) are stored as well as defining the rules for how maintainers and contributors manage the identities stored in the repo. As an example rule, new contributors will first have to "join" a project by sending a patch/PR that adds their public DID document--storing at least their public key and author string--to the repo along with a digital signature over the governing documents as acceptance of the license, CoC, DCO, etc. By combining that rule with one that requires all commits to be signed by an identity *already* stored in the repo, we can ensure that all commits are signed and contributed under the terms of the governing documents.
We are having a meeting tomorrow to discuss the current state of the project at 11am pacific time on the hyperledger.community.backup zoom.
I hope this fully addresses your question/concern.
P.S. Just to head off the question "what happens to old repos that have long histories that weren't governed by this new system?" The answer is, the repos can be "blessed" at any point in their history to adopt this system. When the repo is blessed, all DCO and license issues must be resolved. It's the same as when one of our projects has to clean up all of their DCO issues. For projects that have already cleaned up their DCO issues and have maintained clean DCO histories since, then blessing the repo to use this new governance model is the same as if the repo was brand new.
P.S.S. Once nice side effect of this is being able to make ZKPs that prove things based on identities and contribution history stored in repos. As long as the repos are publicly available, anybody would be able to cryptographically prove that they are a contributor to an HL project and therefore eligible to vote in the TSC election. How 'bout that?
On Mon, May 6, 2019 at 2:16 AM Arnaud Le Hors <lehors@...> wrote:
Interesting idea but isn't depending on a fully centralized system owned by a corporation defeating the whole point of DIDs?