Handling DID value, which is not known until after DID Doc has been committed

[kimdhamilton]

Warning: I'm not up to date on the latest DID ABNF, so my examples may look off

Context

In the git did method spec, the "repo did" is based on the SHA1 of the commit used to create the repo did doc.

This leads to the same chicken-and-egg problem we had in BTCR when pointing to "continuation" DID documents in immutable storage, like IPFS. This leads to the question of what goes here:

{
  "@context": "https://wsid.org/git-method/v1",
  "id": // What goes here?
  ...
}

Our approach for BTCR was to allow fragments in the continuation document, and the method spec told the resolver to splice in DID (once the confirmed tx is known)

E.g.: a continuation DID doc in the immutable store could look like this "id": "#frag1", and the resolver would splice in the known did, returning this "id": "did:btcr:<txref>#frag1"

Questions

1. Is the above relative fragment/path approach still valid? Keep in mind my terminology like "fragment" may be out of date.

2. What should be done if no fragment/path/etc is needed? The latest DID spec indicates that id is a required field, but does that apply to the resolved doc? In other words, can the field be omitted? Or does it need to exist and have an empty string or placeholder value?

[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