Call the DID Document a DID Doc Template and use `$commit` as placeholder

[canadaduane]

Spec currently reads, "A DID Document should be created at did/repo.did and ..."

In the "Peer DIDs" workshop at IIW one participant talked about their method of creating a DID that might apply here: they create a DID Document Template with the "id" field having a $me placeholder. Then they hash the DID Document to generate the DID itself, and the DID Document is dynamically generated from the "DID Document Template".

I think that's almost precisely what we want here, except that the placeholder is the $commit.

So I suggest a did/repo.did that is actually a DID Document Template, and looks like this:

{
  "@context": "https://wsid.org/git-method/v1",
  "id": "did:git:$commit",
  "service": [{
    "type": <gitService>,
    "serviceEndpoint": <Canonical URI for the respository>
  }],
  "authentication": [
    "<hash-of-pub-key>#controller-1",
    "<hash-of-pub-key>#controller-2",
    "<hash-of-pub-key>#controller-n"
  ]
}

Note that it may be fine to call the template a "DID Document" in a generally conversational context, but when we're writing the spec it may be helpful to differentiate the "template" (checked in) from the "document itself" (dynamically generated).

[dhuseby]

@canadaduane I like this idea. The consequence of this is that the read operation for the repo did document has to look up the original commit hash of the repo.did file in the repo history every time. If we support did document aliases then we could, in theory, add an alias of the commit hash to the repo.did file.

So the did/repo.did file would be a template. Then in the did/aliases folder there would be a file named the hash of the commit for repo.did (i.e. the value that will replace $commit when rendering the repo.did file) and the data in the file will be a single line with "repo.did". The repo.did file is the one case where the name of the file is not some content hash of data in the DID document. All of the identity DID documents will be stored in files named after the hash of the public signing key in the DID document.

[twshelton]

Dave, This is some great insight. I was just going to ask some questions around the "read" method but I think this clarifies for me. I'll add to the "read" section of the spec and submit a pull request. Thomas

…

On Sun, Jun 2, 2019 at 4:27 PM Dave Huseby ***@***.***> wrote: @canadaduane <https://github.com/canadaduane> I like this idea. The consequence of this is that the read operation for the repo did document has to look up the original commit hash of the repo.did file in the repo history every time. If we support did document aliases then we could, in theory, add an alias of the commit hash to the repo.did file. So the did/repo.did file would be a template. Then in the did/aliases folder there would be a file named the hash of the commit for repo.did (i.e. the value that will replace $commit when rendering the repo.did file) and the data in the file will be a single line with "repo.did". The repo.did file is the one case where the name of the file is not some content hash of data in the DID document. All of the identity DID documents will be stored in files named after the hash of the public signing key in the DID document. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#16?email_source=notifications&email_token=AAAPEEWPG33OYDJVARWQCI3PYQUJ5A5CNFSM4HMUOEOKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWX5LBI#issuecomment-498062725>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAPEEWL6GKMZMXNNS5KMM3PYQUJ5ANCNFSM4HMUOEOA> .

[dhuseby]

I added aliases to the spec yesterday so using aliases is going in.

[canadaduane]

I'll have time to look at your latest soon, but in the meantime I just wanted to jot this idea down:

Could a "git did add [someone]" command become a two-step commit, allowing us to embed the $commit in the template and create a bonefide DID document checked in to the repo?

So the git porcelain would operate in two steps...

step 1: Generate a DID Doc Template with $commit as placeholder
step 2: Use the commit SHA of step 1 and replace $commit in the Doc Template, thus creating a DID Document.

Seems like this could help with lookups & caching, as well as make the DID Document a real doc in the repo, while maintaining this desirable property of SHA being used to generate a DID with the did:git method.

Downside: I guess it could lead to social engineering hacks where someone replaces a DID that was in some DID Document and someone else doesn't bother to check if the DID matches the original commit SHA.