Handling DID value, which is not known until after DID Doc has been committed about did-git-spec

[msporny]

I think the designers of the git:did method need to decide where the DID Doc/keys/etc. are going to exist. That is, in the .git directory? As a top-level file called something like SECURITY.md, or something else?

If it's in the .git directory, and you're going to modify the git binary, you have a ton of options.

If you are going to use something like SECURITY.md, then you can always make that the second commit and thus it's clear what to put in id (the initial commit).

[dhuseby]

@msporny we went back and forth on this for a long time but we think we came to a well-reasoned conclusion. We decided that all of the files must be stored in the repo itself and not in the .git directory. Here are a bunch of reasons:

1. We want to support git clone --depth=1 and still be able to authenticate. We figured that if the did:git string was anchored somewhere else (e.g. btcr or sov) we could 1) verify that the did:git string matches what is anchored and 2) verify the signature on the HEAD commit. The idea was to give some measure of authenticity without having to do a full clone although I have to admit we haven't gamed this out fully yet and it may not be sufficient.

2. The DID documents are only valid between the commit in which they are added to the repo until the commit where they are removed or renamed. They have to always be valid between those commits, inclusive, and having them tracked in the history means a checkout at any point in history gives you all of the DID documents required to validate the commit.

3. The same can be said for all of the repo-wide files as well. They existing in a specific state at a specific point in history and tracking their provenance in the repo history makes the most sense. The envisioned git-did porcelain will be aware of this temporal "flow" of identity and governance through the history of the repo.

4. We didn't want to require a squash commit to a new repo to imbue a project with did:git authentication and governance. By having the files in the repo itself, it makes it possible to preserve the history and still imbue it with a commit that establishes did:git governance and forms the checkpoint where we can make a legal declaration about all of the code that came before it. This is important to the Linux Foundation use case where existing projects are donated to the org more often than projects are started from scratch.

I originally envisioned all of these documents going into a .did/ hidden subdir in the repo root to avoid cluttering up the root. However as we have moved forward, I began thinking of this stuff as the next generation of the README.md + LICENSE + CONTRIBUTORS boilerplate that we all use now. The new boilerplate being a README.md, LICENSE, GOVERNANCE.json (not .md, see here ), and a DIDDir named did/ containing the DID documents and aliases.

[canadaduane]

See also #16