DID Method Rubric (SVIP 2-cohort discussion group)

* = Subjective judgment or relative ranking may be required for these properties or priorities.

### A. Interoperability
This DID method meets the interoperability requirements of my project/use case, for example:
1. **Testable Compliance**: All parties that pass the SVIP plugathon test suites can demonstrably verify and resolve all DIDs from my method.
2. **Reasonable Modularity***: I can "switch out" this DID method in the future if my business needs change. This means I can stop using one method and start using another with a reasonable transition period/process without minimal need to replace non-DID components.
3. **Individual DID Freedom**: DIDs can be "rotated"or migrated from one method to another, retaining some verifiable history or minimizing breaking changes to the verifiable data that DID controls.
* [Editor's note: not sure any method has this at time of press, but putting it here for future reference!]

### B. Security
This DID method meets the security requirements of my project/usecase, such as:
1. **Street-legal crypto**: Cryptographic dependencies are explicitly approved for use case in target jurisdiction/industry. Lower score for explicitly allowed by exception, lower-than-that score for ambiguous guidance (i.e., "not illegal").
2. **Ledger/anchoring preferences**: Government can express discretionary preference for anchoring on ledgers it deems more or less reliably, transparently, or publically *governed* or to accomodate other forms of official/public *risk assessment* on long-term viability of an anchoring ledger.
* Ex.: how a given ledger handles hard forks, rollbacks, pruning, and mitigations for security breaches or vulnerabilities.

### C. Key Management Capabilities
1. **Key Recovery**: ********************** **Could someone help formulate this as a rubric?**
4. **Key Rotation**: ***************************
6. **Key Revocation**: Robust and transparent, logged mechanisms for key revocation are needed to implement appropriate interventions.
7. **BYO Key**: Bonus points for stable/production-grade compatibility with hardware-governed KMS, external enterprise KMS, multi-party computation, etc.

### D. Privacy
This DID method meets privacy requirements relevant to my use case, which can be broken down by entity type:

----------------- ***this is not my forté, someone else should take a crack***

1. **Public Issuer Identities** and **Roots of Trust**: Identities for "credential issuers" and government authorities (which are fully public in nature) should allow for high transparency and auditing requirements in the public good.
1. **Identifiers of individuals** should preserve data privacy rights and track consent appropriately for all human identities. This includes minimizing unwanted correlation and tracking, from both private sector, public sector, and malicious actors domestic and foreign.
2. **Identifiers for private-sector organizations** should guarantee confidentiality of business information and appropriate levels of auditability, accountability, and discoverability depending on the class and jurisdiction of the organization.
3. **Identifiers for things** hardware, software, and things need to be tracked with appropriate mechanisms for transfer of ownership and/or control.

### E. Scalability
This DID method meets the scalability needs of my use case, across the entire life cycle and foreseeable future. For example:
1. **Throughput***: Will the system be able to accomodate the volume of traffic achieved if it were used by 100% of actors in the target sector, X years into the future assuming reasonable growth in said sector, where X is the upper bound of potential lifespans of the project
2. **Speed***: Will the user experience of human actors and the operational requirements of nonhuman actors be acceptable at said worst-case-scenario throughputs/volumes?
3. **Cost**: Will costs be acceptable to Government at both maximal- and minimal-scale scenarios?
4. **Stability/maturity***: To what degree are core technologies and dependencies proven and hardened at max/min scale?

### F. Root(s) of Trust
This DID method *appropriately* leverages existing roots of trust that have value for my use case or network (or it is truly decentralized). For example:
1. **Trusted domain** and security perimeter: Can this DID method leverage existing budgets and infrastructure for operational security.
2. **Retrofit existing identifiers & identity systems**: How securely and efficiently can pre-existing identifier/identity schemes be "wrapped" or bound to new ones?
3. **Existing credentials**: How securely and efficiently can pre-existing and/or externally-governed systems for signing verifiable data be integrated or bound to this method's DIDs?