w3c
Review of Security Considerations
Remove several extremely contentious and void-for-vagueness paragraphs in order to improve the Security Considerations section.
Pay very close attention to the defense, cryptographic agility, and political acceptability of any cryptography you rely on for DID Method security.
What is the defense of a cryptography?
What is cryptographic agility?
In which part of the world should I gauge political acceptability?
Remove paragraph.
Competition, direct substitutability, interoperability, and mutual feature support are key to reducing the barriers to adoption of, and increasing confidence in, your DID Method.
How does competition reduce the barriers to adoption of your DID Method?
How does competition increase confidence in your DID Method?
What is direct substitutability?
How does direct substitutability reduce the barriers to adoption of your DID Method?
How does direct substitutability increase confidence in your DID Method?
What is interoperability? Does it mean that your DID Documents comply with the DID Core v1.0 spec? Does it mean that another app can get a DID Document when given a DID from your DID Method? That would mean someone included your library in their app, or they were able to read your DID Method spec and reimplement. And that could have been a well-known resolver, so that anyone can get the DID Document with a simple HTTP query.
What is mutual feature support besides complying with the DID Core v1.0 spec in order to allow interoperability?
There is already an entire section titled "Method Reuse is Encouraged".
Remove paragraph, rename subsection.
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.
The notion of "cross-chain" IDs is not compatible with updating and revocation. Supporting those - ahem, required features - would in turn require code (and storage) to actually follow transactions on every cross-chain VDR. If an app developer or browser maker had libraries for certain VDRs, then they might as well use the native DID Methods for those VDRs. As things exist now, minor DID Methods will see interoperability when supported via popular resolvers.
Remove paragraph.
Avoid secp256k1, RSA, P-256, P-384 and P-521.
No.
Remove advisement.
Avoid relying on smart contracts for complex data management. If you must use a smart contract, keep it simple and architect a solution that supports data migration.
What are smart contracts?
Why should they not be relied on?
What is data migration in a smart contract setting?
What is a simple smart contract?
Remove paragraph.
Can we split up this PR into smaller ones that impact only 1 section at a time.
Yes.
I agree with the previous comment that it would be helpful to split this up into multiple PRs. There are several different topics that seem unrelated, e.g. smart contracts, vendor lock-in, etc.
I agree with some of @rxgrant 's comments, e.g. it feels strange that there is a statement "Avoid secp256k1, RSA, P-256, P-384 and P-521." without further explanation.
I also agree with @OR13 's comments that it would be preferable to add additional explanation, or alternate viewpoints, rather than simply removing things.
"Avoid the most battle tested curve in the history of cryptography that has withstood a multi-hundred billion dollar bug bounty for the better part of a decade" - my reaction:
