HID-DID method spec for registration on W3C did registry

[Vishwas1]

Here is the process https://www.w3.org/TR/did-spec-registries/#the-registration-process

• Examples
• All methods which are registered so far: https://www.w3.org/TR/did-spec-registries/#did-methods
• https://docs.ont.io/decentralized-identity-and-data/ontid
• https://docs.ont.io/decentralized-identity-and-data/ontid/decentralized-identifiers/method-specification
• https://docs.ont.io/decentralized-identity-and-data/ontid/decentralized-identifiers/method-specification-1
• https://github.com/ontology-tech/DID-solidity/blob/binance-did/doc/en/DID-spec-binance.md
• https://github.com/decentralized-identity/ethr-did-resolver/blob/master/doc/did-method-spec.md
• https://docs.cheqd.io/node/architecture/adr-list/adr-002-cheqd-did-method

[Vishwas1]

HID-DID method registration on W3C

• [ ] Understand the registration process using this link: https://www.w3.org/TR/did-spec-registries/#the-registration-process
• [ ] Find out what all things do we need to register a DID
• [ ] Look for other did-methods and see how they have implemented the did-method spec

[Vishwas1]

Process

• Software implementers might find that the existing Decentralized Identifier Core specification is not entirely capable of addressing their use case and might need to add a new parameters, properties, or values to this registry in order to achieve their use case in a globally interoperable fashion.
• In order to add a new parameter, property, or value to this registry, an implementer MUST submit a modification request for this registry, as a pull request (PR) on the repository where this registry is hosted. PR must be given in this repo: https://github.com/w3c/did-spec-registries/ . If there is need for discussion then: https://github.com/w3c/did-core/issues . Emails can be sent to "public-did-wg@w3.org"
• the modification request adheres to the following policies:
  • Any addition to the DID Core Registries MUST specify a human readable description of the addition.
  • Any addition to the DID Core Registries MUST link, via at least a URL, preferably a content-integrity protected one, to the defining specification so that implementer can implement the property. (???)
  • Any addition to the DID Core Registries that is a property or value, MUST specify a machine readable JSON-LD Context for the addition.
  • Properties in the DID Core Registries MUST NOT be removed, only deprecated.
• DID method developers are encouraged to review and apply the [DID-RUBRIC] as early as possible in their development process to ensure that they are evaluating their DID method appropriately for the requirements of the problem they are attempting to solve with the introduction of a new DID method.
• If you are considering defining a new DID method, consider first surveying existing defined DID methods to see if there may be an already existing method that may meet your needs. Many DID method specifications can be found listed in the [DID-SPEC-REGISTRIES].
• If no existing DID method fully meets your needs, but some appear that they may be modifiable or extensible to do so, consider contacting the DID method specification author(s) or following other established procedures to see if collaboration may be possible to support your use case.
• Implementers are cautioned to review OWASP Top 10 - Top 10 is a standard awareness document for developers and web application security.
• Implementers should confirm that each representation they decide to support is interoperable with the same representation in other DID Methods.
• Implementers are NOT required to support all representations (JSON-LD, JSON, XML, CBOR etc). For example, an implementation might choose to only support application/did+json, and choose not to support application/did+ld+json, application/did+dag+cbor, application/did+xml, application/did+yaml, etc.
• DID methods that support both application/did+ld+json and application/did+json ought to return application/did+jsonwith an @context, because it enables both representations to be used with tooling and standards that support semantics and because the default behavior of JSON processors is to ignore object members that are not understood.
• A DID method specification should have a section dedicated to personal data covering the extent to which information published on the corresponding ledger can be updated or deleted.
• A DID method implementer should rotate keys and identifiers as often as possible to avoid correlation
• Avoid hard coupling to specific networks, such as Bitcoin or Hyperledger Fabric. Design your method such that it may be adapted to support multiple ledger systems.

Baseline registration requirements for DID

https://github.com/w3c/did-spec-registries/issues/382

How to register ?

• Sample email where a guy from Accenture asked for the process of adding PR for a new method
• How to register new verification method type - thread on github
• Adding a DID Method to this Registry
• In order to register a new DID method, you must add a JSON file to the ./methods directory and open a pull request to add the file to this repository.
• Take a look at PRs which are unmerged https://github.com/w3c/did-spec-registries/pulls specially this one (https://github.com/w3c/did-spec-registries/pull/394)

Points to be considered for DID Method Registration

As a DID method registrant, I have ensured that my DID method registration complies with the following statements:

• [ ] Define DID scheme : https://www.tyronzil.com/scheme/did-scheme/
• [ ] The DID Method specification defines the DID Method Syntax.
• [ ] The DID Method specification defines the Create, Read, Update, and Deactivate DID Method Operations.
• [ ] The DID Method specification contains a Security Considerations section, https://www.tyronzil.com/security-privacy/#smart-contract-security.
• [ ] The DID Method specification contains a Privacy Considerations section, https://www.tyronzil.com/security-privacy/#privacy-considerations
• [ ] The JSON file I am submitting has passed all automated validation tests below.
• [ ] The JSON file contains a contactEmail address [OPTIONAL].
• [ ] The JSON file contains a verifiableDataRegistry entry [OPTIONAL].

Note : privacy/security considerations section split out and more developed in alignment with section 8.3 and 8.4 of DID-Core

DID method registry tooling

command line tooling and support scripts for the did spec registries.

https://github.com/w3c/did-spec-registries/tree/main/tooling

[Vishwas1]

DID Method name

hid

Method Specific Identifier

The cheqd DID method's method-specific identifier ( method-specific-id ) is made up of the namespace component. The namespace is defined as a string that identifies the cheqd network (e.g., "mainnet", "testnet") where the DID reference is stored. Different cheqd networks may be differentiated based on whether they are production vs non-production, governance frameworks in use, participants involved in running nodes, etc. The namespace associated with a certain network/ledger is stored in the genesis file on the node and cannot be changed by validators vote. A namespace is optional and can be omitted. A did:cheqd DID must be unique by having the unique-id component be derived from the initial public key of the DID. For an Ed25519 public key, the first 16 bytes of the base-58 representation of the 256-bit public key is used to generate the unique-id . If no namespace is specified, it assumed to be default namespace for the network/ledger the request is targetted at. This will generally be mainnet for the primary production cheqd network

Hypersign's DID Method Syntax

The Hypersign DID method ABNF Rules conform with DID syntax guidelines is as follows:

did                 = "did" ":"  method-name  ":" network-namespace ":"  unique-id 
method-name         = "hid"
network-namespace   = "main" / "test"
unique-id           = 32*255id-char
idchar              = ALPHA / DIGIT 

Examples:

A DID written to Hypersign mainnet ledger:

did:hid:main:0x123123123123123123

A DID written to Hypersign testnet ledger:

did:hid:test:0x123123123123123123

DID URL Syntax

https://www.tyronzil.com/scheme/did-url-syntax/

DID Documents (DIDDocs)

Elements needed for a W3C specification compliant DIDDoc representation

Example

Format of didDoc on ledger

"diddoc:<id>" -> {DIDDoc, DidDocumentMetadata, txHash, txTimestamp }

DIDDoc metadata

Verification Method

Verification methods are used to define how to authenticate / authorise interactions with a DID subject or delegates. Verification method is an OPTIONAL property.

Example of Verification method

Service

Example of service

{
"id":"did:cheqd:mainnet:N22KY2Dyvmuu2PyyqSFKue#linked-domain",2
"type": "LinkedDomains",3
"serviceEndpoint": "https://bar.example.com"4
}

DID Operations

Create DID

Update DID

Resolve DID

Deactivate DID

Security Concideration

Privacy Conciderations

Consequences

Positive

Negative

Neutral

References

[Vishwas1]

https://github.com/cosmos/cosmos-sdk/discussions/9337

[Vishwas1]

https://github.com/ayanworks/polygon-did-registrar