Add did:drop method

[tenman1739-alt]

----- 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:

• [x ] The DID Method specification defines the DID Method Syntax.
• [x ] The DID Method specification defines the Create, Read, Update, and Deactivate DID Method Operations.
• [x ] The DID Method specification contains a Security Considerations section.
• [x ] The DID Method specification contains a Privacy Considerations section.
• [x ] The JSON file I am submitting has passed all automated validation tests below.
• [x ] The JSON file contains a contactEmail address [OPTIONAL].
• [x ] The JSON file contains a verifiableDataRegistry entry [OPTIONAL].

[tenman1739-alt]

I do believe my system being, unique in the registry, should have the opportunity.

[ottomorac]

Hello @tenman1739-alt ,

Thank you for your submission. Upon reviewing, I have some feedback regarding the "Security & Privacy Considerations" section. I assume that the public and private keys mentioned in the spec are required to read and write data in the Algorand chain? Perhaps you can discuss security considerations around those in more detail. The section should discuss some aspects public/private key handling and any other privacy and security implications of implementing your specification. Some examples here:

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

[tenman1739-alt]

Hello @tenman1739-alt ,

Thank you for your submission. Upon reviewing, I have some feedback regarding the "Security & Privacy Considerations" section. I assume that the public and private keys mentioned in the spec are required to read and write data in the Algorand chain? Perhaps you can discuss security considerations around those in more detail. The section should discuss some aspects public/private key handling and any other privacy and security implications of implementing your specification. Some examples here:

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

Hello Otto. I have updated/revised the final sections in security and considerations. Be advised since this is preliminary, I am treating some of the data as Raw/Unprocessed. In retrospect arguable no identifying data is stored only Crypto Hash of pointers.

[swcurran]

While I don't fully understand exactly what is happening, I think the spec is complete enough to meet the requirements for registration. A bit more of an example might help, showing what a did:drop DID Document would contain beyond the DID Core fields -- notably the missionEndpoint object. However, presumably someone with expertise in the field would understand what is being said -- e.g. MAT Generation, Proof of Consumption.

All that said, I think there is sufficient information for registration.

[tenman1739-alt]

While I don't fully understand exactly what is happening, I think the spec is complete enough to meet the requirements for registration. A bit more of an example might help, showing what a did:drop DID Document would contain beyond the DID Core fields -- notably the missionEndpoint object. However, presumably someone with expertise in the field would understand what is being said -- e.g. MAT Generation, Proof of Consumption.

All that said, I think there is sufficient information for registration.

Great, that lives, Otto. I will do more I depth on the Spec Sheet programmatically. I am waiting on the approval first.