Use SHA1 of commit for generating a contributor DID as well?

[canadaduane]

Context

While it's certainly possible (and even encouraged, as DIDs become more wide-spread) to use an external DID as one's contributor DID (e.g. did:sov, did:btcr, etc.) it also seems useful and likely common to create a DID within the git repository for a contributor. It could be that the contributor has no other DID, or they prefer to remain anonymous, and thus need a new DID.

Proposal

We could require that all new DIDs generated via the did:git method be by appending the commit sha.

So for the genesis DID of the repo itself, the DID would be generated from did:git:$commit. (Producing did:git:<genesis commit SHA>.)

For a subsequent new contributor DID to be generated, it would be did:git:<genesis commit SHA>:$commit where this $commit refers not to the genesis commit, but to the SHA1 of the commit where the contributor's new DID document was added.

Corollaries

This would imply that DID document filenames stored like did/<contributor>.did do not contain the actual DID in the filename (nor in the document). Since the SHA1 is generated as a result of checking in the DID Document, a contributor DID doc would suffer from the same problem as the genesis DID document--the DID itself is known only after creation.

So, the <contributor> in <contributor>.did could be the name or handle of the contributor, rather than their DID. As an aside, I think this would actually be easier to manage, since listing the directory contents would show recognizable names rather than a list of SHA-like DIDs.

Also, contributor DID generation would be exactly like repository DID generation: the DID is contained in the context of the DID Document creation (i.e. in the SHA1) not in the repository content.

Lastly, only one new contributor DID can be generated per commit.

[dhuseby]

This is an interesting idea. I had assumed that the <contributor> part would be the hash of the contributor's public key stored inside of the <contributor>.did file. I'm worried that the insecurity of SHA-1 is something we're not fully considering. I like the symmetry between the repo DID and contributor DID strings being commit hashes. My original design for alias mapping allows for arbitrary aliases to map to DID documents in an N to 1 fashion. There could be multiple aliases pointed at the same DID document to maximize their usefulness for repo governance. I don't think it is very important for the name of the DID documents to have some human meaningful name. You make a good point that doing an ls on the dir would be nice to see meaningful file names for DID documents, but with aliases and the git did porcelain, it would be just as easy to implement a git did list command that outputs alias -> DID lines.

I'm liking the idea of making all of the DID documents templates and the DID string in them being "rendered" with the commit hashes. But again, that commit hash is SHA-1. I just defaulting to using the SHA-256 hash of the DID's public key instead, just because SHA-256 > SHA-1. But this requires more thinking.

Can you think of any attack vectors that can be mitigated by using the key hash instead of the commit hash?

[dhuseby]

FYI, I updated the spec to say that the <contributor> part is the Base58(SHA256(public key bytes)).

[dhuseby]

The reason I went that way is because the author string in commits will be the DID string for the contributor and I want that to include the key ID for the signature and I also want the contributor's DID document to be named the same for simplicity sake.

[dhuseby]

OK, so I can see the value of going either way, but now I'm going to change my mind : ) If the contributor DID document is named the encoded hash of the public key, then the DID document would change names when the key get rotated. I'm not sure that's a good idea.

I like using the commit hash as the contributor ID better than using the key id. Here's why:

1. The contributor ID is tied to the repo and tied to a point in time. This is important for verifiable claims that are time based. For instance, I could prove that I've been a contributor for >5 years or something.
2. The DID string for a contributor will remain stable over time even if their keys are rotated. This will help for keeping DID strings from going stale.
3. We can add aliases that map the Base58(SHA256(key bytes)) -> .did and then modify aliases as keys rotate.

[twshelton]

I like that approach. The aliases seem to provide a lot of flexibility. Thomas

…

On Wed, Jun 5, 2019 at 2:06 PM Dave Huseby ***@***.***> wrote: OK, so I can see the value of going either way, but now I'm going to change my mind : ) If the contributor DID document is named the encoded hash of the public key, then the DID document would change names when the key get rotated. I'm not sure that's a good idea. I like using the commit hash as the contributor ID better than using the key id. Here's why: 1. The contributor ID is tied to the repo and tied to a point in time. This is important for verifiable claims that are time based. For instance, I could prove that I've been a contributor for >5 years or something. 2. The DID string for a contributor will remain stable over time even if their keys are rotated. This will help for keeping DID strings from going stale. 3. We can add aliases that map the Base58(SHA256(key bytes)) -> .did and then modify aliases as keys rotate. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#17?email_source=notifications&email_token=AAAPEEVVCOZDTTK3ZLZQDXLPY76DBA5CNFSM4HMUUO3KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXARMGA#issuecomment-499193368>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAPEER3XVOIXZE6WS6JIZ3PY76DBANCNFSM4HMUUO3A> .

[dhuseby]

So now we have to revisit the procedure for bootstrapping the regime in a repo. If a contributor ID is the commit ID of when their DID document is added means that all DID documents have to be added in their own commit. But we want to have the repo.did file to be signed and linked to the DID documents of the maintainers. Also, all of the DID documents would at least start as a template with placeholders for the commit IDs in the the ID strings in the document.

So here's how I think the bootstrapping procedure should go:

0. The did folder is created in the repo root.
1. The repo.did DID template is created and committed, signing it with one of the maintainer keys. Along with the repo.did DID template, the governance documents are also committed.
2. An initial maintainer creates their DID template in the did folder and commits it, signing the commit with the private key associated with the public key in their template.
3. Each initial maintainer creates their DID template in the did folder and commits them in the same way. One DID per commit.

It isn't atomic, but it has to be this way if the commit ID is the contributor ID. This is the only way to establish the DID for a committer.

[canadaduane]

Yes, I think this would be the necessary sequence if none of the maintainers have external DIDs/trust from outside.

…

On Wed, Jun 5, 2019 at 5:50 PM Dave Huseby ***@***.***> wrote: So now we have to revisit the procedure for bootstrapping the regime in a repo. If a contributor ID is the commit ID of when their DID document is added means that all DID documents have to be added in their own commit. But we want to have the repo.did file to be signed and linked to the DID documents of the maintainers. Also, all of the DID documents would at least start as a template with placeholders for the commit IDs in the the ID strings in the document. So here's how I think the bootstrapping procedure should go: 1. The did folder is created in the repo root. 2. The repo.did DID template is created and committed, signing it with one of the maintainer keys. Along with the repo.did DID template, the governance documents are also committed. 3. An initial maintainer creates their DID template in the did folder and commits it, signing the commit with the private key associated with the public key in their template. 4. Each initial maintainer creates their DID template in the did folder and commits them in the same way. One DID per commit. It isn't atomic, but it has to be this way if the commit ID is the contributor ID. This is the only way to establish the DID for a committer. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#17?email_source=notifications&email_token=AAAABANVWHKPT7X27JDFBMLPZBGNBA5CNFSM4HMUUO3KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXBKVTI#issuecomment-499296973>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAABAPVYCZ3U6H4MJNOUPTPZBGNBANCNFSM4HMUUO3A> .