✨ Try the Interactive Playground! Explore how Git history drives Decentralized Identifiers. ✨

Many early DID methods were based on distributed ledgers or other decentralized infrastructure. The DID method presented here is did:git. The primary intention of the did:git method is to support permissive commons by embedding licensing, rights, and financial obligations directly into the version control workflow, anchored via gitmark to the Bitcoin blockchain. This strips "digital slavery" out of the commons informatics supply chain.

Introduction

Preface

The did:git method specification conforms to the requirements specified in the Decentralized Identifiers v1.1 Specification [[DID-CORE]]. For more information about DIDs and DID method specifications, please also see the [[?DID-PRIMER]].

Example 

did:git:git@github.com:WebCivics/did-method-git.git
        
            {
                "@context": "https://www.w3.org/ns/did/v1",
                "id": "did:git:github:WebCivics/did-method-git.git",
                "publicKey": [
                  {
                    "id": "#keys-1",
                    "type": "RsaVerificationKey2018",
                    "owner": "did:git:github:WebCivics/did-method-git.git",
                    "publicKeyPem": ""
                  }
                ]
              }
        
        {
            "@context": "https://www.w3.org/ns/did/v1",
            "id": "did:git:github:WebCivics/did-method-git/",
            'commit':"e59a1820d9f79c54655c16777949b1b09e378671",
            "publicKey": [
              {
                "id": "#keys-1",
                "type": "RsaVerificationKey2018",
                "owner": "did:git:github:WebCivics",
                "publicKeyPem": ""
              }
            ]
          }

did:git Method Specification

Target system

The target system of the did:git method is the GIT distributed version control system, originally authored by Linus Torvalds in 2005 for development of the Linux kernel. The source code for Git refers to the program as, "the information manager from hell." source: WikiPedia

Method name

The method name 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.

Method-specific identifier

the method-specific identifier for a DID is a unique Git repository URL or Git commit hash. The repository URL identifies a specific Git repository that can be cloned and manipulated using the Git protocol, while the commit hash represents a specific commit in the Git repository. Both the repository URL and the commit hash can be used to verify the authenticity and integrity of the associated data, which is a key feature of the DID specification. The links to the formal rules describing valid GIT syntax will be added to the specification. 

git-did = "did:git:" git-repo [ ":" commit-hash ]

The git-repo component can be a standard git URL, and the optional commit-hash anchors the resolution to a specific moment in the repository's history.

DID method operations

Create

Creating a DID is done by:

  1. Choose a Git repository: First, you'll need to choose a Git repository that you want to use for your DID. This might be a repository that you control, or it might be a public repository that you want to reference in your DID.
  2. Create a Git commit: Next, you'll need to create a Git commit that contains the data you want to reference in your DID. This might be a JSON-LD file that describes your DID document, or it might be some other kind of data that you want to associate with your DID.
  3. Push the commit to the repository: Once you've created the Git commit, you'll need to push it to the Git repository. This will make the commit publicly available and allow others to reference it in their DIDs.
  4. Create a DID document: Using the Git commit hash or repository URL, you can create a DID document that references the data you want to associate with your DID. The DID document might include additional information such as public keys, service endpoints, or other metadata.
  5. Publish the DID document: Finally, you'll need to publish the DID document to a decentralized identifier registry or other relevant platform. This will make the DID publicly available and allow others to resolve it and access the associated data.

Update

The following steps MUST be executed to resolve a DID to a DID document using the did:git method.

  1. associated with your DID. This might involve updating the JSON-LD file that describes your DID document, adding new public keys or service endpoints, or making other modifications to the associated data.
  2. Create a new Git commit: Once you've made the changes to the data, you'll need to create a new Git commit that reflects those changes. This new commit will serve as the updated version of your DID.
  3. Push the commit to the repository: Once you've created the new Git commit, you'll need to push it to the Git repository. This will make the updated data publicly available and allow others to reference the updated version of your DID.
  4. Update the DID document: Using the new Git commit hash or repository URL, you can update the DID document to reference the updated version of the associated data. This might involve updating the updated property in the DID document, as well as any other relevant metadata.
  5. Publish the updated DID document: Finally, you'll need to publish the updated DID document to the relevant platform or registry. This will make the updated DID publicly available and allow others to resolve it and access the latest version of the associated data.

Read

To read the DID document, the git repository must be accessible to the user. see the Read section.

  1. Resolve the DID: First, you'll need to resolve the DID to obtain the Git commit hash or repository URL that is associated with the DID. This might involve querying a decentralized identifier registry or other relevant platform.
  2. Clone the Git repository: Once you have the Git commit hash or repository URL, you'll need to clone the Git repository to your local machine or server. This will allow you to access the data that is associated with the DID.
  3. Access the data: Once you have the Git repository, you can access the data that is associated with the DID. This might involve opening the JSON-LD file that describes the DID document, or accessing other files or data that are associated with the DID.
  4. Verify the data: It's a good idea to verify the data that is associated with the DID to ensure that it hasn't been tampered with or modified. This might involve checking the digital signatures or other cryptographic proofs that are associated with the data.
  5. Use the data: Finally, you can use the data that is associated with the DID for whatever purpose you intended. This might involve using the public keys in the DID document to authenticate the DID owner, or accessing other metadata or data that is associated with the DID.

Fork

To Fork a GIT Repo linked to a DID document, the git repository must be accessible to the user. see the Read section.

  1. Create a new Git repository: First, you'll need to create a new Git repository that will serve as the fork of the original DID repository. This might involve using a Git hosting platform like GitHub or GitLab, or creating a new repository on a server or other platform.
  2. Clone the original repository: Next, you'll need to clone the original DID repository to your local machine or server. This will allow you to access the data that is associated with the original DID.
  3. Create a new branch: Once you have the original DID repository, you'll need to create a new Git branch that will serve as the basis for your fork. This might involve creating a new branch in the Git command line or using a Git client or platform.
  4. Push the new branch to the new repository: Using the new Git branch, you can push the relevant data to the new Git repository that you created in step 1. This will create a copy of the original DID data in the new repository and allow you to make changes and updates as needed.
  5. Update the DID document: Using the new repository URL or Git commit hash, you can update the DID document to reference the new forked repository. This might involve updating the id property in the DID document to reflect the new repository URL, as well as updating any other relevant metadata.
  6. Publish the updated DID document: Finally, you'll need to publish the updated DID document to the relevant platform or registry. This will make the forked DID publicly available and allow others to resolve it and access the associated data.

Pull Request

To create a pull request for a GIT Repo linked to a DID document, the git repository must be accessible to the user. see the Read section.

  1. Clone the original repository: First, you'll need to clone the original DID repository to your local machine or server. This will allow you to access the data that is associated with the original DID.
  2. Create a new branch: Once you have the original DID repository, you'll need to create a new Git branch that will contain the changes you want to make to the DID. This might involve creating a new branch in the Git command line or using a Git client or platform.
  3. Make changes to the DID: Using the new Git branch, you can make the changes to the DID that you want to propose in the pull request. This might involve updating the id property in the DID document to reflect a new repository URL or other changes to the DID metadata.
  4. Commit the changes: Once you have made the necessary changes, you'll need to commit them to the Git repository using the Git command line or a Git client. This will create a new Git commit that includes the changes to the DID.
  5. Push the new branch and commit to a forked repository: Next, you'll need to push the new branch and commit to a forked repository that you control. This might involve creating a new Git repository on a hosting platform like GitHub or GitLab, or using a server or other platform to host the forked repository.
  6. Submit a pull request: Using the hosting platform or other tools, you can then submit a pull request to the original repository that includes the changes you made to the DID in the forked repository. This will allow the maintainers of the original DID to review the changes and merge them into the main branch of the repository if they are accepted.
  7. Update the DID document: If the pull request is accepted and the changes are merged into the original repository, you'll need to update the id property in the DID document to reflect the new changes. This might involve referencing the new commit hash or other metadata associated with the merged changes.
  8. Publish the updated DID document: Finally, you'll need to publish the updated DID document to the relevant platform or registry. This will make the updated DID publicly available and allow others to resolve it and access the associated data.

Deactivate

To create a pull request for a GIT Repo linked to a DID document, the git repository must be accessible to the user. see the Read section.

  1. Create a new Git commit: First, you'll need to create a new Git commit that indicates that the DID is being deactivated. This might involve adding a new property or flag to the JSON-LD file that describes the DID document, indicating that the DID is no longer active.
  2. Push the commit to the repository: Once you've created the new Git commit, you'll need to push it to the Git repository. This will make the updated data publicly available and allow others to reference the deactivated version of your DID.
  3. Update the DID document: Using the new Git commit hash or repository URL, you can update the DID document to reference the deactivated version of the associated data. This might involve updating the updated property in the DID document, as well as any other relevant metadata.
  5. Publish the updated DID document: Finally, you'll need to publish the updated DID document to the relevant platform or registry. This will make the deactivated DID publicly available and allow others to resolve it and access the deactivated version of the associated data.

It's important to note that deactivating a DID using the DID:GIT method does not necessarily remove the associated data from the Git repository. Instead, it simply indicates that the DID is no longer active and should not be used for authentication or other purposes (see the Deactivate section).

Discuss if there should be a way to explicitly mark a git resource as "deactivated" or "deprecated".

Stash

To create a pull request for a GIT Repo linked to a DID document, the git repository must be accessible to the user. see the Read section.

  1. Clone the original repository: First, you'll need to clone the original DID repository to your local machine or server. This will allow you to access the data that is associated with the original DID.
  2. Create a new branch: Once you have the original DID repository, you'll need to create a new Git branch that will contain the changes you want to stash. This might involve creating a new branch in the Git command line or using a Git client or platform.
  3. Make changes to the DID: Using the new Git branch, you can make the changes to the DID that you want to stash. This might involve updating the id property in the DID document to reflect a new repository URL or other changes to the DID metadata.
  5. Stash the changes: Once you have made the necessary changes, you can stash them using the Git command line or a Git client. This will temporarily save the changes to the branch without committing them to the repository.
  6. Switch to a different branch: After stashing the changes, you can switch to a different Git branch to work on other changes or updates to the DID.
  7. Apply the stashed changes: When you are ready to apply the stashed changes to the DID, you can do so using the Git command line or a Git client. This will restore the changes you made to the DID in the stashed branch and allow you to continue working on them.

It's important to note that deactivating a DID using the DID:GIT method does not necessarily remove the associated data from the Git repository. Instead, it simply indicates that the DID is no longer active and should not be used for authentication or other purposes (see the Deactivate section).

Discuss if there should be a way to explicitly mark a git resource as "deactivated" or "deprecated".

annotate

To create a pull request for a GIT Repo linked to a DID document, the git repository must be accessible to the user. see the Read section.

  1. Clone the original repository: First, you'll need to clone the original DID repository to your local machine or server. This will allow you to access the data that is associated with the original DID.
  2. Create a new branch: Once you have the original DID repository, you'll need to create a new Git branch that will contain the changes you want to stash. This might involve creating a new branch in the Git command line or using a Git client or platform.
  3. Make changes to the DID: Using the new Git branch, you can make the changes to the DID that you want to stash. This might involve updating the id property in the DID document to reflect a new repository URL or other changes to the DID metadata.
  5. Stash the changes: Once you have made the necessary changes, you can stash them using the Git command line or a Git client. This will temporarily save the changes to the branch without committing them to the repository.
  6. Switch to a different branch: After stashing the changes, you can switch to a different Git branch to work on other changes or updates to the DID.
  7. Apply the stashed changes: When you are ready to apply the stashed changes to the DID, you can do so using the Git command line or a Git client. This will restore the changes you made to the DID in the stashed branch and allow you to continue working on them.

It's important to note that deactivating a DID using the DID:GIT method does not necessarily remove the associated data from the Git repository. Instead, it simply indicates that the DID is no longer active and should not be used for authentication or other purposes (see the Deactivate section).

Discuss if there should be a way to explicitly mark a git resource as "deactivated" or "deprecated".

Relation to other technologies

Relation to the did:web method

Similar to this specification, [[?DID-WEB]] also defines a new DID method based on domain names. The syntax of the identifiers is equivalent with the exceptions that 1. the method name in this specification is git instead of web, and 2. the did:web method also allows an optional colon-separated path component as part of its method-specific identifier, which is not supported by this specification. In terms of functionality, the main difference between the two methods is that while the did:web method requires both git and web infrastructure for its operation, the did:git method requires only git infrastructure.

Relation to DID-in-git

The [[?DID-IN-git]] specification also provides a way to connect existing git infrastructure with DIDs. It uses similar Resource Records (RRs). It however does not define a new DID method specification; rather, it defines a way of discovering a DID (using any DID method) from a domain name, using the git infrastructure and protocol. This is intended for use cases where a domain name is used for bootstrapping initial relationships or interactions, but the domain name is not intended to be used beyond such an initial step.

Relation to Well Known DID Configuration

Similar to [[?DID-IN-git]], the [[?WELL-KNOWN-DID]] specification also does not define a new DID method and is rather used for discovery of a DID (using any DID method) via an existing domain name.

As the discovery mechanism, it uses a /.well-known/ path (see [[DID-WEB]]) on a web server in addition to git.

Access Control and Payload Encryption

In addition to public permissive commons, did:git natively supports Private Shared Resources (e.g., private relationship logs or sensitive shared data) by leveraging the cryptographic keys embedded in the W3C DID Documents.

Network Access Control: The SSH keys defined in the verificationMethod of authorized did:git identified entities can be mapped to Git transport hooks (e.g., Gitolite or native SSH constraints), thereby cryptographically restricting which users can fetch or push to the repository.

Payload Encryption: To guarantee data privacy even on untrusted hosts, did:git supports transparent file encryption (conceptually identical to git-crypt). The PGP public keys associated with authorized did:git identified users are used to encrypt the repository's files. Thus, the files remain encrypted at rest and in transit, and can only be decrypted locally by the authorized participants holding the corresponding private keys.

A separate specification will further define the native DID to SSH bindings (DID:SSH) for transport layer security.

Network-Level Privacy and Nym Integration

To prevent metadata leakage (such as IP addresses and connection timing) that occurs even when payloads are encrypted, did:git natively supports the Nym Mixnet.

A Decentralized Identifier Document can express a Nym network address as a ServiceEndpoint. Git clients SHOULD route fetch and push operations through a Nym SOCKS5 proxy (e.g., nym-socks5-client) when resolving repositories hosted via Nym Network Requesters. This ensures true anonymity for both the repository host and the identified users communicating with it.

Cryptographic Suite Mappings

Git natively supports several signature standards. The did:git method parses these raw commit signatures and maps them to standard W3C verificationMethod cryptographic suites.

The required mappings are as follows:

Relation to gitmark and Bitcoin Anchoring

The base did:git method provides identity and verifiable history purely through the Git protocol. However, to support the Permissive Commons Profile, the use of gitmark is REQUIRED.

Gitmark anchors git commits to the Bitcoin blockchain using blocktrails key chaining. This enables the evaluation of permissive commons obligations and the tracking of financial contributions in a tamper-proof manner without requiring a centralized registry. For basic did:git resolution where obligation tracking is not needed, gitmark is optional.

WebID and Solid Interoperability

A WebID is a URI that points to a profile document identifying a person, agent, or group, often utilized in decentralized web ecosystems like the Solid Project. The did:git method is designed to natively operate as a valid WebID, seamlessly bridging W3C Decentralized Identifiers with WebID authentication paradigms (WebID-TLS and WebID-OIDC).

did:git as a Native WebID

When a relying party (e.g., a Solid Pod) attempts to dereference a WebID, it performs HTTP Content Negotiation. While modern applications should request JSON-LD, many legacy Semantic Web agents strictly expect WebID profiles to be served in Turtle (.ttl) format.

To ensure maximum backward compatibility across the WebID and Solid ecosystems, did:git resolvers SHOULD support dynamic Content Negotiation for text/turtle. When an agent requests Accept: text/turtle, the resolver must dynamically synthesize and return a valid RDF Turtle string from the underlying JSON-LD DID Document, explicitly mapping the cryptographic verificationMethod arrays to standard cert:key and foaf:Agent triples.

Authentication (WebID-TLS)

WebID-TLS authentication requires the client to present an X.509 client certificate, which the server validates against the public key found in the WebID profile. Because the did:git parser natively extracts X.509 S/MIME signatures from Git commits and maps them to JsonWebKey2020 (or equivalent) in the verificationMethod array, a did:git DID Document inherently exposes the exact cryptographic assertions required for WebID-TLS authentication. A user simply signs their repository commits with their client certificate to establish their WebID identity root.

Security considerations

DID Document Auditing and History

The DID operations defined in this specification do not provide an immutable history of changes that is typical for other forms of blockchain/DLT based DID methods, and which can be used for auditing purposes. This can lead to certain attacks where the DID document is manipulated temporarily, or different DID documents are presented to different resolvers, without an easy way to detect this behavior.

Add further discussion and possible mitigations.

Decentralization

It has been made known that the DID Working Group has extensively discussed the meaning of "decentralized" identifiers, and various aspects of this terms. GIT is considered to be a decentralized system, in a traditional sense. Further considerations will be made to updated versions of the document.

Privacy considerations

Reference implementations

TBA/TBD.

Acknowledgements

The author would like to acknowledge the people who work tirelessly often without recgonition, compensation or reembursement of costs associated to their work. The hope is that the consequence of works, that includes this specification and if / as needed, the one for DNS:SSH, are parts of work that will lead to better approaches being available to address the widespread problems associated with web slavery, as to better support human rights as they relate to the works done by people, seeking to make a better world for all.