add did:swtc method

[GinMu]

Instructions for Pull Requests

Please read these instructions thoroughly in order to ensure that your pull request is processed in a timely manner. This document contains detailed instructions for registering a DID Method. If your pull request concerns some other change to the repository, you may delete all of the text in this text box and write up a more relevant description.

There is a DID Method Registration form below that MUST be included in a DID Method Registration Request. The form includes check boxes that you are expected to fill out when you submit your request.

Once you submit your request, your pull request will be reviewed by the registry editors. Changes regarding the required criteria may be requested. If there are no objections or changes requested, your DID method will be registered after a minimum of 7 days.

DID Method Registration Process

In order to register a new DID method, you must add a JSON file to the ./methods directory.

Here is an example registration entry:

{
  // These fields are required
  "name": "example",
  "status": "registered",
  "specification": "https://w3c-ccg.github.io/did-spec/",
  // These fields are optional
  "contactName": "W3C Credentials Community Group",
  "contactEmail": "",
  "contactWebsite": "",
  "verifiableDataRegistry": "DID Specification"
}

Your Pull Request will be automatically validated, please ensure that all of the automated tests pass (no errors reported) or your submission will not be reviewed. Common reasons for failed validation includes invalidly formatted JSON files and missing mandatory fields.

----- DID METHOD REGISTRATION FORM: DELETE EVERYTHING ABOVE THIS LINE ------

DID Method Registration

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

• 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.
• The DID Method specification contains a Privacy Considerations section.
• 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].

[ottomorac]

Hello @GinMu ,

Good day. After an initial review, I have some feedback:

DID Method Structure
You need to add a section a the beginning that describes your did method structure:

Samples here:

• https://identity.foundation/didwebvh/v1.0/#method-name
• https://github.com/iden3/did-iden3/blob/main/did-iden3-method.md#method-specific-identifier
• https://docs.cheqd.io/product/architecture/adr-list/adr-001-cheqd-did-method#method-specific-identifier

CRUD Operations

Your CRUD operations should be described in at least a few bullets. Providing code is fine, but there should be human readable explanations of the CRUD methods that you support (ideally an algorithm describing the steps):

Samples here:

• https://identity.foundation/didwebvh/v1.0/#did-method-operations
• https://github.com/iden3/did-iden3/blob/main/did-iden3-method.md#basic-operations
• https://docs.cheqd.io/product/architecture/adr-list/adr-001-cheqd-did-method#update-did

Security and Privacy Considerations section
You need to add a"Security and Privacy Considerations section" . Ideally the "Security and Privacy Considerations" section. should have a few paragraphs of the privacy and security implications of implementing your specification. Some examples here:

• https://identity.foundation/didwebvh/v1.0/#security-considerations
• https://docs.cheqd.io/product/architecture/adr-list/adr-001-cheqd-did-method#security-considerations
• https://github.com/iden3/did-iden3/blob/main/did-iden3-method.md#security-and-privacy-considerations

Suggest you address these points and then we can review again. Thank you.

[GinMu]

@ottomorac Thanks for the review! I applied the suggested change and pushed a new commit. Please take another look when you have a moment.

[ottomorac]

Thanks @GinMu . The entry meets the minimum criteria, Approved. You will need one additional review from others in the group before this can be merged.

[ottomorac]

Also I might suggest that you indicate that the DELETE operation is not supported in your spec (at least that was my understanding from reading it).

[GinMu]

Also I might suggest that you indicate that the DELETE operation is not supported in your spec (at least that was my understanding from reading it).

The DELETE method is not currently supported. You can achieve deletion by writing empty data (i.e., overwriting the item with an empty payload).

[ottomorac]

The DELETE method is not currently supported. You can achieve deletion by writing empty data (i.e., overwriting the item with an empty payload).

Understood. 👍 Then perhaps you may want to add that explanation in the spec for the did:swtc DID method.

[GinMu]

The DELETE method is not currently supported. You can achieve deletion by writing empty data (i.e., overwriting the item with an empty payload).

Understood. 👍 Then perhaps you may want to add that explanation in the spec for the did:swtc DID method.

I’ve already added that explanation to the spec for the did:swtc DID method. 🤝

[swcurran]

I agree that the submission meets the minimum requirements for approval, but I do have a few suggestions and comments about the spec.

• It would be nice to have in the introduction the use cases for the DID Method and why the name is "swtc". What is the "SWT Chain", and how it relates to the use of IPFS MFS. This would help newcomers to understand what the DID Method is about.
• It would be nice to have a definition of what this means "Convert public key from keypair into an SWTC address.". What is an SWTC address exactly, and how does one convert a key to it?
• Is there a defined relationship between the key pair used to create the SWTC address and the key in the DID Doc? I'm assuming so, but couldn't tell from the spec.
• The JSON-LD document below the steps is labelled as being the "JSON-LD context", but it is actually an example DID Document. The label should be changed.
• Not crucial, but I'm intrigued about how the indexing of the DID identifier allows for the discovery of the DID Document associated with it on IPFS MFS. Especially after an update to the DID Document.
• When a DID Document is updated, can any part of the DID Document change? Most importantly, can the key be rotated to a public key of a new key pair.

Happy to approve with or without answers to those questions/comments.