dhuseby / did-git-spec Goto Github PK

Not sure if this is helpful or not, but GitHub DID was originally more similar to this, and has since become much more centralized (and less ambitious).

I'd love to create compatibility, and assist, I'm gonna share some links here to things I considered which may or may not be useful. Since this isn't really an "issue" feel free to close it.

We used to have a bunch of scripts that operated on files checked into the repo:

https://github.com/decentralized-identity/github-did/tree/f6baefe68fefbed5fae32149fbab97f8652e7475/scripts

We tried to use GPG directly via command line tools, instead of via js libraries:

https://github.com/decentralized-identity/github-did/tree/f6baefe68fefbed5fae32149fbab97f8652e7475/scripts/shell

https://github.com/decentralized-identity/github-did/blob/f6baefe68fefbed5fae32149fbab97f8652e7475/scripts/did/create_document.js

We had a checkDID script that would cause travis CI to fail if a DID was not signed properly:

https://github.com/decentralized-identity/github-did/blob/f6baefe68fefbed5fae32149fbab97f8652e7475/scripts/did/checkDIDs.js

The idea was to not merge PRs that contains DIDs that were not signed correctly.

Originally I considered it to be fine to fork and push, because the resolver was tied to the user in GitHub, so I might have old versions of your DID in my repo, but nobody would trust them since I'm not the root of trust for you.

I really liked the idea of just building a DID method on top of GPG, GIT and SSH + some strong assumptions around trust, but the security challenges, rewriting history, etc... scared me off. plus I'm not actually very good with git.

Feel free to borrow any code that is helpful from GitHub DID, and I'm happy to think through security / protocol / method design.

I may be wrong here, but I think the git:did method is going to be susceptible to rewrite attacks. That is, an attacker gets a git repository and either forks, rewrites, or appends history. Now you have two .git repositories w/ the same initial commit hash, that have subtly different histories.

I don't think you can mitigate this attack (unless you couple this DID Method w/ some sort of global append-only audit log), the best you can do is detect the attack and do something about it (like, check to make sure you're using the "official repository" for the project). Even that is susceptible to attack: https://about.gitlab.com/2019/05/03/suspicious-git-activity-security-update/

In any case, you should document this in the Security Considerations section of the DID Document.

Hello,

I came across DIDs only recently, so forgive if any of the following is a result of me not yet fully understanding the concept. We are building a p2p network for code collaboration over at monadic, and - unsurprisingly - are facing some of the same challenges wrt identity management. It would be great to tap into DIDs, and also git-did, yet it seems like some of the assumptions made in the current version of the spec wouldn't quite work in a fully distributed setting. Hence a few questions:

• Is the service of type git supposed to be an example only (that is, service endpoints of any type could be used)? IOW, what if there is no canonical URI for a repo, because the development process of the project is fully distributed?

• Are there more specific ideas around what the governance.{md,json} should specify? I'm thinking that this would also tie into what's been said in #7.

  What we came up with so far is to device a verification procedure very similar to TUF, where the history of the repo identity must be followed from the initial revision up to the most recent one, checking attestation by a quorum of the maintainers at each revision along the way. That has some nice properties to defend against history rewrites and censorship, but poses another challenge in a fully distributed setting: it should be possible to perform this verification before cloning the entire, potentially large, history of the repo from one or more untrusted sources. Since git doesn't allow partial checkouts, we devise storing metadata in disjoint branches, such that an upper bound on the data that has to be fetched can be guaranteed.

Would love to get your thoughts on this!

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?

The current selection of filename seems to be introducing a lot of complexity. From the DID Dir Spec:

The name of each DIDDoc is arbitrary but a best practice is to name each file with the public key identifier (PkId) associated with the identity in the DID document.

Naming the files after aliases would remove some challenges this is causing e.g. discussed here, and remove the need for alias mapping.

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).

Any progress on implementing this code? I’ve a new secp256k1 library for signing in Schnorr that is compatible with multisig and thus great for groups signing a repo.

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.

I think it is a good idea for us to use Linked Data Proofs for the signatures that are stored in Git commits. This seems like the right thing to do.

Just checking if we need to add this to Security Considerations.

I've been thinking about the authentication process for walking through a git history and verifying that the governance rules, DID doc provenance, and commit signatures all check out. I keep wondering how we can specify the governance rules so that an authentication tool can be created. I think the first step is to change the governance doc from a free-form md file to a YAML or JSON file that has both deterministic fields that encode the governance rules as well as free-form text for human consumption.

I'd like to have an array of rules in the governance document that are input parameters to some verification system. If we think of the repo history as a blockchain of transactions, then the governance.json file is the set of "smart contracts" that validate each transaction. Git already has commit hooks so the governance rules could simply be a script that gets run as the commit-msg hook to validate the fully formed commit before it gets finalized. Ideally the script would also be runable by an authentication checking tool that walks history from oldest to newest feeding the raw commit to the script.

The first step in all of this would be to change the governance document to something that scripts/code can parse easily and pull named values from. Since DID documents are JSON-LD, I think the governance document should be as well--if for no other reason than to minimize dependencies in tools.