Re: Gid DID spec work


Arnaud Le Hors
 

You're right, I was confused. Now, I understand. That's pretty cool!
Thanks. :-)
--
Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM




From:        David Huseby <dhuseby@...>
To:        Arnaud Le Hors <lehors@...>
Cc:        Hyperledger List <tsc@...>
Date:        05/23/2019 07:28 PM
Subject:        [EXTERNAL] Re: [Hyperledger TSC] Gid DID spec work




Hi Arnaud,

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.

Cheers!
Dave

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?

---
David Huseby
Security Maven, Hyperledger
The Linux Foundation
+1-206-234-2392
dhuseby@...


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?
--
Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM





From:        
"Dave Huseby" <dhuseby@...>
To:        
Hyperledger List <tsc@...>
Date:        
05/05/2019 09:50 PM
Subject:        
[Hyperledger TSC] Gid DID spec work
Sent by:        
tsc@...




Hi TSC,

I attended the Internet Identity Workshop last week and decided to organize sessions on a solution to the DCO problem that I've been chewing on for more than a year now. I proposed sessions to work out a Git DID method spec and all of the details around it. For those of you not familiar with what I'm talking about, you've got a lot of reading :) DID primer DID spec DID method registry Understanding DIDs

The short cut explanation is that this is an effort to teach Git how to understand digital signatures on commits made by self-sovereign identities and how to store those identities in the repo itself. Another aspect of this is how to encode governance rules (think: transaction validation/"smart contracts") into a Git repo to enforce legal (e.g. DCO) and governance (e.g. 2+2 sign-offs) rules so that we can have air-tight compliance.

The proposal generated a lot of attention and support and the effort has moved to github repos and a mailing list to keep the momentum. Since this doesn't fit neatly under the HL banner--is more systemic in nature--I haven't tried to set up a lab or anything, but I do want you to all be aware of it. All are welcome and I invite you to take a look and help. Currently the spec writing repo is here: https://github.com/dhuseby/did-git-specand the mailing list is here: https://groups.io/g/did-git/topics

I am planning on presenting this work at the next appropriate HL get-together and talk about how the HL community can use this to meet DCO and other governance requirements better.

Dave
---
David Huseby
Security Maven, Hyperledger
The Linux Foundation
+1-206-234-2392
dhuseby@...


Join tsc@lists.hyperledger.org to automatically receive all group messages.