From 40d9fa2163f7f8cd684bc10c722d1d2b395214c3 Mon Sep 17 00:00:00 2001 From: John Hopkins Date: Thu, 9 May 2019 19:58:49 -0700 Subject: [PATCH 01/12] added ODCA use case --- did-git-spec.md | 26 +++++++++++++++----------- 1 file changed, 15 insertions(+), 11 deletions(-) diff --git a/did-git-spec.md b/did-git-spec.md index deacf05..1e45d84 100644 --- a/did-git-spec.md +++ b/did-git-spec.md @@ -1,7 +1,7 @@ -Note: for everything marked (Optional), +Note: for everything marked (Optional), -# Abstract +# Abstract Git is a revision control system designed to enable contributors to collaborate in a distributed fashion with no centralized repository. Git supports digitally signing changes with GPG/GPGSM but it is of limited utility because of the lack of widespread adoption of GPG and the infrastructure for key escrowing. This document defines the [DID Method](https://w3c-ccg.github.io/did-spec/#specific-did-method-schemes) for using a Git repository as a source of truth about the repository and its contributors. @@ -20,6 +20,10 @@ The Linux Foundation requires that all contributions to their open source projec ### Authorship and Intellectual Property Rights +### Data Interoperability Standards Management + +The Overlay Data Capture Architecture aims to be a universal tool for data interoperability. It provides for composable multi-dimensional schemas which can be dynamically linked to allow for data pooling and frictionless data sharing. In the case of multiple parties wanting to work together to create standard schemas for a particular use case (an industry consortium standardizing product labels, for instance) but who don't necessarily trust one another, this method provides the ability to enforce a governance framework for managing a shared repository while not giving any one entity the keys to the castle. + # Git DID Method The namestring that shall identify this DID method is `:git`. @@ -38,7 +42,7 @@ The `:git` namestring is defined by the following [ABNF](ftp://ftp.rfc-editor.or git-did = "did:git:commitid" 1*(":" keyid) 1*(";" did-service) 1*("/" did-path) 1*("?" did-query) 1*("#" did-fragment) commitid = 40*(lowerhex) keyid = 64*(lowerhex) -lowerhex = "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" +lowerhex = "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9" / "a" / "b" / "c" / "d" / "e" / "f" ``` @@ -54,13 +58,13 @@ The commit ID portion becomes a globally unique identifier for the Git repositor # CRUD Operations -## Create +## Create **1. Repository DID** The operation of creating a git-did can be done at any point in a git repository. -A DID Document should be created at `.did/repo.did` and all maintainer DID documents added into the .did/ directory. All files are then signed and committed by one of the associated keys in the authentication block into the project. The SHA1 of the commit is then used to create the git-did for this respository. +A DID Document should be created at `.did/repo.did` and all maintainer DID documents added into the .did/ directory. All files are then signed and committed by one of the associated keys in the authentication block into the project. The SHA1 of the commit is then used to create the git-did for this respository. For example: @@ -105,7 +109,7 @@ An example DID doc is shown below. ```jsonld { "@context": "https://wsid.org/git-method/v1", - "id": "did:git::", + "id": "did:git::", "publicKey": [{ "id": "did:git::", "type": "", @@ -117,7 +121,7 @@ Example: ```jsonld { "@context": "https://wsid.org/git-method/v1", - "id": "did:git:abcde12345/hijklmn678919", + "id": "did:git:abcde12345/hijklmn678919", "publicKey": [{ "id": "did:git:abcde12345/hijklmn678919", "type": "ED25519SignatureVerification", @@ -131,7 +135,7 @@ The commit adding your DID document should be signed by the key associated priva Notes: since we don't know the repo did string when the repo DID document is created, the repo DID document will not contain the "id" did string for the repo. The `git did read` operation will "resolve" the "id" by looking up the SHA1 hash of the commit that added the DID document to the repo and dynamically add the "id" member to what is rendered to the user. -## Update +## Update **1. Repository DID** There aren't currently any keys associated with the respository, so there will ne no need to update the Public Keys in the DID document. The process to change the maintainers or the canonical endpoint should be defined in the `.did/governance.md` file. @@ -148,12 +152,12 @@ TODO: **1. Repository DID** -The DID for the repository can be deleted by removing the `.did/repo.did` file from the respository and performaing a commit. The signature of this commit should correspond to one of the maintainers in the `.did/repo.did#authentication list. - +The DID for the repository can be deleted by removing the `.did/repo.did` file from the respository and performaing a commit. The signature of this commit should correspond to one of the maintainers in the `.did/repo.did#authentication list. + **2. Contributor DID** Deletion of a personal did will remove the file from `.did/.did`. The `.did` is maintained in history which supports provability. The signature over this change should correspond to one of the maintainers in the `.did/repo.did#authentication list or the private key of the associated DID document itself. - + TODO: - What happens when re-established? (confirm: new repo.did = new commit hash = new did?) - Is this how we give first-class status to branches/forks - e.g. fork/branch, delete repo.did, re-create new repo.did in each relevant position From 238bcc06d7ff1fbf41641ff1ec9d160231b547e6 Mon Sep 17 00:00:00 2001 From: John Hopkins Date: Thu, 9 May 2019 21:17:15 -0700 Subject: [PATCH 02/12] clean up language --- did-git-spec.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/did-git-spec.md b/did-git-spec.md index 1e45d84..7dd70c2 100644 --- a/did-git-spec.md +++ b/did-git-spec.md @@ -20,9 +20,9 @@ The Linux Foundation requires that all contributions to their open source projec ### Authorship and Intellectual Property Rights -### Data Interoperability Standards Management +### Shared Overlay Repositories -The Overlay Data Capture Architecture aims to be a universal tool for data interoperability. It provides for composable multi-dimensional schemas which can be dynamically linked to allow for data pooling and frictionless data sharing. In the case of multiple parties wanting to work together to create standard schemas for a particular use case (an industry consortium standardizing product labels, for instance) but who don't necessarily trust one another, this method provides the ability to enforce a governance framework for managing a shared repository while not giving any one entity the keys to the castle. +The Overlay Data Capture Architecture aims to be a universal tool for data interoperability. It provides for multi-dimensional schemas which can be dynamically linked to allow for data pooling and frictionless data sharing. In the case of multiple parties wanting to work together to create standard schemas for a particular use case (an industry consortium standardizing product labels, for instance) but who don't necessarily trust one another, this method provides the ability to enforce a governance framework for managing a shared repository while not giving any one entity the keys to the castle. # Git DID Method From 82b2180445989dce02a4bf66374d6c836ac16588 Mon Sep 17 00:00:00 2001 From: John Hopkins Date: Thu, 9 May 2019 21:17:37 -0700 Subject: [PATCH 03/12] clean up language --- did-git-spec.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/did-git-spec.md b/did-git-spec.md index 7dd70c2..b9b87c2 100644 --- a/did-git-spec.md +++ b/did-git-spec.md @@ -22,7 +22,7 @@ The Linux Foundation requires that all contributions to their open source projec ### Shared Overlay Repositories -The Overlay Data Capture Architecture aims to be a universal tool for data interoperability. It provides for multi-dimensional schemas which can be dynamically linked to allow for data pooling and frictionless data sharing. In the case of multiple parties wanting to work together to create standard schemas for a particular use case (an industry consortium standardizing product labels, for instance) but who don't necessarily trust one another, this method provides the ability to enforce a governance framework for managing a shared repository while not giving any one entity the keys to the castle. +The Overlay Data Capture Architecture aims to be a universal tool for data interoperability. It provides for multi-dimensional schemas which can be dynamically linked to allow for efficient data pooling. In case multiple parties want to work together to create standard schemas for a particular use case (an industry consortium standardizing product labels, for instance) but don't necessarily trust one another, this method provides the ability to enforce a governance framework for managing a shared repository while not giving any one entity the keys to the castle. # Git DID Method From 69bb926d4472879266aface7330763613cd37689 Mon Sep 17 00:00:00 2001 From: Thomas Shelton Date: Sun, 12 May 2019 15:42:27 -0400 Subject: [PATCH 04/12] adding version to DID method --- did-git-spec.md | 1 + 1 file changed, 1 insertion(+) diff --git a/did-git-spec.md b/did-git-spec.md index 3bf9ff6..b5c6fc6 100644 --- a/did-git-spec.md +++ b/did-git-spec.md @@ -1,5 +1,6 @@ Note: for everything marked (Optional), +

Git DID Method 1.0

# Abstract From 0d91d3569ad527c2689df56944ae73f2526aeb17 Mon Sep 17 00:00:00 2001 From: Thomas Shelton Date: Sun, 12 May 2019 15:44:45 -0400 Subject: [PATCH 05/12] adding initial terminology section --- did-git-spec.md | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/did-git-spec.md b/did-git-spec.md index b5c6fc6..2df08f9 100644 --- a/did-git-spec.md +++ b/did-git-spec.md @@ -21,6 +21,26 @@ The Linux Foundation requires that all contributions to their open source projec ### Authorship and Intellectual Property Rights +# Terminology + +
+
Commit ID
+
A Git commit ID is a checksum (SHA1 hash) of every important aspect of a commit including: +
    +
  1. The contents of the commit
    2. +
  2. Commit date
    3. +
  3. Committer's name and email address
    4. +
  4. Log message
    5. +
  5. The ID of the previous commit(s)
    6. +
+[A more detailed description](https://git-scm.com/book/en/v1/Getting-Started-Git-Basics#Git-Has-Integrity) +
+
Repo ID
+
The Repo ID is the Commit ID of the commit adding this file into the repository and can be found in the `did/repo.did` file.
+
Contributor ID
+
The Contributor ID is a hash[???(Base64(SHA256(PublicKey from DID Document))???)] of the Contributor's Public Key from the DID document that they control and can be found in the `did/.did` file.
+
+ # Git DID Method The namestring that shall identify this DID method is `:git`. From facdd7f3d1e63168b8e72f7d7d3367dc346f3e22 Mon Sep 17 00:00:00 2001 From: Thomas Shelton Date: Sun, 12 May 2019 17:03:53 -0400 Subject: [PATCH 06/12] adding version to DID method --- did-git-spec.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/did-git-spec.md b/did-git-spec.md index 2df08f9..cfaa918 100644 --- a/did-git-spec.md +++ b/did-git-spec.md @@ -1,6 +1,6 @@ Note: for everything marked (Optional), -

Git DID Method 1.0

+# Git DID Method 1.0 # Abstract From e2d3afb009f86ff651806ff0a3885268cf14045d Mon Sep 17 00:00:00 2001 From: Thomas Shelton Date: Sun, 12 May 2019 17:04:22 -0400 Subject: [PATCH 07/12] adding initial terminology section --- did-git-spec.md | 43 ++++++++++++++++++++++++------------------- 1 file changed, 24 insertions(+), 19 deletions(-) diff --git a/did-git-spec.md b/did-git-spec.md index cfaa918..f423dcc 100644 --- a/did-git-spec.md +++ b/did-git-spec.md @@ -21,25 +21,30 @@ The Linux Foundation requires that all contributions to their open source projec ### Authorship and Intellectual Property Rights -# Terminology - -
-
Commit ID
-
A Git commit ID is a checksum (SHA1 hash) of every important aspect of a commit including: -
    -
  1. The contents of the commit
    2. -
  2. Commit date
    3. -
  3. Committer's name and email address
    4. -
  4. Log message
    5. -
  5. The ID of the previous commit(s)
    6. -
-[A more detailed description](https://git-scm.com/book/en/v1/Getting-Started-Git-Basics#Git-Has-Integrity) -
-
Repo ID
-
The Repo ID is the Commit ID of the commit adding this file into the repository and can be found in the `did/repo.did` file.
-
Contributor ID
-
The Contributor ID is a hash[???(Base64(SHA256(PublicKey from DID Document))???)] of the Contributor's Public Key from the DID document that they control and can be found in the `did/.did` file.
-
+## Terminology + +- **Commit ID** + + A Git commit ID is a checksum (SHA1 hash) of every important aspect of a commit including + + 1. The contents of the commit + 2. Commit date + 3. Committer's name and email address + 4. Log message + 5. The ID of the previous commit(s) + + [A more detailed description](https://git-scm.com/book/en/v1/Getting-Started-Git-Basics#Git-Has-Integrity) + +- **Repo ID** + + The Repo ID is the Commit ID of the commit adding this file into the repository and can be found in the `did/repo.did` file. + +- **Contributor ID** + + The Contributor ID is a hash of the Contributor's Public Key from the DID document that they control and can be found in the `did/.did` file. + + TODO: Is this hash = Base64(SHA256(PublicKey from DID Document))? + # Git DID Method From e41d60ee257c507bc8fc5a57b6f0a112a81f4fc4 Mon Sep 17 00:00:00 2001 From: Dave Huseby Date: Mon, 13 May 2019 16:23:58 -0700 Subject: [PATCH 08/12] added status of diddir code --- README.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/README.md b/README.md index d980871..8b00fee 100644 --- a/README.md +++ b/README.md @@ -50,4 +50,6 @@ each area. ## BetterSign TODO: - [x] Create a public [repo for BetterSign signing tool](https://github.com/dhuseby/bs). -- [ ] Upload existing code. +- [ ] Upload existing bs code. +- [x] Create a public [repo for the DIDDir library](https://github.com/dhuseby/diddir). +- [x] Upload existing diddir code. From ad2615762513d554991ba27faf97054fc26a5ff8 Mon Sep 17 00:00:00 2001 From: Dave Huseby Date: Thu, 16 May 2019 11:16:21 -0700 Subject: [PATCH 09/12] fixing formatting to be text editor friendly --- did-git-spec.md | 120 +++++++++++++++++++++++++++++++++++++----------- 1 file changed, 93 insertions(+), 27 deletions(-) diff --git a/did-git-spec.md b/did-git-spec.md index f423dcc..18a4be2 100644 --- a/did-git-spec.md +++ b/did-git-spec.md @@ -4,17 +4,41 @@ Note: for everything marked (Optional), # Abstract -Git is a revision control system designed to enable contributors to collaborate in a distributed fashion with no centralized repository. Git supports digitally signing changes with GPG/GPGSM but it is of limited utility because of the lack of widespread adoption of GPG and the infrastructure for key escrowing. This document defines the [DID Method](https://w3c-ccg.github.io/did-spec/#specific-did-method-schemes) for using a Git repository as a source of truth about the repository and its contributors. +Git is a revision control system designed to enable contributors to collaborate +in a distributed fashion with no centralized repository. Git supports digitally +signing changes with GPG/GPGSM but it is of limited utility because of the lack +of widespread adoption of GPG and the infrastructure for key escrowing. This +document defines the [DID +Method](https://w3c-ccg.github.io/did-spec/#specific-did-method-schemes) for +using a Git repository as a source of truth about the repository and its +contributors. # Introduction -The Git revision control tool is designed to function in a decentralized peer-to-peer fashion to facilitate collaboration in the frequently-disconnected world. Git uses a directed acyclic graph (DAG) of commits that represent the changes to the folders and files in the repository. Because it uses blockchain-like hash-linking of commits, Git is an effective tool for tracking the provenance of data inside the repository. Git also records the author and other meta data such as digital signatures with each commit linking identity of committers to each commit. Git repos therefore contain all of the information needed to serve as the single source of truth for the provenance of the data it contains and the identities of the contributors that created it. +The Git revision control tool is designed to function in a decentralized +peer-to-peer fashion to facilitate collaboration in the frequently-disconnected +world. Git uses a directed acyclic graph (DAG) of commits that represent the +changes to the folders and files in the repository. Because it uses +blockchain-like hash-linking of commits, Git is an effective tool for tracking +the provenance of data inside the repository. Git also records the author and +other meta data such as digital signatures with each commit linking identity of +committers to each commit. Git repos therefore contain all of the information +needed to serve as the single source of truth for the provenance of the data it +contains and the identities of the contributors that created it. ## Motivation ### Developer Certificate of Origin Compliance -The Linux Foundation requires that all contributions to their open source projects are made by individuals that assert that their contribution adheres to the terms of the [Developer Certificate of Origin](https://developercertificate.org/). The contributor signals their assertion by using either Git's [`--signoff`](https://git-scm.com/docs/git-commit#Documentation/git-commit.txt---signoff) feature, [digital signature](https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work) feature, or both when committing their changes. +The Linux Foundation requires that all contributions to their open source +projects are made by individuals that assert that their contribution adheres to +the terms of the [Developer Certificate of +Origin](https://developercertificate.org/). The contributor signals their +assertion by using either Git's +[`--signoff`](https://git-scm.com/docs/git-commit#Documentation/git-commit.txt---signoff) +feature, [digital +signature](https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work) feature, +or both when committing their changes. ### Verifiable Claims Against Open Source Contributions @@ -25,7 +49,8 @@ The Linux Foundation requires that all contributions to their open source projec - **Commit ID** - A Git commit ID is a checksum (SHA1 hash) of every important aspect of a commit including +A Git commit ID is a checksum (SHA1 hash) of every important aspect of a commit +including 1. The contents of the commit 2. Commit date @@ -33,32 +58,41 @@ The Linux Foundation requires that all contributions to their open source projec 4. Log message 5. The ID of the previous commit(s) - [A more detailed description](https://git-scm.com/book/en/v1/Getting-Started-Git-Basics#Git-Has-Integrity) +[A more detailed +description](https://git-scm.com/book/en/v1/Getting-Started-Git-Basics#Git-Has-Integrity) - **Repo ID** - The Repo ID is the Commit ID of the commit adding this file into the repository and can be found in the `did/repo.did` file. +The Repo ID is the Commit ID of the commit adding this file into the repository +and can be found in the `did/repo.did` file. - **Contributor ID** - The Contributor ID is a hash of the Contributor's Public Key from the DID document that they control and can be found in the `did/.did` file. +The Contributor ID is a hash of the Contributor's Public Key from the DID +document that they control and can be found in the `did/.did` +file. - TODO: Is this hash = Base64(SHA256(PublicKey from DID Document))? +TODO: +- [ ] Is this hash = Base64(SHA256(PublicKey from DID Document))? # Git DID Method The namestring that shall identify this DID method is `:git`. -A DID that uses this method MUST begin with the following prefix: `did:git`. Per the DID specification, this string MUST be in lowercase. The remainder of the DID, after the prefix, is the NSI specified below. +A DID that uses this method MUST begin with the following prefix: `did:git`. +Per the DID specification, this string MUST be in lowercase. The remainder of +the DID, after the prefix, is the NSI specified below. # Target System(s) -This DID method applies to Git beginning with the release of Git that supports the DID signing tool. +This DID method applies to Git beginning with the release of Git that supports +the DID signing tool. # Namespace Specific Identifier (NSI) -The `:git` namestring is defined by the following [ABNF](ftp://ftp.rfc-editor.org/in-notes/std/std68.txt): +The `:git` namestring is defined by the following +[ABNF](ftp://ftp.rfc-editor.org/in-notes/std/std68.txt): ```abnf git-did = "did:git:commitid" 1*(":" keyid) 1*(";" did-service) 1*("/" did-path) 1*("?" did-query) 1*("#" did-fragment) @@ -68,9 +102,14 @@ lowerhex = "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9" / "a" / "b" / "c" / "d" / "e" / "f" ``` -All Git DIDs consist of one lower case hexidecimal string that is the commit ID for the commit that added the `repo.did` document for the repo and an optional lower case hexidecimal string that is the SHA-256 hash of the public key associated with a DID document stored in the repo itself. +All Git DIDs consist of one lower case hexidecimal string that is the commit ID +for the commit that added the `repo.did` document for the repo and an optional +lower case hexidecimal string that is the SHA-256 hash of the public key +associated with a DID document stored in the repo itself. -The commit ID portion becomes a globally unique identifier for the Git repository and is immutable for the life of the Git repository. The "constitution" file contains the list of key IDs of the maintainers +The commit ID portion becomes a globally unique identifier for the Git +repository and is immutable for the life of the Git repository. The +"constitution" file contains the list of key IDs of the maintainers # (Optional) JSON-LD Context Definition @@ -86,7 +125,11 @@ The commit ID portion becomes a globally unique identifier for the Git repositor The operation of creating a git-did can be done at any point in a git repository. -A DID Document should be created at `did/repo.did` and all maintainer DID documents added into the did/ directory. All files are then signed and committed by one of the associated keys in the authentication block into the project. The SHA1 of the commit is then used to create the git-did for this respository. +A DID Document should be created at `did/repo.did` and all maintainer DID +documents added into the did/ directory. All files are then signed and +committed by one of the associated keys in the authentication block into the +project. The SHA1 of the commit is then used to create the git-did for this +respository. For example: @@ -125,7 +168,8 @@ Example: ``` **2. Contributor DID** -To create a Contributor DID, add public DID document into the did/ directory and name it using a `.did` +To create a Contributor DID, add public DID document into the did/ directory +and name it using a `.did` An example DID doc is shown below. ```jsonld @@ -151,42 +195,64 @@ Example: } } ``` -The commit adding your DID document should be signed by the key associated private key of the public key referenced in the DID document. +The commit adding your DID document should be signed by the key associated +private key of the public key referenced in the DID document. ## Read -Notes: since we don't know the repo did string when the repo DID document is created, the repo DID document will not contain the "id" did string for the repo. The `git did read` operation will "resolve" the "id" by looking up the SHA1 hash of the commit that added the DID document to the repo and dynamically add the "id" member to what is rendered to the user. +Notes: since we don't know the repo did string when the repo DID document is +created, the repo DID document will not contain the "id" did string for the +repo. The `git did read` operation will "resolve" the "id" by looking up the +SHA1 hash of the commit that added the DID document to the repo and dynamically +add the "id" member to what is rendered to the user. ## Update **1. Repository DID** -There aren't currently any keys associated with the respository, so there will ne no need to update the Public Keys in the DID document. The process to change the maintainers or the canonical endpoint should be defined in the `did/governance.md` file. +There aren't currently any keys associated with the respository, so there will +ne no need to update the Public Keys in the DID document. The process to +change the maintainers or the canonical endpoint should be defined in the +`did/governance.md` file. **2. Contributor DID** -To update a Contributor DID document, update the current DID document in the repository and rename the file to reflect the new public key. Once all changes have been made commit and sign with the private key of the DID document before it was changed. +To update a Contributor DID document, update the current DID document in the +repository and rename the file to reflect the new public key. Once all changes +have been made commit and sign with the private key of the DID document before +it was changed. ## Delete (Revoke) **1. Repository DID** -The DID for the repository can be deleted by removing the `did/repo.did` file from the respository and performaing a commit. The signature of this commit should correspond to one of the maintainers in the `did/repo.did#authentication list. +The DID for the repository can be deleted by removing the `did/repo.did` file +from the respository and performaing a commit. The signature of this commit +should correspond to one of the maintainers in the `did/repo.did#authentication +list. **2. Contributor DID** -Deletion of a personal did will remove the file from `did/.did`. The `.did` is maintained in history which supports provability. The signature over this change should correspond to one of the maintainers in the `did/repo.did#authentication list or the private key of the associated DID document itself. +Deletion of a personal did will remove the file from `did/.did`. +The `.did` is maintained in history which supports provability. +The signature over this change should correspond to one of the maintainers in +the `did/repo.did#authentication list or the private key of the associated DID +document itself. TODO: - - What happens when re-established? (confirm: new repo.did = new commit hash = new did?) - - Is this how we give first-class status to branches/forks - e.g. fork/branch, delete repo.did, re-create new repo.did in each relevant position +- [ ] What happens when re-established? (confirm: new repo.did = new commit hash = new did?) +- [ ] Is this how we give first-class status to branches/forks - e.g. fork/branch, delete repo.did, re-create new repo.did in each relevant position # Security Considerations -This spec applies only to versions of git >= 2.13.0, which used hardened SHA-1. Versions less than v.2.13.0 are susceptible to a [critical hash collision vulnerability](https://github.com/git/git/blob/master/Documentation/technical/hash-function-transition.txt), and MUST NOT be used for implementing this method. +This spec applies only to versions of git >= 2.13.0, which used hardened SHA-1. +Versions less than v.2.13.0 are susceptible to a [critical hash collision +vulnerability](https://github.com/git/git/blob/master/Documentation/technical/hash-function-transition.txt), +and MUST NOT be used for implementing this method. # Privacy Considerations -Since DIDs can be resolved by anyone, care should be taken to ensure the DID Document does not contain any sensitive personal information. +Since DIDs can be resolved by anyone, care should be taken to ensure the DID +Document does not contain any sensitive personal information. # Reference Implementations @@ -213,5 +279,5 @@ Since DIDs can be resolved by anyone, care should be taken to ensure the DID Doc - roll -> used to indicate maintainer/contributor status # Resources -The Peer DID Method Spec is very similar in nature and can be used as a reference point. -(https://dhh1128.github.io/peer-did-method-spec/index.html) +The Peer DID Method Spec is very similar in nature and can be used as a +reference point. (https://dhh1128.github.io/peer-did-method-spec/index.html) From 27cf0d225bd16b49e694ed17cc09640e095a5334 Mon Sep 17 00:00:00 2001 From: John Hopkins Date: Thu, 9 May 2019 19:58:49 -0700 Subject: [PATCH 10/12] added ODCA use case --- did-git-spec.md | 20 ++++++++++++-------- 1 file changed, 12 insertions(+), 8 deletions(-) diff --git a/did-git-spec.md b/did-git-spec.md index 18a4be2..88798da 100644 --- a/did-git-spec.md +++ b/did-git-spec.md @@ -1,8 +1,8 @@ -Note: for everything marked (Optional), +Note: for everything marked (Optional), # Git DID Method 1.0 -# Abstract +# Abstract Git is a revision control system designed to enable contributors to collaborate in a distributed fashion with no centralized repository. Git supports digitally @@ -40,6 +40,10 @@ feature, [digital signature](https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work) feature, or both when committing their changes. +### Data Interoperability Standards Management + +The Overlay Data Capture Architecture aims to be a universal tool for data interoperability. It provides for composable multi-dimensional schemas which can be dynamically linked to allow for data pooling and frictionless data sharing. In the case of multiple parties wanting to work together to create standard schemas for a particular use case (an industry consortium standardizing product labels, for instance) but who don't necessarily trust one another, this method provides the ability to enforce a governance framework for managing a shared repository while not giving any one entity the keys to the castle. + ### Verifiable Claims Against Open Source Contributions @@ -98,7 +102,7 @@ The `:git` namestring is defined by the following git-did = "did:git:commitid" 1*(":" keyid) 1*(";" did-service) 1*("/" did-path) 1*("?" did-query) 1*("#" did-fragment) commitid = 40*(lowerhex) keyid = 64*(lowerhex) -lowerhex = "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" +lowerhex = "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9" / "a" / "b" / "c" / "d" / "e" / "f" ``` @@ -119,7 +123,7 @@ repository and is immutable for the life of the Git repository. The # CRUD Operations -## Create +## Create **1. Repository DID** @@ -175,7 +179,7 @@ An example DID doc is shown below. ```jsonld { "@context": "https://wsid.org/git-method/v1", - "id": "did:git::", + "id": "did:git::", "publicKey": [{ "id": "did:git::", "type": "", @@ -187,7 +191,7 @@ Example: ```jsonld { "@context": "https://wsid.org/git-method/v1", - "id": "did:git:abcde12345/hijklmn678919", + "id": "did:git:abcde12345/hijklmn678919", "publicKey": [{ "id": "did:git:abcde12345/hijklmn678919", "type": "ED25519SignatureVerification", @@ -206,7 +210,7 @@ repo. The `git did read` operation will "resolve" the "id" by looking up the SHA1 hash of the commit that added the DID document to the repo and dynamically add the "id" member to what is rendered to the user. -## Update +## Update **1. Repository DID** There aren't currently any keys associated with the respository, so there will @@ -225,6 +229,7 @@ it was changed. **1. Repository DID** +<<<<<<< HEAD The DID for the repository can be deleted by removing the `did/repo.did` file from the respository and performaing a commit. The signature of this commit should correspond to one of the maintainers in the `did/repo.did#authentication @@ -237,7 +242,6 @@ The `.did` is maintained in history which supports provability. The signature over this change should correspond to one of the maintainers in the `did/repo.did#authentication list or the private key of the associated DID document itself. - TODO: - [ ] What happens when re-established? (confirm: new repo.did = new commit hash = new did?) - [ ] Is this how we give first-class status to branches/forks - e.g. fork/branch, delete repo.did, re-create new repo.did in each relevant position From 276b3b6732d0b6eea8c9b066b7d26ca80e097eab Mon Sep 17 00:00:00 2001 From: John Hopkins Date: Thu, 9 May 2019 21:17:15 -0700 Subject: [PATCH 11/12] clean up language --- did-git-spec.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/did-git-spec.md b/did-git-spec.md index 88798da..0ed824a 100644 --- a/did-git-spec.md +++ b/did-git-spec.md @@ -49,6 +49,7 @@ The Overlay Data Capture Architecture aims to be a universal tool for data inter ### Authorship and Intellectual Property Rights +<<<<<<< HEAD ## Terminology - **Commit ID** @@ -80,6 +81,7 @@ TODO: - [ ] Is this hash = Base64(SHA256(PublicKey from DID Document))? + # Git DID Method The namestring that shall identify this DID method is `:git`. From 27d9906226b2e44664b00a868cd910dfd166bbe7 Mon Sep 17 00:00:00 2001 From: John Hopkins Date: Thu, 9 May 2019 21:17:37 -0700 Subject: [PATCH 12/12] clean up language --- did-git-spec.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/did-git-spec.md b/did-git-spec.md index 0ed824a..796311c 100644 --- a/did-git-spec.md +++ b/did-git-spec.md @@ -81,6 +81,10 @@ TODO: - [ ] Is this hash = Base64(SHA256(PublicKey from DID Document))? +<<<<<<< HEAD +======= +The Overlay Data Capture Architecture aims to be a universal tool for data interoperability. It provides for multi-dimensional schemas which can be dynamically linked to allow for efficient data pooling. In case multiple parties want to work together to create standard schemas for a particular use case (an industry consortium standardizing product labels, for instance) but don't necessarily trust one another, this method provides the ability to enforce a governance framework for managing a shared repository while not giving any one entity the keys to the castle. +>>>>>>> clean up language # Git DID Method