diff --git a/.github/workflows/auto-publish.yml b/.github/workflows/auto-publish.yml
index e5b071d..001f2b2 100644
--- a/.github/workflows/auto-publish.yml
+++ b/.github/workflows/auto-publish.yml
@@ -6,10 +6,26 @@ on:
 jobs:
   main:
     name: Build, Validate and Deploy
-    runs-on: ubuntu-20.04
+    runs-on: ubuntu-latest
     steps:
-      - uses: actions/checkout@v2
-      - uses: w3c/spec-prod@v2
+      - name: Checkout source...
+        uses: actions/checkout@v4
+      - name: Set up Node.js
+        uses: actions/setup-node@v4
+        with:
+          node-version: '22.x'
+      - name: Install did-rubric tooling...
+        working-directory: tooling
+        run: npm i
+      - name: Validate did-rubric template and criteria
+        working-directory: tooling
+        run: npm run validate-rubric
+      - name: Generate did rubric JSON from template and criteria
+        working-directory: tooling
+        run: npm run generate-rubric
+      - name: Begin W3C Spec Prod Deployment
+        if: github.event_name == 'push'
+        uses: w3c/spec-prod@v2
         with:
           W3C_ECHIDNA_TOKEN: ${{ secrets.W3C_TR_TOKEN }}
           W3C_WG_DECISION_URL: https://www.w3.org/2019/did-wg/Meetings/Minutes/2021-08-17-did#resolution2
diff --git a/.github/workflows/deploy-pages.yml b/.github/workflows/deploy-pages.yml
new file mode 100644
index 0000000..8c512ff
--- /dev/null
+++ b/.github/workflows/deploy-pages.yml
@@ -0,0 +1,50 @@
+name: Deploy GitHub Pages
+on:
+  push:
+    branches:
+      - "**"
+  workflow_dispatch: {}
+
+permissions:
+  contents: write
+
+jobs:
+  build:
+    name: Build and Deploy Pages
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout source
+        uses: actions/checkout@v4
+      - name: Set up Node.js
+        uses: actions/setup-node@v4
+        with:
+          node-version: "22.x"
+      - name: Install tooling dependencies
+        working-directory: tooling
+        run: npm i
+      - name: Validate rubric
+        working-directory: tooling
+        run: npm run validate-rubric
+      - name: Generate rubric JS
+        working-directory: tooling
+        run: npm run generate-rubric
+      - name: Prepare site bundle
+        run: |
+          mkdir -p site/rubric site/tooling/src
+          cp index.html common.js site/
+          cp rubric/rubric.js site/rubric/
+          cp tooling/src/render-criteria.js site/tooling/src/
+      - name: Select deploy target folder
+        id: deploy_target
+        run: |
+          if [ "${{ github.ref_name }}" = "main" ]; then
+            echo "target=" >> "$GITHUB_OUTPUT"
+          else
+            echo "target=${{ github.ref_name }}" >> "$GITHUB_OUTPUT"
+          fi
+      - name: Deploy to GitHub Pages
+        uses: JamesIves/github-pages-deploy-action@v4
+        with:
+          branch: gh-pages
+          folder: site
+          target-folder: ${{ steps.deploy_target.outputs.target }}
diff --git a/.gitignore b/.gitignore
index 485dee6..815c569 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,4 @@
 .idea
+.history
+rubric/rubric.js
+node_modules/
diff --git a/README.md b/README.md
index c09e87d..ad41808 100644
--- a/README.md
+++ b/README.md
@@ -5,6 +5,18 @@
 
 This is the repository of the W3C’s note on DID Method Rubric v1.0, developed by the [DID Working Group](https://www.w3.org/2019/did-wg/). The editors’ draft of the specification can also be [read directly](https://w3c.github.io/did-rubric/).
 
+## Generate the DID Rubric from JSON
+
+Follow these steps to generate the DID Rubric `rubric.js` file from the
+`rubric-outline.json` and `criteria` under the `rubric` folder.
+
+1. `cd tooling`
+2. `npm install`
+3. `npm run validate-rubric`
+4. `npm run generate-rubric`
+5. Open the `index.html` file in browser
+
+
 ## Contributing to the Repository
 
 Use the standard fork, branch, and pull request workflow to propose changes to the specification. Please make branch names informative—by including the issue or bug number for example.
@@ -25,3 +37,4 @@ W3C functions under a [code of conduct](https://www.w3.org/Consortium/cepc/).
 * [W3C Decentralized Characteristics Rubric v1.0](https://github.com/w3c/did-rubric)
 * [Decentralized Identifier Use Cases v1.0](https://github.com/w3c/did-use-cases)
 * [W3C DID Test Suite and Implementation Report](https://github.com/w3c/did-test-suite)
+
diff --git a/index.html b/index.html
index 049daf7..983ed66 100644
--- a/index.html
+++ b/index.html
@@ -3,9 +3,12 @@
 
 <head>
   <meta charset="utf-8">
-  <title>DID Method Rubric v1.0</title>
+  <title>DID Method Rubric v2.0</title>
   <script src="https://www.w3.org/Tools/respec/respec-w3c" defer="defer" class="remove"></script>
   <script class='remove' src="./common.js"></script>
+  <script src="./tooling/src/render-criteria.js" class="remove"></script>
+  <script src="./rubric/rubric.js"></script>
+
   <script class='remove'>
     // See https://github.com/w3c/respec/wiki/ for how to configure ReSpec
     var respecConfig = {
@@ -17,7 +20,7 @@
       shortName: "did-rubric",
 
       // specification status (e.g., WD, LCWD, NOTE, etc.). If in doubt use ED.
-      specStatus: "FPWD-NOTE",
+      specStatus: "NOTE",
 
       // Editor's Draft URL
       edDraftURI: "https://w3c.github.io/did-rubric/",
@@ -34,6 +37,7 @@
 
       // extend the bibliography entries
       localBiblio: ccg.localBiblio,
+      preProcess: [window.renderCategories],
 
       github: {
         repoURL: "https://github.com/w3c/did-rubric/",
@@ -128,7 +132,7 @@
     </p>
     <p>
       This rubric is a collection of criteria for creating Evaluation
-      Reports that assist people in choosing a DID Method. 
+      Reports that assist people in choosing a DID Method.
 
       While this rubric assists in the evaluation of many aspects of a
       DID Method, it is not exhaustive.
@@ -443,18 +447,23 @@ <h3>DID Evaluations Cited</h3>
         </tr>
         <tr id="eval-3">
           <td>eval-3</td>
-          <td>"A Rubric for Decentralization of DID Methods". Joe Andrieu, Shannon Appelcline,
-            Amy Guy, Joachim Lohkamp, Drummond Reed, Markus Sabadello, Oliver Terbu. <cite>Rebooting
-              the Web of Trust</cite>. Published 2020-07-20. <a
-              href="https://github.com/WebOfTrustInfo/rwot9-prague/blob/master/final-documents/decentralization-rubric.pdf">
-              https://github.com/WebOfTrustInfo/rwot9-prague/blob/master/final-documents/decentralization-rubric.pdf</a>.
+          <td>VeresOne Rubric Evaluation</td>
+          <td>Funded by Digital Bazaar under DHS SVIP contract 70RSAT20T00000029.
+            Available at <a href="https://didevaluations.com/evals/v1.2022.03.01.pdf">https://didevaluations.com/evals/v1.2022.03.01.pdf</a>.
           </td>
-          <td>The original DID Rubric paper from Rebooting the Web of Trust. Not explicitly funded.</td>
         </tr>
         <tr id="eval-4">
           <td>eval-4</td>
-          <td>VeresOne Rubric Evaluation</td>
-          <td>Funded by Digital Bazaar under DHS SVIP contract 70RSAT20T00000029.</td>
+          <td>DID Web Rubric Evaluation</td>
+          <td>Funded by Digital Bazaar under DHS SVIP contract 70RSAT20T00000029.
+            Available at <a href="https://didevaluations.com/evals/web.2022.03.01.pdf">https://didevaluations.com/evals/web.2022.03.01.pdf</a>.</td>
+        </tr>
+        <tr id="eval-5">
+          <td>eval-5</td>
+          <td>DID Ion Rubric Evaluation</td>
+          <td>Funded by Digital Bazaar under DHS SVIP contract 70RSAT20T00000029.
+            Available at <a href="https://didevaluations.com/evals/ion.2022.03.01.pdf">https://didevaluations.com/evals/ion.2022.03.01.pdf</a>.
+          </td>
         </tr>
       </table>
     </section>
@@ -773,7 +782,7 @@ <h3>Criteria and Criterion</h3>
         sentence in the previous paragraph <em>should</em> be "Select one
         criterion from the list of criteria." </p>
       <p>As editors of a Note published by the World Wide Web Consortium,
-        we are torn. We would prefer to use 
+        we are torn. We would prefer to use
         rigorous grammar and be consistent in doing so. At the same time,
         we find attempts to enforce the formal rule sometimes leads people
         to using the inverse, such as "Select a criteria from the list of
@@ -784,7 +793,7 @@ <h3>Criteria and Criterion</h3>
         used, even alongside plural usage. Since the DID Method Rubric
         is, at its core, a set of criteria with ample reason to refer to,
         for example, "Criteria #23", we find the combined singular and
-        plural use is cleaner (just stick with "criteria"), less 
+        plural use is cleaner (just stick with "criteria"), less
         confusing, and more aligned with common usage among our audience.</p>
       <p>As such, throughout the DID Method Rubric, we use the term
         "criteria" to refer to both singular instances of
@@ -802,27 +811,27 @@ <h3>General Requirements</h3>
       <ol>
       <li>If there are copyright, trademark, or intellectual property
       rights concerns, the addition and use MUST be authorized
-      in writing by the intellectual property rights holder under a F/RAND 
+      in writing by the intellectual property rights holder under a F/RAND
       license. For example, criteria that use trademarked brand names, use the titles or excerpts from copyrighted works, or require patented technology to perform the evaluation.
       </li>
-      <li>Additions MUST NOT create unreasonable legal, security, 
+      <li>Additions MUST NOT create unreasonable legal, security,
       moral, or privacy issues that may result in direct or
       indirect harm to others, including violations of the W3C Code Of
       Ethics And Professional Conduct <a href="https://www.w3.org/Consortium/cepc/">
       https://www.w3.org/Consortium/cepc/</a>
-      Examples of unacceptable additions include 
+      Examples of unacceptable additions include
       any containing hate speech, unprofessional or
-      unethical attacks, proprietary information, and any personal data or 
+      unethical attacks, proprietary information, and any personal data or
       personally identifiable information (excepting
       identification details of the submitter).
             </li>
       <li>All criteria MUST be uniquely identified and versioned to ensure
       permanent linkability with version trackability. Those
-      identifiers MUST be present as an `href` anchor in the HTML for the 
+      identifiers MUST be present as an `href` anchor in the HTML for the
       criteria itself. See the sections below on identifiers
-      and versioning. Subcomponents, such as questions, responses, 
+      and versioning. Subcomponents, such as questions, responses,
       relevance, and examples, are not separately versioned; any
-      change to a subcomponent triggers an appropriate version change to 
+      change to a subcomponent triggers an appropriate version change to
       its primary component.
       </li>
       <li>Use cases, methods, and evaluations cited within a criteria MUST
@@ -830,22 +839,22 @@ <h3>General Requirements</h3>
       the relevant citation section: Use Cases Referenced,
       Methods Evaluated, and Evaluations Cited, respectively.
       </li>
-      <li>Rubric criteria and associated metadata in the DID Method 
+      <li>Rubric criteria and associated metadata in the DID Method
       Rubric Registry MAY be updated or removed at the editors’
-      discretion, including the addition or removal of categories of 
+      discretion, including the addition or removal of categories of
       metadata such as <em>Use Cases Referenced</em> or <em>Implementations
       of Note</em>.</li>
       </ol>
     </section>
     <section>
     <h3>Component Requirements</h3>
-    <p>The primary components managed by this registry are criteria for 
+    <p>The primary components managed by this registry are criteria for
     evaluating DID Methods, with as many as eight
-    subcomponents: name, id, version, question, responses, relevance, 
+    subcomponents: name, id, version, question, responses, relevance,
     examples, and, optionally, a source. In addition, the
-    DID Method Rubric maintains a list of cited references: DID methods, 
+    DID Method Rubric maintains a list of cited references: DID methods,
     use cases, and evaluations. The criteria are
-    independently identified and versioned (see those sections for 
+    independently identified and versioned (see those sections for
     details) while references cited in the criteria
     themselves link to their full citation in the appropriate list.</p>
       <section>
@@ -854,9 +863,9 @@ <h4>Criteria</h4>
         <li>Updates to criteria MUST follow the following versioning
         guidelines.
         </li>
-        <li>Proposed criteria without at least three independent example 
+        <li>Proposed criteria without at least three independent example
         evaluations MUST have the word “PROVISIONAL” as the last
-        term in its name. Once at least three independent example 
+        term in its name. Once at least three independent example
         evaluations exist, the word “PROVISIONAL” SHOULD be removed.
         </li>
         <li>Accepted (non-provisional) criteria MUST have at least three example evaluations, and generally SHOULD have no more example
@@ -900,7 +909,7 @@ <h4>Criteria</h4>
       </section> <!-- criteria -->
       <section>
         <h4>Criteria.Name</h4>
-        <p>Each criteria needs a human-friendly, short, descriptive name 
+        <p>Each criteria needs a human-friendly, short, descriptive name
         that captures the essence of the criteria as concisely as
         possible.</p>
       </section> <!-- Criteria.Name -->
@@ -911,15 +920,15 @@ <h4>Criteria.Id</h4>
       </section> <!-- Criteria.Id -->
       <section>
         <h4>Criteria.Version</h4>
-        <p>The criteria version must increment, as appropriate, any time 
+        <p>The criteria version must increment, as appropriate, any time
         the criteria, or any of its subcomponents, is updated. See
         the section on <a href="#versioning">Versioning</a> for details.</p>
       </section> <!-- Criteria.Version -->
       <section>
         <h4>Criteria.Question</h4>
-        <p>This subcomponent presents the key question for evaluating the 
+        <p>This subcomponent presents the key question for evaluating the
         criteria. The question MUST be a single inquiry that gets to
-        the heart of the criteria. It should be reasonably clear to a 
+        the heart of the criteria. It should be reasonably clear to a
         competent professional skilled in the art how to resolve
         the question into one of the possible responses.</p>
       </section> <!-- Criteria.Question -->
@@ -931,7 +940,7 @@ <h4>Criteria.Responses</h4>
         Responses are either labeled or open ended.
         </li>
         <li>
-        Labeled responses MUST include a label and a meaning for that 
+        Labeled responses MUST include a label and a meaning for that
         label.
         </li>
         <li>
@@ -944,16 +953,16 @@ <h4>Criteria.Responses</h4>
       </section> <!-- Criteria.Responses -->
       <section>
         <h4>Criteria.Relevance</h4>
-        <p>This subcomponent explains why this criteria is useful. Readers 
+        <p>This subcomponent explains why this criteria is useful. Readers
         should be able to understand the extent to which this
-        particular criteria is applicable to their situation. 
+        particular criteria is applicable to their situation.
         </p>
       </section> <!-- Criteria.Relevance -->
       <section>
         <h4>Criteria.Examples</h4>
-        <p>This section lists example evaluations of different DID methods 
+        <p>This section lists example evaluations of different DID methods
         using this criteria, presented as a table for easy
-        correlation between evaluations of different methods using the 
+        correlation between evaluations of different methods using the
         same criteria.
         </p>
         <ol>
@@ -968,93 +977,93 @@ <h4>Criteria.Examples</h4>
         Some criteria MAY require an additional "Referent" entry, in its
         own column in the examples table.
         </li>
-        <li>Example Evaluations for a given criteria SHOULD highlight 
+        <li>Example Evaluations for a given criteria SHOULD highlight
         distinct responses. That is, each evaluation should have a
-        different set of responses from the other example evaluations. 
+        different set of responses from the other example evaluations.
         The point of the examples is to illustrate how different
         DID methods score differently.</li>
-        <li>The editors will curate the list of proposed examples to 
+        <li>The editors will curate the list of proposed examples to
         provide a best effort illustration of each criteria, with
         consideration to highlighting a broad corpus of methods.</li>
-        <li>Criteria with fewer than 3 example evaluations MUST be 
+        <li>Criteria with fewer than 3 example evaluations MUST be
         marked “PROVISIONAL”</li>
-        <li>Criteria SHOULD have no more example evaluations than there 
+        <li>Criteria SHOULD have no more example evaluations than there
         are possible responses.</li>
         </ol>
         <section>
           <h4>Criteria.Examples.Method</h4>
           <ol>
-            <li>Example evaluations MUST specify the evaluated method in 
+            <li>Example evaluations MUST specify the evaluated method in
             the first column, using a relative link to the method’s entry
-            in the Methods Evaluated section. The entry in the Methods 
+            in the Methods Evaluated section. The entry in the Methods
             Evaluated table MUST conform to the requirements in that
-            section. 
+            section.
             </li>
             <li>The title of this column MUST be “Method”.
             </li>
-            <li>The Method entry MUST uniquely identify a specific 
+            <li>The Method entry MUST uniquely identify a specific
             DID Method specification suitable for evaluation,
-            including any specified variant such as testnet, mainnet, 
+            including any specified variant such as testnet, mainnet,
             etc.
-            </li>            
+            </li>
           </ol>
         </section><!-- Criteria.Examples.Method-->
         <section>
           <h4>Criteria.Examples.Referent</h4>
           <ol>
-            <li>Evaluations MAY refer to open ended responses from other 
+            <li>Evaluations MAY refer to open ended responses from other
             evaluations. If present, this referent MUST be listed as a
-            possible response in another criteria’s evaluation. In this 
+            possible response in another criteria’s evaluation. In this
             manner, a first criteria can elicit structural elements to
-            be separately evaluated in subsequent criteria. This 
-            “structure-variable” pattern allows the Rubric to support 
-            criteria that matches the structural complexity of the 
+            be separately evaluated in subsequent criteria. This
+            “structure-variable” pattern allows the Rubric to support
+            criteria that matches the structural complexity of the
             Method in question.
             </li>
             <li>If present, the Referent MUST be in the second column
             </li>
-            <li>The column title MUST be appropriate for the referred 
-            structure, e.g., “Layer” or “Governing body”, as understood 
+            <li>The column title MUST be appropriate for the referred
+            structure, e.g., “Layer” or “Governing body”, as understood
             by the criteria which establishes the structural elements.
             </li>
           </ol>
-        </section><!-- Criteria.Examples.Referent-->          
+        </section><!-- Criteria.Examples.Referent-->
         <section>
           <h4>Criteria.Examples.Responses</h4>
           <ol>
-            <li>Example evaluations MUST include at least one response, 
-            and may include multiple columns when appropriate. Each 
-            column allows for responses to particular system elements 
+            <li>Example evaluations MUST include at least one response,
+            and may include multiple columns when appropriate. Each
+            column allows for responses to particular system elements
             such as “Specification”, “Network”, and “Registry”.
             </li>
             <li>
-            Column names such as "Specification", "Network", and 
+            Column names such as "Specification", "Network", and
             "Registry" may be abbreviated as "Spec.", "Net.", and "Reg."
             </li>
             <li>
-            The number and labels for response columns MUST be proposed 
+            The number and labels for response columns MUST be proposed
             by the initial PR and will be finalized when the criteria
             moves from PROVISIONAL to accepted.
             </li>
-            <li>Each column MUST contain an entry that communicates the 
+            <li>Each column MUST contain an entry that communicates the
             evaluator’s judgment of the best response to the question for
             this method for that element (Spec, Reg, Net).
             </li>
-            <li>For improved comparability across different methods, 
-            responses SHOULD be based on the possible responses listed 
-            in the criteria. However, evaluators MAY provide any 
+            <li>For improved comparability across different methods,
+            responses SHOULD be based on the possible responses listed
+            in the criteria. However, evaluators MAY provide any
             appropriate response, based on their own judgment
             </li>
             <li>
-            Responses MAY be a variant of the Possible Responses, to 
+            Responses MAY be a variant of the Possible Responses, to
             capture a nuance beyond those listed. For example, one might
-            append a “+” or a “-”, e.g., A+, or even provide two 
-            different responses when different situations merit a 
-            distinction, e.g., A/D. The reasoning behind these variants 
+            append a “+” or a “-”, e.g., A+, or even provide two
+            different responses when different situations merit a
+            distinction, e.g., A/D. The reasoning behind these variants
             &nbps;
             SHOULD be explained in the Notes column.
             </li>
-            <li>A response of “n/a” (short for Not Applicable) SHOULD be 
+            <li>A response of “n/a” (short for Not Applicable) SHOULD be
             used if the criteria doesn’t apply to the evaluated method.
             </li>
           </ol>
@@ -1062,35 +1071,35 @@ <h4>Criteria.Examples.Responses</h4>
         <section>
           <h4>Criteria.Examples.Notes</h4>
           <ol>
-            <li>This entry SHOULD include any details that help explain 
+            <li>This entry SHOULD include any details that help explain
             why that particular response was chosen.It MAY be blank.
             However, the column MUST be included.</li>
-            <li>The Notes entry MUST specify a distinct use case listed 
-            explicitly in this registry in the Use Cases Referenced 
+            <li>The Notes entry MUST specify a distinct use case listed
+            explicitly in this registry in the Use Cases Referenced
             section, using the label from that section.
             <ol type="a">
               <li>
                 The use case label MUST be delimited by square brackets.
               </li>
               <li>
-                The label text itself must be a hyperlink to the entry 
-                in the Use Cases Referenced section, for example [UC.1] 
-                where “UC.1” links to “#useCase-1” in the current 
+                The label text itself must be a hyperlink to the entry
+                in the Use Cases Referenced section, for example [UC.1]
+                where “UC.1” links to “#useCase-1” in the current
                 document.
               </li>
             </ol>
             <li>
-              The Notes entry MUST identify a published evaluation by 
-              reference to an entry in the Evaluations Cited section of 
+              The Notes entry MUST identify a published evaluation by
+              reference to an entry in the Evaluations Cited section of
               the Rubric, using the label from that section.
             <ol>
               <li>
-                The evaluation label MUST be delimited by square 
+                The evaluation label MUST be delimited by square
                 brackets.
               </li>
               <li>
-                The label text itself must be a hyperlink to the entry 
-                in the Evaluations Cited section, for example [E.1] 
+                The label text itself must be a hyperlink to the entry
+                in the Evaluations Cited section, for example [E.1]
                 where “E.1” links to “#eval-1” in the current document.
               </li>
             </ol>
@@ -1100,13 +1109,13 @@ <h4>Criteria.Examples.Notes</h4>
       </section> <!-- Criteria.Examples -->
       <section>
         <h4>Criteria.Source</h4>
-        <p>This subcomponent, if present, MUST list the specific 
-        external source of the criteria, if any, by referring to its 
-        entry in the Rubric’s list of Sources Cited. Source entries 
-        should include both the name (or title) of the source as well as 
-        a URL. When possible, sources should specify the precise page, 
+        <p>This subcomponent, if present, MUST list the specific
+        external source of the criteria, if any, by referring to its
+        entry in the Rubric’s list of Sources Cited. Source entries
+        should include both the name (or title) of the source as well as
+        a URL. When possible, sources should specify the precise page,
         section, and/or anchor that points to the specific criteria
-        in the source document. Each source listed in the criteria MUST 
+        in the source document. Each source listed in the criteria MUST
         also be listed in the Sources Cited section.
         </p>
       </section> <!-- Criteria.Source -->
@@ -1115,79 +1124,79 @@ <h4>Criteria.Source</h4>
       <h3>Identifiers</h3>
       <p>Each criteria must be explicitly, uniquely, and persistently
        identified using incremental numbers. New criteria should
-      use the next available increment based on the highest numbered 
+      use the next available increment based on the highest numbered
       identifier in the current publication.</p>
-      <p>Previous numbered identifiers MUST NOT be re-used, even if the 
+      <p>Previous numbered identifiers MUST NOT be re-used, even if the
       criteria so identified are no longer published; this
-      maintains the persistent linkability of previously published 
+      maintains the persistent linkability of previously published
       versions. Such “retired” criteria MAY be listed in a Prior
-      Criteria section linking directly to the latest published Rubric 
+      Criteria section linking directly to the latest published Rubric
       containing the retired criteria; this Prior Criteria
       section MUST also contain an anchor with the canonical id.</p>
       <p>The registry shall maintain an entry with the “next available”
       number. Additions should use the “next available”
-      number to construct an identifier for the new criteria, and update 
+      number to construct an identifier for the new criteria, and update
       the “next available” entry at the same time. Editors
       will manage any sequencing errors when accepting PRs.</p>
-      
-      <p>Identifiers must be constructed by appending that numerical value 
+
+      <p>Identifiers must be constructed by appending that numerical value
       to the string “criteria-” and incorporated in the ID
-      of the heading element for that criteria, which when placed in the 
+      of the heading element for that criteria, which when placed in the
       Rubric appears as something like (note the version in
       its own span after the permalink):
       <pre class="example nohighlight" title="Example criteria numbering">
       &lt;h4 id="criteria-1"&gt;Open contribution (participation)&lt;/h4&gt;
       &lt;a href="#criteria-1"&gt;https://www.w3.org/TR/did-rubric#criteria-1&lt;/a&gt; &lt;span&gt;1.0.0&lt;/span&gt;
       </pre>
-      This allows permanent links to citations based on the publication 
+      This allows permanent links to citations based on the publication
       date of a given Rubric:
 <a href="https://www.w3.org/TR/2021/NOTE-did-rubric-20210826/#criteria-32">https://www.w3.org/TR/2021/NOTE-did-rubric-20210826/#criteria-32</a> as well as version-free links that resolve to the
-      latest version of the criteria, and if retired, to an entry in the 
+      latest version of the criteria, and if retired, to an entry in the
       Prior Criteria list which itself links to the last
-      valid presentation of the criteria, so that, for example, <a 
+      valid presentation of the criteria, so that, for example, <a
       href="https://www.w3.org/TR/did-rubric/#criteria-32">https://www.w3.org/TR/did-rubric/#criteria-32</a> points to the
-      current criteria-32 in the latest published document. When that 
+      current criteria-32 in the latest published document. When that
       criteria is retired, that same URL points to the entry
-      in the Prior Criteria list, which links to its last versioned 
+      in the Prior Criteria list, which links to its last versioned
       publication, e.g.,
       <a href="https://www.w3.org/TR/2021/NOTE-did-rubric-20210826/#criteria-32">https://www.w3.org/TR/2021/NOTE-did-rubric-20210826/#criteria-32</a>
     </section> <!-- Identifiers -->
     <section>
       <h3 id="versioning" >Versioning</h3>
-      <p>Criteria versions allow for incremental improvements while 
+      <p>Criteria versions allow for incremental improvements while
       retaining long-term referenceability.</p>
       <ol>
-      <li>Versions contain a Major, Minor, and Patch number, based on 
+      <li>Versions contain a Major, Minor, and Patch number, based on
       SemVer 2.0
       </li>
       <li>Every new criteria has a version of 1.0.0, even if PROVISIONAL.
       </li>
-      <li>Updates to criteria must increment the appropriate version 
+      <li>Updates to criteria must increment the appropriate version
       number based on the scope of change:
       <ol type="a">
-        <li><strong>Major</strong> number MUST increment if, <em>and only if</em>, 
-        the criteria is fundamentally changed in a way that invalidates 
+        <li><strong>Major</strong> number MUST increment if, <em>and only if</em>,
+        the criteria is fundamentally changed in a way that invalidates
         existing
-        evaluations. This could be a material change to any subcomponent 
+        evaluations. This could be a material change to any subcomponent
         of the criteria, including removing or changing
         Possible Responses.
         </li>
-        <li><strong>Minor</strong> number MUST increment if, <em>and only 
-        if</em>, new responses are added, without invalidating existing 
-        responses. It’s understood that an evaluator of an existing 
-        evaluation may desire to choose the new response if they were 
+        <li><strong>Minor</strong> number MUST increment if, <em>and only
+        if</em>, new responses are added, without invalidating existing
+        responses. It’s understood that an evaluator of an existing
+        evaluation may desire to choose the new response if they were
         evaluating the criteria anew; however, as long as prior evaluations
         remain valid, a Minor increment SHOULD be applied.
         </li>
-        <li><strong>Patch</strong> number MUST increment if, <em>and only 
+        <li><strong>Patch</strong> number MUST increment if, <em>and only
         if</em>, the change to the question is “editorial”, defined by
-        clarifying the original intent of the criteria WITHOUT 
+        clarifying the original intent of the criteria WITHOUT
         invalidating existing evaluations.
         </li>
       </ol>
       </li>
       <li>
-      As long as a given criteria is an evolution of essentially the same 
+      As long as a given criteria is an evolution of essentially the same
       consideration, it retains the original identifier,
       even as its version is updated throughout its lifetime.
       </li>
@@ -1203,26 +1212,26 @@ <h3>Metadata Tables</h3>
       <section>
         <h3>Evaluations Cited</h3>
         <p>Every example evaluation cited in the Notes entry in an evaluation MUST link to a proper citation in this section.</p>
-        <p>This is not a comprehensive listing of DID Method Rubric evaluations. It is expected that such evaluations are developed and published elsewhere, in support of various methods and use cases. Only those evaluations cited as Example Evaluations in current criteria will be listed.</p> 
+        <p>This is not a comprehensive listing of DID Method Rubric evaluations. It is expected that such evaluations are developed and published elsewhere, in support of various methods and use cases. Only those evaluations cited as Example Evaluations in current criteria will be listed.</p>
         <p>Entries in this section MUST include:</p>
         <ol>
-        <li><strong>Evaluators</strong> The name and contact 
-        information for the parties accepting responsibility for that 
-        evaluation. It MAY include each evaluator’s affiliation at the 
+        <li><strong>Evaluators</strong> The name and contact
+        information for the parties accepting responsibility for that
+        evaluation. It MAY include each evaluator’s affiliation at the
         time of the evaluation.
         </li>
-        <li><strong>Evaluation Date</strong> The performance date of 
+        <li><strong>Evaluation Date</strong> The performance date of
         the evaluation.
         </li>
-        <li><strong>Funding</strong> The source, if any, of funds 
+        <li><strong>Funding</strong> The source, if any, of funds
         explicitly paid to perform the evaluation.
         </li>
-        <li><strong>Use Cases</strong> One or more use cases listed 
-        Use Cases Referenced section of this registry, using the label 
+        <li><strong>Use Cases</strong> One or more use cases listed
+        Use Cases Referenced section of this registry, using the label
         from that section.
         <ol type="a">
         <li>The use case label MUST be delimited by square brackets.</ li>
-        <li>The label text itself must be a hyperlink to the entry in 
+        <li>The label text itself must be a hyperlink to the entry in
         the Use Cases Referenced section, for example [UC.1] where
         “UC.1” links to “#useCase-1” in the current document.
         </li>
@@ -1237,19 +1246,19 @@ <h3>Use Cases Referenced</h3>
         <p>Every use case cited in the Notes entry in an evaluation MUST link to an entry in this section.</p>
         <p>A collection of the use cases referenced by different evaluations. This is not a comprehensive list (see the DID Use Cases and Requirements document for a more detailed discussion). Rather, it is an aggregation of all the use cases cited by example evaluations in current criteria.</p>
         <ol>
-        <li>This section MUST list all use cases cited by any example 
+        <li>This section MUST list all use cases cited by any example
         evaluation for current criteria.
         </li>
-        <li>Use cases must specify a label for use by citations within 
+        <li>Use cases must specify a label for use by citations within
         the registry.
         </li>
-        <li>The label must be of the form UC.x where “x” is a unique, 
+        <li>The label must be of the form UC.x where “x” is a unique,
         incremental number within the Use Cases Referenced section.
         </li>
-        <li>Each use case must have an unique name and an illustrative 
+        <li>Each use case must have an unique name and an illustrative
         description of a value-creating use of DIDs.
         </li>
-        <li>Use cases SHOULD identify unique contexts or situations 
+        <li>Use cases SHOULD identify unique contexts or situations
         not covered by other use cases in the registry.
         </li>
         </ol>
@@ -1264,29 +1273,29 @@ <h3>Methods Evaluated</h3>
         <ol>
         <li>A label for the DID method within the registry
         </li>
-        <li>An anchor tag so that the entry in the table can be linked by 
+        <li>An anchor tag so that the entry in the table can be linked by
         fragment from example evaluations.
         </li>
         <li>
-        Columns for the Specification, the Network, and the Registry (SNR) 
+        Columns for the Specification, the Network, and the Registry (SNR)
         evaluated with this label.
         </li>
         <li>
-        In the case that all three SNR entries would be identical for 
-        different rows in the same table, subsequent entries MAY refer to 
-        the prior entry by Method (with link), along with a description of 
+        In the case that all three SNR entries would be identical for
+        different rows in the same table, subsequent entries MAY refer to
+        the prior entry by Method (with link), along with a description of
         the difference, in a single column spanning all three SNR columns.
         </li>
         <li>Each SNR entry should uniquely describe the component evaluated.
           <ol type="a">
-            <li><strong>Specification</strong> identifies the DID Method 
-            specification under evaluation, with a hyperlink to the 
+            <li><strong>Specification</strong> identifies the DID Method
+            specification under evaluation, with a hyperlink to the
             specification (at the time of the evaluation).</li>
-            <li><strong>Network</strong> identifies the communications 
+            <li><strong>Network</strong> identifies the communications
             mechanism through which DID operations (create, read, update,
             and deactivate) are communicated.</li>
-            <li><strong>Registry</strong> should unambiguously identify the 
-            state management substrate of the method’s Verifiable Data 
+            <li><strong>Registry</strong> should unambiguously identify the
+            state management substrate of the method’s Verifiable Data
             Registry.</li>
           </ol>
         </li>
@@ -1297,3398 +1306,32 @@ <h3>Methods Evaluated</h3>
     </section><!-- Metadata Tables -->
 <section>
 <h3>Editorial Acceptance & Publication</h3>
-<p>The Editors of the DID Method Rubric Registry MUST consider all of the 
-policies above when reviewing additions to the registry and MUST reject 
-registry entries if they violate any of the policies in this section. 
-Entities registering additions can challenge rejections first with the W3C 
-DID Working Group and then, if they are not satisfied with the outcome, 
-with the W3C Staff. W3C Staff need not be consulted on changes to the DID 
-Method Rubric Registry, but do have the final authority on registry 
-contents. This is to ensure that W3C can adequately respond to time 
-sensitive legal, privacy, security, moral, or other pressing concerns 
+<p>The Editors of the DID Method Rubric Registry MUST consider all of the
+policies above when reviewing additions to the registry and MUST reject
+registry entries if they violate any of the policies in this section.
+Entities registering additions can challenge rejections first with the W3C
+DID Working Group and then, if they are not satisfied with the outcome,
+with the W3C Staff. W3C Staff need not be consulted on changes to the DID
+Method Rubric Registry, but do have the final authority on registry
+contents. This is to ensure that W3C can adequately respond to time
+sensitive legal, privacy, security, moral, or other pressing concerns
 without putting an undue operational burden on W3C Staff.
 </p>
-<p>Submissions to the registry that meet all the criteria listed above 
-will be considered for inclusion, however the editors retain the 
-responsibility of curating the content to ensure the broadest 
+<p>Submissions to the registry that meet all the criteria listed above
+will be considered for inclusion, however the editors retain the
+responsibility of curating the content to ensure the broadest
 applicability of the DID Method Rubric with the goal of enabling effective
 evaluations of any DID Method for any legitimate use case.
 </p>
 </section>
   </section> <!-- Registration Process -->
-  <section>
-    <h2>The criteria</h2>
-    <section>
-      <h3>Rulemaking</h3>
-      <p>
-        Rulemaking addresses who makes the rules and how. Output of rulemaking are the
-        rules.
-      </p>
-      <section>
-        <h4 id="criteria-1">Open contribution (participation)</h4>
-        <a href="#criteria-1">https://www.w3.org/TR/did-rubric#criteria-1</a> <span>v1.0.0</span>
-        <section>
-          <h5>Question</h5>
-          <p>
-            How open is participation in governance decisions?
-          </p>
-        </section>
-        <section>
-          <h5>Responses</h5>
-          <ol type="A">
-            <li>
-              Anyone can participate in an open, fair process where all participants have
-              equal opportunity to be heard and influence decisions.
-            </li>
-            <li>
-              Anyone can comment and contribute to open debate, but decisions are ultimately
-              made by a closed group.
-            </li>
-            <li>
-              Debate is restricted to a selected but known group.
-            </li>
-            <li>
-              Debate is conducted in secret by an unknown group.
-            </li>
-          </ol>
-        </section>
-        <section>
-          <h5>Relevance</h5>
-          <p>
-            Governance determines how the rules of the underlying network are set and
-            maintained. The more parties that are able to contribute to governance debates,
-            the more decentralized the governance.
-          </p>
-        </section>
-        <section>
-          <h5>Examples</h5>
-          <table class="simple">
-            <tr>
-              <th>
-                Method
-              </th>
-              <th>
-                Spec.
-              </th>
-              <th>
-                Net.
-              </th>
-              <th>
-                Reg.
-              </th>
-              <th>
-                Notes
-              </th>
-            </tr>
-            <tr>
-              <td>
-                did:peer
-              </td>
-              <td>
-                B
-              </td>
-              <td>
-                C
-              </td>
-              <td>
-                C
-              </td>
-              <td>
-                did:peer has no intrinsic network. It can use any communications channel
-                between parties. Only those two parties are privy to the decisions made about
-                communications and recordation. The spec is openly developed on github by a
-                listed set of contributors and issues may be raised by anyone. [<a href="#eval-1">eval-1</a>]
-              </td>
-            </tr>
-            <tr>
-              <td>
-                did:git
-              </td>
-              <td>
-                B
-              </td>
-              <td>
-                C
-              </td>
-              <td>
-                D
-              </td>
-              <td>
-                The git network is the git source code, which is controlled (currently) by 16
-                people. They do not have a public issues process. The spec is openly developed
-                on github by a listed set of contributors and issues may be raised by anyone.
-                Each registry is controlled by potentially unknown parties as negotiated in
-                "meatspace". [<a href="#eval-1">eval-1</a>]
-              </td>
-            </tr>
-            <tr>
-              <td>
-                did:btcr
-              </td>
-              <td>
-                B
-              </td>
-              <td>
-                D
-              </td>
-              <td>
-                D
-              </td>
-              <td>
-                Changes to the bitcoin protocol are chaotic and uncertain. They use BIPs, but
-                the path to adoption is uncertain and the relative power of developers, miners,
-                and users is open to debate. The spec is openly developed on github by a
-                listed set of contributors and issues may be raised by anyone. [<a href="#eval-1">eval-1</a>]
-              </td>
-            </tr>
-            <tr>
-              <td>
-                did:sov
-              </td>
-              <td>
-                B
-              </td>
-              <td>
-                B
-              </td>
-              <td>
-                B
-              </td>
-              <td>
-                The Sovrin Foundation has an open community governance model but has not yet
-                had open elections of trustees. [<a href="#eval-1">eval-1</a>]
-              </td>
-            </tr>
-            <tr>
-              <td>
-                did:ethr
-              </td>
-              <td>
-                C
-              </td>
-              <td>
-                B
-              </td>
-              <td>
-                n/a
-              </td>
-              <td>
-                The network is Ethereum, which evolves through EIPs proposed by anyone,
-                discussed by "the community" and ultimately adopted by Ethereum core devs. The
-                spec is published on GitHub with issues open to the public. The smart contract
-                for the registry is immutable. [<a href="#eval-1">eval-1</a>]
-              </td>
-            </tr>
-            <tr>
-              <td>
-                did:jolo
-              </td>
-              <td>
-                D
-              </td>
-              <td>
-                B
-              </td>
-              <td>
-                D
-              </td>
-              <td>
-                Jolocom's network is Ethereum. Decisions over Jolocom's smart contracts are
-                made by an unknown group within Jolocom. The specification (as listed in the
-                DID Method Registry [[DID-SPEC-REGISTRIES]]) is currently archived and not
-                open to public comment. [<a href="#eval-1">eval-1</a>]
-              </td>
-            </tr>
-          </table>
-        </section>
-      </section> <!-- participation -->
-
-      <section>
-        <h4 id="criteria-2">Transparency</h4>
-        <a href="#criteria-2">https://www.w3.org/TR/did-rubric#criteria-2</a>
-
-        <p>
-        </p>
-        <section>
-          <h5>Question</h5>
-          <p>
-            How visible are rulemaking processes?
-          </p>
-        </section>
-        <section>
-          <h5>Responses</h5>
-          <ol type="A">
-            <li>
-              Agendas and participation details for all meetings are publicly announced, the
-              meetings are broadcast in real-time to any listeners, and all minutes and
-              recordings are captured in realtime and publicly reviewable in perpetuity.
-            </li>
-            <li>
-              Minutes of meetings are reviewable by the public, including all votes and who
-              cast them, but real-time observation may be limited.
-            </li>
-            <li>
-              All current rules are publicly available.
-            </li>
-            <li>
-              Rules may be changed without public notice.
-            </li>
-          </ol>
-        </section>
-        <section>
-          <h5>Relevance</h5>
-          <p>
-            While participation measures active contribution, transparency measures the
-            visibility of discussions affecting rule making. If such discussions are only
-            visible to a limited group, it centralizes decision making in ways that
-            <a>Evaluators</a> and users cannot easily see.
-          </p>
-        </section>
-        <section>
-          <h5>Examples</h5>
-          <table class="simple">
-            <tr>
-              <th>
-                Method
-              </th>
-              <th>
-                Spec.
-              </th>
-              <th>
-                Net.
-              </th>
-              <th>
-                Reg.
-              </th>
-              <th>
-                Notes
-              </th>
-            </tr>
-            <tr>
-              <td>
-                did:peer
-              </td>
-              <td>
-                C
-              </td>
-              <td>
-                n/a
-              </td>
-              <td>
-                B
-              </td>
-              <td>
-                Rules for accepting changes to the business rules are bilaterally negotiated
-                between the peers, subject to conformance with the specification. [<a href="#eval-1">eval-1</a>]
-              </td>
-            </tr>
-            <tr>
-              <td>
-                did:git
-              </td>
-              <td>
-                C
-              </td>
-              <td>
-                n/a
-              </td>
-              <td>
-                D
-              </td>
-              <td>
-                The controllers of the git repo are a limited set, but their decisions are
-                "meatspace protocol" and hence not explicitly transparent. [<a href="#eval-1">eval-1</a>]
-              </td>
-            </tr>
-            <tr>
-              <td>
-                did:btcr
-              </td>
-              <td>
-                C
-              </td>
-              <td>
-                C
-              </td>
-              <td>
-                C
-              </td>
-              <td>
-                The spec is maintained by volunteers, operating in an open fashion but without
-                formal processes for announcements and meeting notes. The network and registry
-                are bitcoin, which has a fairly public but messy innovation process, without
-                formal meetings or votes. [<a href="#eval-1">eval-1</a>]
-              </td>
-            </tr>
-            <tr>
-              <td>
-                did:sov
-              </td>
-              <td>
-                B
-              </td>
-              <td>
-                B
-              </td>
-              <td>
-                B
-              </td>
-              <td>
-                The Sovrin Governance Framework actually requires all minutes of Sovrin
-                governance discussions are public with a handful of exceptions for legal
-                reasons (e.g., HR actions, legal actions). See Section 9 of
-                <a href="https://sovrin.org/wp-content/uploads/Sovrin-Governing-Body-Policies-V1.pdf">
-                  Sovrin Governing Body Policies</a>. [<a href="#eval-1">eval-1</a>]
-              </td>
-            </tr>
-            <tr>
-              <td>
-                did:ethr
-              </td>
-              <td>
-                C
-              </td>
-              <td>
-                C
-              </td>
-              <td>
-                D
-              </td>
-              <td>
-                The governance is controlled by a smart contract, which is immutable.
-                [<a href="#eval-1">eval-1</a>]
-              </td>
-            </tr>
-            <tr>
-              <td>
-                did:jolo
-              </td>
-              <td>
-                C
-              </td>
-              <td>
-                C
-              </td>
-              <td>
-                D
-              </td>
-              <td>
-                Jolocom does not expose the internal and/or customer conversations that drive
-                rulemaking. [<a href="#eval-1">eval-1</a>]
-              </td>
-            </tr>
-          </table>
-        </section>
-      </section> <!-- transparency -->
-
-      <section>
-        <h4 id="criteria-3">Breadth of Authority</h4>
-        <a href="#criteria-3">https://www.w3.org/TR/did-rubric#criteria-3</a>
-        <section>
-          <h5>Question</h5>
-          <p>
-            How many independent parties actively participate in the governance authority?
-          </p>
-        </section>
-        <section>
-          <h5>Responses</h5>
-          <ol type="A">
-            <li>
-              Rules are decided by an open set of multiple parties.
-            </li>
-            <li>
-              Rules are decided by a closed set of multiple parties.
-            </li>
-            <li>
-              Rules are decided by a single known entity.
-            </li>
-            <li>
-              Rules are decided by an unknown party.
-            </li>
-          </ol>
-        </section>
-        <section>
-          <h5>Relevance</h5>
-          <p>
-            Is the governing authority for the DID Method innately centralized? Is the
-            Method governed by a single entity, who could make arbitrary changes to the
-            governance? Or is it governed by a closed set of parties, without fully open
-            access? Or is there a legitimate effort to open the decision making process
-            to multiple, competing and cooperating parties?
-          </p>
-        </section>
-        <section>
-          <h5>Examples</h5>
-          <table class="simple">
-            <tr>
-              <th>
-                Method
-              </th>
-              <th>
-                Spec.
-              </th>
-              <th>
-                Net.
-              </th>
-              <th>
-                Reg.
-              </th>
-              <th>
-                Notes
-              </th>
-            </tr>
-            <tr>
-              <td>
-                did:peer
-              </td>
-              <td>
-                B
-              </td>
-              <td>
-                B
-              </td>
-              <td>
-                B
-              </td>
-              <td>
-                There is only one editor to the did:peer specification, but the repository
-                itself lists 14 contributors with actual commits. The network and registry
-                rules are ultimately decided by the parties participating in each did:peer
-                context (a closed set of peers).
-                [<a href="#eval-1">eval-1</a>]
-              </td>
-            </tr>
-            <tr>
-              <td>
-                did:git
-              </td>
-              <td>
-                B
-              </td>
-              <td>
-                B
-              </td>
-              <td>
-                D
-              </td>
-              <td>
-                There is only one editor to the did:git specification, with a total of three
-                contributors with actual commits (although more are listed). The network is
-                git (controlled by an unknown population) and the registry is a particular
-                repo under the control of potentially unknown parties.
-                [<a href="#eval-1">eval-1</a>]
-              </td>
-            </tr>
-            <tr>
-              <td>
-                did:btcr
-              </td>
-              <td>
-                B
-              </td>
-              <td>
-                A
-              </td>
-              <td>
-                A
-              </td>
-              <td>
-                The spec lists 4 editors and the repo lists 4 committers. The network and
-                registry is bitcoin, which relies on an informal process of any number of
-                parties.
-                [<a href="#eval-1">eval-1</a>]
-              </td>
-            </tr>
-            <tr>
-              <td>
-                did:sov
-              </td>
-              <td>
-                C+
-              </td>
-              <td>
-                C+
-              </td>
-              <td>
-                C+
-              </td>
-              <td>
-                All three layers are ultimately under the control of the Sovrin Foundation,
-                which itself has a governance framework to coordinate input from multiple
-                parties.
-                [<a href="#eval-1">eval-1</a>]
-              </td>
-            </tr>
-            <tr>
-              <td>
-                did:ethr
-              </td>
-              <td>
-                B
-              </td>
-              <td>
-                B
-              </td>
-              <td>
-                n/a
-              </td>
-              <td>
-                The specification is now under DIF control and the registry is immutable. The
-                network is Ethereum, which is controlled by Ethereum core devs.
-                [<a href="#eval-1">eval-1</a>]
-              </td>
-            </tr>
-            <tr>
-              <td>
-                did:jolo
-              </td>
-              <td>
-                C
-              </td>
-              <td>
-                B
-              </td>
-              <td>
-                C+
-              </td>
-              <td>
-                The specification and registry are controlled by Jolocom, sometimes in
-                coordination with customers. The network is Ethereum, which is controlled by
-                Ethereum core devs.
-                [<a href="#eval-1">eval-1</a>]
-              </td>
-            </tr>
-          </table>
-        </section>
-      </section> <!-- breadth -->
-
-      <section>
-        <h4 id="criteria-4">Public v private economies</h4>
-        <a href="#criteria-4">https://www.w3.org/TR/did-rubric#criteria-4</a>
-        <section>
-          <h5>Question</h5>
-          <p>
-            How privatized is the economic interest of the governing authority?
-          </p>
-        </section>
-        <section>
-          <h5>Responses</h5>
-          <ol type="A">
-            <li>
-              The governing authority is established for the public good without rents or
-              remuneration.
-            </li>
-            <li>
-              The governing authority is established for the common good of a limited set of
-              parties.
-            </li>
-            <li>
-              The governing authority is established to enhance profits for a limited set of
-              parties.
-            </li>
-            <li>
-              The governing authority is established to extract rents.
-            </li>
-          </ol>
-        </section>
-        <section>
-          <h5>Relevance</h5>
-          <p>
-            The underlying financial goals of DID Method creators may affect the
-            centralization of their Method. If the goal of a Method is to enhance or
-            support a certain group, then there may be centralization focused on that
-            group and their interests. In the most centralized extreme, a Method may be
-            created explicitly to establish a monopoly market that it can extract rent
-            from. The opposite extreme is a Method created explicitly for the public good.
-          </p>
-        </section>
-        <section>
-          <h5>Examples</h5>
-          <table class="simple">
-            <tr>
-              <th>
-                Method
-              </th>
-              <th>
-                Spec.
-              </th>
-              <th>
-                Net.
-              </th>
-              <th>
-                Reg.
-              </th>
-              <th>
-                Notes
-              </th>
-            </tr>
-            <tr>
-              <td>
-                did:peer
-              </td>
-              <td>
-                A
-              </td>
-              <td>
-                B
-              </td>
-              <td>
-                B
-              </td>
-              <td>
-                The specification was developed to demonstrate a way that anyone can use DIDs
-                without a distributed ledger. Each network and registry is established solely
-                for the benefit of each peer.
-                [<a href="#eval-1">eval-1</a>]
-              </td>
-            </tr>
-            <tr>
-              <td>
-                did:git
-              </td>
-              <td>
-                A
-              </td>
-              <td>
-                A
-              </td>
-              <td>
-                B
-              </td>
-              <td>
-                The specification was developed to demonstrate how you might use DIDs to
-                enhance git-based software development. Git itself (the network) was developed
-                so anyone could have better software development practices. Any given registry
-                (each repo is a registry) is assumed to be established for the common good of
-                its controllers.
-                [<a href="#eval-1">eval-1</a>]
-              </td>
-            </tr>
-            <tr>
-              <td>
-                did:btcr
-              </td>
-              <td>
-                A
-              </td>
-              <td>
-                A
-              </td>
-              <td>
-                A
-              </td>
-              <td>
-                The specification was developed to demonstrate how you could use Bitcoin for
-                DIDs. The network and registry were created as a public benefit proof of
-                concept for decentralized digital cash.
-                [<a href="#eval-1">eval-1</a>]
-              </td>
-            </tr>
-            <tr>
-              <td>
-                did:sov
-              </td>
-              <td>
-                B
-              </td>
-              <td>
-                B
-              </td>
-              <td>
-                B
-              </td>
-              <td>
-                All three elements are developed and maintained for the common good. As a
-                501(c)4 the Sovrin foundation is a social welfare organization that must
-                operate primarily to further the common good and general welfare of the people
-                of its community.
-                [<a href="#eval-1">eval-1</a>]
-              </td>
-            </tr>
-            <tr>
-              <td>
-                did:ethr
-              </td>
-              <td>
-                C
-              </td>
-              <td>
-                C
-              </td>
-              <td>
-                C
-              </td>
-              <td>
-                The specification and registry were created by a private company (uPort) to
-                support their business. The smart contract is a common good and free to use.
-                However, the network, Ethereum, was created to create wealth for its creators.
-                [<a href="#eval-1">eval-1</a>]
-              </td>
-            </tr>
-            <tr>
-              <td>
-                did:jolo
-              </td>
-              <td>
-                C
-              </td>
-              <td>
-                C
-              </td>
-              <td>
-                C
-              </td>
-              <td>
-                The specification and registry were created by a private company (Jolocom) to
-                support their business, but are now available for anyone to use. Similarly,
-                the network, Ethereum, was created to create wealth for its creators.
-                [<a href="#eval-1">eval-1</a>]
-              </td>
-            </tr>
-          </table>
-        </section>
-      </section> <!-- public v private -->
-      <section>
-        <h4 id="criteria-5">Cost</h4>
-        <a href="#criteria-5">https://www.w3.org/TR/did-rubric#criteria-5</a>
-        <section>
-          <h5>Question</h5>
-          <p>
-            How expensive is it to participate in governance (in time, money, or effort)?
-          </p>
-        </section>
-        <section>
-          <h5>Responses</h5>
-          <ol type="A">
-            <li>
-              Free to all
-            </li>
-            <li>
-              Inexpensive, but accessible
-            </li>
-            <li>
-              Modest cost for interested parties
-            </li>
-            <li>
-              Expensive and restricted
-            </li>
-            <li>
-              Not possible to participate
-            </li>
-          </ol>
-        </section>
-        <section>
-          <h5>Relevance</h5>
-          <p>
-            Governance takes resources, which can limit the ability of interested parties
-            to influence rulemaking. Generally, the more expensive it is to participate,
-            the more governance centralizes to those parties most able to make the
-            investment.
-          </p>
-        </section>
-        <section>
-          <h5>Examples</h5>
-          <table class="simple">
-            <tr>
-              <th>
-                Method
-              </th>
-              <th>
-                Spec.
-              </th>
-              <th>
-                Net.
-              </th>
-              <th>
-                Reg.
-              </th>
-              <th>
-                Notes
-              </th>
-            </tr>
-            <tr>
-              <td>
-                did:peer
-              </td>
-              <td>
-                B
-              </td>
-              <td>
-                n/a
-              </td>
-              <td>
-                n/a
-              </td>
-              <td>
-                The specification is available for engagement via Github, but participating in
-                decision making takes time and requires expertise. The network and registry
-                are negotiated on a case-by-case basis, so participation could be anywhere on
-                the spectrum.
-                [<a href="#eval-1">eval-1</a>]
-              </td>
-            </tr>
-            <tr>
-              <td>
-                did:git
-              </td>
-              <td>
-                B
-              </td>
-              <td>
-                D+
-              </td>
-              <td>
-                D
-              </td>
-              <td>
-                The specification is available for engagement via Github, but participating in
-                decision making takes time and requires expertise. Git itself (the network) is
-                partially influenceable through online issues, but real change requires deep
-                expertise and is controlled by a handful of developers. Any given registry's
-                governance is, by design, a question of "meatspace" negotiations, which is
-                expensive and limited to the parties who control the repo.
-                [<a href="#eval-1">eval-1</a>]
-              </td>
-            </tr>
-            <tr>
-              <td>
-                did:btcr
-              </td>
-              <td>
-                B
-              </td>
-              <td>
-                D
-              </td>
-              <td>
-                D
-              </td>
-              <td>
-                The specification is available for engagement via Github, but participating in
-                decision making takes time and requires expertise. The network and registry
-                (bitcoin) are theoretically open to any participants, but influencing the
-                direction of bitcoin is notoriously expensive and unpredictable.
-                [<a href="#eval-1">eval-1</a>]
-              </td>
-            </tr>
-            <tr>
-              <td>
-                did:sov
-              </td>
-              <td>
-                B
-              </td>
-              <td>
-                B
-              </td>
-              <td>
-                B
-              </td>
-              <td>
-                The did:sov method together with 100% of the Sovrin ledger and Sovrin
-                infrastructure are governed by an open public non-profit organization that is
-                open to anyone to participate. The Sovrin Governance Framework Working Group
-                is an all-volunteer community-driven effort in which over 50 volunteers have
-                participated for over three years to develop a
-                <a href="https://sovrin.org/library/sovrin-governance-framework/">fully public governance
-                  framework</a> on which anyone can comment and suggest improvements. The Sovrin
-                ledger operates on the Hyperledger Indy open source code base to which anyone
-                can contribute.
-                [<a href="#eval-1">eval-1</a>]
-              </td>
-            </tr>
-            <tr>
-              <td>
-                did:ethr
-              </td>
-              <td>
-                C
-              </td>
-              <td>
-                D
-              </td>
-              <td>
-                E
-              </td>
-              <td>
-                The specification is available for engagement via Github, and managed by DIF.
-                The network itself, Ethereum, is expensive and difficult to influence: not
-                impossible for an outsider, but expensive. Governance of the registry is not
-                accessible except with uPort's permission.
-                [<a href="#eval-1">eval-1</a>]
-              </td>
-            </tr>
-            <tr>
-              <td>
-                did:jolo
-              </td>
-              <td>
-                D
-              </td>
-              <td>
-                D
-              </td>
-              <td>
-                E
-              </td>
-              <td>
-                While the did:jolo specification is available online, it is archived and not
-                open to further engagement. Jolocom has sole control over who can participate
-                in developing specifications based on did:jolo, and they work with customers
-                to customize the Method. The network itself, Ethereum, is expensive and
-                difficult to influence: not impossible for an outsider, but expensive. The
-                registry is immutable and therefore not open to participation.
-                [<a href="#eval-1">eval-1</a>]
-              </td>
-            </tr>
-          </table>
-        </section>
-      </section><!-- cost -->
-
-    </section> <!-- rulemaking -->
-    <section>
-      <h3>Design</h3>
-      <p>
-        Design criteria addresses the method as designed. In other words, the output of the rulemaking: what rules apply
-        to this DID method?
-      </p>
-      <section>
-        <h4 id="criteria-6">Permissioned operation</h4>
-        <a href="#criteria-6">https://www.w3.org/TR/did-rubric#criteria-6</a>
-        <section>
-          <h5>Question</h5>
-          <p>
-            To use the DID Method, do you need permission?
-          </p>
-        </section>
-        <section>
-          <h5>Responses</h5>
-          <ol type="A">
-            <li>
-              Anyone can participate fully (full read/write and participation in consensus).
-            </li>
-            <li>
-              Anyone can read/write, but consensus mechanism is permissioned.
-            </li>
-            <li>
-              Anyone can read, but writing and consensus is permissioned.
-            </li>
-            <li>
-              All participation is permissioned.
-            </li>
-          </ol>
-        </section>
-        <section>
-          <h5>Relevance</h5>
-          <p>
-            Permissioned operation impacts the availability of the network to various
-            participants, which can affect inclusivity with regard to underserved or
-            vulnerable populations. Permissioned networks also expose the permission giver
-            to legal or other attacks.
-          </p>
-        </section>
-        <section>
-          <h5>Examples</h5>
-          <table class="simple">
-            <tr>
-              <th>
-                Method
-              </th>
-              <th>
-                Net.
-              </th>
-              <th>
-                Reg.
-              </th>
-              <th>
-                Notes
-              </th>
-            </tr>
-            <tr>
-              <td>
-                did:peer
-              </td>
-              <td>
-                A
-              </td>
-              <td>
-                D
-              </td>
-              <td>
-                By design, did:peer can use any communications channel and only the
-                participation of the participants is required. Unfortunately, for those
-                outside the peer context, the registry is inaccessible.
-                [<a href="#eval-1">eval-1</a>]
-              </td>
-            </tr>
-            <tr>
-              <td>
-                did:git
-              </td>
-              <td>
-                A
-              </td>
-              <td>
-                D
-              </td>
-              <td>
-                Git software is available to anyone. Participation and access is controlled by
-                the repo maintainers.
-                [<a href="#eval-1">eval-1</a>]
-              </td>
-            </tr>
-            <tr>
-              <td>
-                did:btcr
-              </td>
-              <td>
-                A
-              </td>
-              <td>
-                A
-              </td>
-              <td>
-                The bitcoin network is open to anyone.
-                [<a href="#eval-1">eval-1</a>]
-              </td>
-            </tr>
-            <tr>
-              <td>
-                did:sov
-              </td>
-              <td>
-                C
-              </td>
-              <td>
-                C
-              </td>
-              <td>
-                Sovrin foundation limits access to writing and consensus, but the network is
-                open to all for reading.
-                [<a href="#eval-1">eval-1</a>]
-              </td>
-            </tr>
-            <tr>
-              <td>
-                did:ethr
-              </td>
-              <td>
-                A
-              </td>
-              <td>
-                A
-              </td>
-              <td>
-                Ethereum is open to anyone. The registry is accessible to anyone.
-                [<a href="#eval-1">eval-1</a>]
-              </td>
-            </tr>
-            <tr>
-              <td>
-                did:jolo
-              </td>
-              <td>
-                A
-              </td>
-              <td>
-                A
-              </td>
-              <td>
-                Ethereum is open to anyone. The registry is accessible to anyone, although
-                some subregistries/subnetworks may have alternate rules.
-                [<a href="#eval-1">eval-1</a>]
-              </td>
-            </tr>
-          </table>
-        </section>
-      </section> <!-- permissioned operation -->
-      <section>
-        <h4 id="criteria-7">Interoperability</h4>
-        <a href="#criteria-7">https://www.w3.org/TR/did-rubric#criteria-7</a>
-        <section>
-          <h5>Question</h5>
-          <p>
-            Does the DID Method restrict access or functionality to particular wallet
-            implementations per the specification? (Whether or not any given wallet works
-            with the resolver or registry is covered elsewhere.)
-          </p>
-        </section>
-        <section>
-          <h5>Responses</h5>
-          <ol type="A">
-            <li>
-              Any wallet can work with any resolver on any registry,
-            </li>
-            <li>
-              Any wallet can work with multiple resolvers and multiple registries,
-            </li>
-            <li>
-              Some implementations of some wallets can work with some resolvers,
-            </li>
-            <li>
-              There is a single combined suite of resolver, registry, and wallet.
-            </li>
-          </ol>
-        </section>
-        <section>
-          <h5>Relevance</h5>
-          <p>
-            The ability to communicate with different (ideally all) resolvers and
-            registries significantly increases the applicability of a decentralized
-            identity layer / usability of a given wallet. Vice versa, limited capability
-            to work with other Methods and registries restrict usage.
-          </p>
-        </section>
-        <section>
-          <h5>Examples</h5>
-          <table class="simple">
-            <tr>
-              <th>
-                Method
-              </th>
-              <th>
-                Net.
-              </th>
-              <th>
-                Reg.
-              </th>
-              <th>
-                Notes
-              </th>
-            </tr>
-            <tr>
-              <td>
-                did:peer
-              </td>
-              <td>
-                A
-              </td>
-              <td>
-                A
-              </td>
-              <td>
-                did:peer is agnostic regarding the software that implements it.
-                [<a href="#eval-1">eval-1</a>]
-              </td>
-            </tr>
-            <tr>
-              <td>
-                did:git
-              </td>
-              <td>
-                A-
-              </td>
-              <td>
-                A-
-              </td>
-              <td>
-                did:git is predicated on using git software. However, git itself uses a
-                protocol that any software could implement. Although we know of no other
-                implementation in widespread use, we know of no limitations in the protocol
-                itself.
-                [<a href="#eval-1">eval-1</a>]
-              </td>
-            </tr>
-            <tr>
-              <td>
-                did:btcr
-              </td>
-              <td>
-                A
-              </td>
-              <td>
-                A
-              </td>
-              <td>
-                Bitcoin has no restrictions on the software used to access the network.
-                [<a href="#eval-1">eval-1</a>]
-              </td>
-            </tr>
-            <tr>
-              <td>
-                did:sov
-              </td>
-              <td>
-                A
-              </td>
-              <td>
-                A
-              </td>
-              <td>
-                did:sov: has no restrictions on any software that implements it.
-                [<a href="#eval-1">eval-1</a>]
-              </td>
-            </tr>
-            <tr>
-              <td>
-                did:ethr
-              </td>
-              <td>
-                A
-              </td>
-              <td>
-                A
-              </td>
-              <td>
-                Neither Ethereum nor the smart contract has any restrictions on the software
-                used to access them.
-                [<a href="#eval-1">eval-1</a>]
-              </td>
-            </tr>
-            <tr>
-              <td>
-                did:jolo
-              </td>
-              <td>
-                A
-              </td>
-              <td>
-                A
-              </td>
-              <td>
-                Neither Ethereum nor the smart contract has any restrictions on the software
-                used to access them.
-                [<a href="#eval-1">eval-1</a>]
-              </td>
-            </tr>
-          </table>
-        </section>
-      </section> <!-- interop -->
-      <section>
-        <h4 id="criteria-8">Scope of usage</h4>
-        <a href="#criteria-8">https://www.w3.org/TR/did-rubric#criteria-8</a>
-        <section>
-          <h5>Question</h5>
-          <p>
-            How widely can DIDs of this Method be used?
-          </p>
-        </section>
-        <section>
-          <h5>Responses</h5>
-          <ol type="A">
-            <li>
-              Universal: DIDs can only be created and used universally, between any number
-              of parties.
-            </li>
-            <li>
-              Contextual: DIDs can be created and used contextually, between any set of
-              collaborating parties.
-            </li>
-            <li>
-              Paired: DID can be created and used pairwise, between any two parties.
-            </li>
-            <li>
-              Central: DIDs can only be created and used with a single, centralized party.
-            </li>
-          </ol>
-        </section>
-        <section>
-          <h5>Relevance</h5>
-          <p>
-            Different Methods enable different scopes in which a DID might be considered
-            usable or valid. For example, peer DIDs are only usable between the two peers
-            who share unique DIDs with each other; other parties are unable to resolve the
-            DID, find the DID Document, or use its information to establish secure
-            interactions. In contrast, BTCR records all DIDs on a public ledger, meaning
-            that all DIDs are fundamentally accessible to any party who might receive the
-            DID. Contextual DIDs are a middle ground that allow a set of parties to use
-            DIDs, while those outside that group cannot meaningfully do so. Finally,
-            central DIDs use the DID syntax and DID Documents to establish secure
-            communications, but authority to use these DIDs resides with the central party,
-            who may revoke that ability at their discretion.
-          </p>
-        </section>
-        <section>
-          <h5>Examples</h5>
-          <table class="simple">
-            <tr>
-              <th>
-                Method
-              </th>
-              <th>
-                Net.
-              </th>
-              <th>
-                Reg.
-              </th>
-              <th>
-                Notes
-              </th>
-            </tr>
-            <tr>
-              <td>
-                did:peer
-              </td>
-              <td>
-                A+
-              </td>
-              <td>
-                C
-              </td>
-              <td>
-                Did:peer is communication-layer independent, so it can be used on any network,
-                including direct physical links. However, only those parties to the creation
-                of the DID can actually use it. The DIDs have no use outside that direct
-                peer-to-peer relationship.
-                [<a href="#eval-1">eval-1</a>]
-              </td>
-            </tr>
-            <tr>
-              <td>
-                did:git
-              </td>
-              <td>
-                A
-              </td>
-              <td>
-                B
-              </td>
-              <td>
-                Anyone can set up a git-based repo and use did:git. However, to interact with
-                a given repo, one must be aware of the repo, including which instance of it is
-                authoritative.
-                [<a href="#eval-1">eval-1</a>]
-              </td>
-            </tr>
-            <tr>
-              <td>
-                did:btcr
-              </td>
-              <td>
-                A
-              </td>
-              <td>
-                A
-              </td>
-              <td>
-                Open, permissionless, and globally resolvable.
-                [<a href="#eval-1">eval-1</a>]
-              </td>
-            </tr>
-            <tr>
-              <td>
-                did:sov
-              </td>
-              <td>
-                A
-              </td>
-              <td>
-                B
-              </td>
-              <td>
-                Transactions on the Sovrin ledger are publicly readable by anyone. Transactions
-                may be written by any Transaction Author however for GDPR reasons personal
-                data may not currently be written to the Sovrin ledger. See
-                <a href="https://sovrin.org/data-protection/">Sovrin Data Protection</a>.
-                [<a href="#eval-1">eval-1</a>]
-              </td>
-            </tr>
-            <tr>
-              <td>
-                did:ethr
-              </td>
-              <td>
-                A
-              </td>
-              <td>
-                A
-              </td>
-              <td>
-                Open, permissionless, and globally resolvable.
-                [<a href="#eval-1">eval-1</a>]
-              </td>
-            </tr>
-            <tr>
-              <td>
-                did:jolo
-              </td>
-              <td>
-                A
-              </td>
-              <td>
-                A
-              </td>
-              <td>
-                Open, permissionless, and globally resolvable.
-                [<a href="#eval-1">eval-1</a>]
-              </td>
-            </tr>
-          </table>
-        </section>
-      </section> <!-- scope -->
-    </section> <!-- design -->
-    <section>
-      <h3>Operation</h3>
-      <section>
-        <h4 id="criteria-9">Financial accountability</h4>
-        <a href="#criteria-9">https://www.w3.org/TR/did-rubric#criteria-9</a>
-        <section>
-          <h5>Question</h5>
-          <p>
-            How transparent and fair are the economics of the Method?
-          </p>
-        </section>
-        <section>
-          <h5>Responses</h5>
-          <ol type="A">
-            <li>
-              All operational finances are transparent and accounted for.
-              ​ </li>
-            <li>
-              Compensation for primary operators is transparent.
-              ​ </li>
-            <li>
-              Some financial flows are visible.
-              ​ </li>
-            <li>
-              Operation is privatized with no visibility.
-            </li>
-          </ol>
-        </section>
-        <section>
-          <h5>Relevance</h5>
-          <p>
-            Similar to Governance, financial accountability reflects the integrity and
-            sustainability of the DID registry. The more open, transparent, and accountable
-            the system, the greater the confidence a DID controller may have that it will
-            remain stable and operational, and therefore continue to provide service.
-          </p>
-        </section>
-        <section>
-          <h5>Examples</h5>
-          <table class="simple">
-            <tr>
-              <th>
-                Method
-              </th>
-              <th>
-                Net.
-              </th>
-              <th>
-                Reg.
-              </th>
-              <th>
-                Notes
-              </th>
-            </tr>
-            <tr>
-              <td>
-                did:peer
-              </td>
-              <td>
-                D
-              </td>
-              <td>
-                D
-              </td>
-              <td>
-                The financials of both parties have no visibility.
-                [<a href="#eval-1">eval-1</a>]
-              </td>
-            </tr>
-            <tr>
-              <td>
-                did:git
-              </td>
-              <td>
-                A
-              </td>
-              <td>
-                D
-              </td>
-              <td>
-                The financials of both parties have no visibility. However, the underlying git
-                software is free and open source.
-                [<a href="#eval-1">eval-1</a>]
-              </td>
-            </tr>
-            <tr>
-              <td>
-                did:btcr
-              </td>
-              <td>
-                A-
-              </td>
-              <td>
-                A-
-              </td>
-              <td>
-                Bitcoin is transparent, although operations are somewhat obscured by
-                pseudonymous transaction addresses.
-                [<a href="#eval-1">eval-1</a>]
-              </td>
-            </tr>
-            <tr>
-              <td>
-                did:sov
-              </td>
-              <td>
-                B
-              </td>
-              <td>
-                B
-              </td>
-              <td>
-                The Sovrin Foundation publishes an annual report with details about overall
-                finances for their operation, and the books are required to be openly
-                available for inspection by anyone.
-                [<a href="#eval-1">eval-1</a>]
-              </td>
-            </tr>
-            <tr>
-              <td>
-                did:ethr
-              </td>
-              <td>
-                A-
-              </td>
-              <td>
-                A-
-              </td>
-              <td>
-                Ethereum is transparent, although operations are somewhat obscured by pseudonymous transaction
-                addresses.
-                [<a href="#eval-1">eval-1</a>]
-              </td>
-            </tr>
-            <tr>
-              <td>
-                did:jolo
-              </td>
-              <td>
-                A-
-              </td>
-              <td>
-                A-
-              </td>
-              <td>
-                Ethereum is transparent, although operations are somewhat obscured by
-                pseudonymous transaction addresses.
-                [<a href="#eval-1">eval-1</a>]
-              </td>
-            </tr>
-          </table>
-        </section>
-      </section> <!-- financial -->
-      <section>
-        <h4 id="criteria-10">Limited resource resolution</h4>
-        <a href="#criteria-10">https://www.w3.org/TR/did-rubric#criteria-10</a>
-        <section>
-          <h5>Question</h5>
-          <p>
-            How much memory is required for DID resolution, without relying on authoritative
-            intermediaries (e.g. blockchain explorer APIs)? We consider the amount of memory
-            required to fully resolve a DID of the method, whether that memory is stored
-            locally or processed ephemerally via communications.
-          </p>
-        </section>
-        <section>
-          <h5>Responses</h5>
-          <ol type="A">
-            <li>
-              Minimal. Less than 1MB
-            </li>
-            <li>
-              Modest. 1MB to 1GB
-            </li>
-            <li>
-              Substantial. 1GB to 128 GB
-            </li>
-            <li>
-              Exceptional. Over 128GB in memory
-            </li>
-          </ol>
-        </section>
-        <section>
-          <h5>Relevance</h5>
-          <p>
-            Whether or not one can resolve a DID directly on a resource-constrained device
-            affects the granularity at which smaller devices can be part of the ecosystem.
-            If small edge devices, such as a smart watch, smart speaker, or even a mobile
-            phone, are incapable of directly resolving a DID of the DID Method, then the
-            method will lead to cloud-based services like blockchain explorer APIs, which
-            themselves become a point of centralization. Many find this option an
-            acceptable engineering trade-off. Others would prefer solutions that allow
-            even the smallest devices to be fully capable of resolving DIDs in an
-            authoritative manner.
-          </p>
-        </section>
-        <section>
-          <h5>Examples</h5>
-          <table class="simple">
-            <tr>
-              <th>
-                Method
-              </th>
-              <th>
-                Net.
-              </th>
-              <th>
-                Reg.
-              </th>
-              <th>
-                Notes
-              </th>
-            </tr>
-            <tr>
-              <td>
-                did:peer
-              </td>
-              <td>
-                A
-              </td>
-              <td>
-                A
-              </td>
-              <td>
-                Resolution typically requires looking up a file in the file system, which
-                uses minimal RAM. [<a href="#eval-2">eval-2</a>]
-              </td>
-            </tr>
-            <tr>
-              <td>
-                did:git
-              </td>
-              <td>
-                B
-              </td>
-              <td>
-                varies
-              </td>
-              <td>
-                Git for Windows is just shy of 50 MB (please update if there are smaller
-                versions available). However, one must still download the entire repo
-                containing the registry material.
-                [<a href="#eval-1">eval-1</a>]
-              </td>
-            </tr>
-            <tr>
-              <td>
-                did:btcr
-              </td>
-              <td>
-                D
-              </td>
-              <td>
-                D
-              </td>
-              <td>
-                To definitively resolve, one must operate a full node.
-                [<a href="#eval-1">eval-1</a>]
-              </td>
-            </tr>
-            <tr>
-              <td>
-                did:sov
-              </td>
-              <td>
-                A
-              </td>
-              <td>
-                A
-              </td>
-              <td>
-                The Sovrin ledger is based on Hyperledger Indy which supports highly efficient
-                state proofs for cryptographic verification of resolution responses. A full
-                node is not required.
-                [<a href="#eval-1">eval-1</a>]
-              </td>
-            </tr>
-            <tr>
-              <td>
-                did:ethr
-              </td>
-              <td>
-                B
-              </td>
-              <td>
-                B
-              </td>
-              <td>
-                A full ethereum node takes >100GB, but a light ethereum node can support this
-                method with less than 256kb.
-                [<a href="#eval-1">eval-1</a>]
-              </td>
-            </tr>
-            <tr>
-              <td>
-                did:jolo
-              </td>
-              <td>
-                B
-              </td>
-              <td>
-                B
-              </td>
-              <td>
-                A full ethereum node takes >100GB, but a light ethereum node can support this
-                method with less than 256kb.
-                [<a href="#eval-1">eval-1</a>]
-              </td>
-            </tr>
-          </table>
-        </section>
-      </section> <!-- resource res -->
-
-      <section>
-        <h4 id="criteria-11">Limited resource registration</h4>
-        <a href="#criteria-11">https://www.w3.org/TR/did-rubric#criteria-11</a>
-        <section>
-          <h5>Question</h5>
-          <p>
-            What are the minimum resources required to create a trusted DID without relying
-            on intermediaries?
-          </p>
-        </section>
-        <section>
-          <h5>Responses</h5>
-          <ol type="A">
-            <li>
-              Minimal. Less than 1MB
-            </li>
-            <li>
-              Modest. 1MB to 1GB
-            </li>
-            <li>
-              Substantial. 1GB to 128 GB
-            </li>
-            <li>
-              Exceptional. Over 128GB in memory
-            </li>
-          </ol>
-        </section>
-        <section>
-          <h5>Relevance</h5>
-          <p>
-            Being able to create a DID in constrained situations enables certain types of
-            decentralized applications that otherwise are not possible. On the edge, many
-            devices rely on gateways to manage compute-, memory-, and bandwidth- intensive
-            tasks. For example, while a smart lightbulb might use ZigBee or 6LowPAN, it
-            will typically use a hub to connect to the Internet, even for access from
-            devices within the local IP network. The more resources it takes for small
-            devices to participate in registration, the greater the percentage of those
-            that will need to rely on centralizing factors like hubs and gateways.
-          </p>
-        </section>
-        <section>
-          <h5>Examples</h5>
-          <table class="simple">
-            <tr>
-              <th>
-                Method
-              </th>
-              <th>
-                Net.
-              </th>
-              <th>
-                Reg.
-              </th>
-              <th>
-                Notes
-              </th>
-            </tr>
-            <tr>
-              <td>
-                did:peer
-              </td>
-              <td>
-                A
-              </td>
-              <td>
-                A
-              </td>
-              <td>
-                Registration may require a few KB of RAM as a DID doc is written to disk.
-                [<a href="#eval-2">eval-2</a>]
-              </td>
-            </tr>
-            <tr>
-              <td>
-                did:git
-              </td>
-              <td>
-                B
-              </td>
-              <td>
-                varies
-              </td>
-              <td>
-                Git for Windows is just shy of 50 MB (please update if there are smaller
-                versions available). However, one must still download the entire repo
-                containing the registry material.
-                [<a href="#eval-1">eval-1</a>]
-              </td>
-            </tr>
-            <tr>
-              <td>
-                did:btcr
-              </td>
-              <td>
-                A-
-              </td>
-              <td>
-                A-
-              </td>
-              <td>
-                To register a DID, one must simply get a transaction on the ledger, unless you
-                choose to host a continuation DID Document elsewhere, which would require its
-                own resources.
-                [<a href="#eval-1">eval-1</a>]
-              </td>
-            </tr>
-            <tr>
-              <td>
-                did:sov
-              </td>
-              <td>
-                A
-              </td>
-              <td>
-                A
-              </td>
-              <td>
-                Registration of a DID is a single transaction that can be performed by a thin
-                client.
-                [<a href="#eval-1">eval-1</a>]
-              </td>
-            </tr>
-            <tr>
-              <td>
-                did:ethr
-              </td>
-              <td>
-                A+
-              </td>
-              <td>
-                A+
-              </td>
-              <td>
-                The smart contract used for did:ethr recognizes any valid public key as a DID,
-                without requiring registration. This means DIDs can even be created offline
-                with full usability. Only rotation and the registration of service endpoints
-                require network access.
-                [<a href="#eval-1">eval-1</a>]
-              </td>
-            </tr>
-            <tr>
-              <td>
-                did:jolo
-              </td>
-              <td>
-                A+
-              </td>
-              <td>
-                A+
-              </td>
-              <td>
-                The smart contract used for did:ethr recognizes any valid public key as a DID,
-                without requiring registration. Only rotation and the registration of service
-                endpoints require network access.
-                [<a href="#eval-1">eval-1</a>]
-              </td>
-            </tr>
-          </table>
-        </section>
-      </section> <!-- resource reg -->
-    </section> <!-- operation -->
-    <section>
-      <h3>Enforcement</h3>
-      <p>
-        The matter of enforcement may be interpreted at many levels.
-        Enforcement criteria addresses how the system enforces its own
-        rules as well as how jurisdictional governance applies.
-      </p>
-      <p>
-        In state-level governance, enforcement is an operational matter for the police
-        and a judgmental matter for the courts. In other words, the police and the
-        courts constitute the enforcement powers of governance.
-      </p>
-      <p>
-        For distributed systems, especially those like Bitcoin and Ethereum,
-        enforcement is a function of both social and technical functions.
-      </p>
-      <p>
-        Technical enforcement could include such notions as which cryptography is used
-        to ensure proper authentication of transactions or the details of a consensus
-        mechanism such as proof of work (POW) or proof of stake (POS). Should a given
-        cryptographic technique prove to be compromised, that would affect the ability
-        of the system to enforce its own rules, making the specific cryptography used
-        by a given Method a significant factor in evaluating the suitability of a
-        given Method. Further, understanding the decentralized nature of a given POW
-        or POS mechanism requires an <a>Evaluation</a> of both the means for executing
-        the mechanism as well as a profile of those parties who could potentially
-        influence or even undermine that mechanism.
-      </p>
-      <p>
-        Social enforcement mechanisms rely on community or institutions. For Methods
-        that have explicit governing bodies, like did:sov, presumably enforcement is a
-        matter under their jurisdiction. Nodes on the network that operate outside the
-        guidelines of the governing bodies can presumably have permission revoked as a
-        means of enforcement. Methods that do not have formal governing bodies may,
-        nevertheless, have a strong enough community to correct violations, as Ethereum
-        did in response to the
-        <a href="https://www.coindesk.com/understanding-dao-hack-journalists">DAO hack</a>.
-      </p>
-      <p>
-        Finally, all Methods operate in (and across) one or more geographic
-        jurisdictions, each with potentially distinct laws and mechanisms of
-        enforcement. Identifying the potential enforcement mechanisms that
-        <em>could</em> apply to the Method, to those using a Method, or to the
-        operators of a Method, is almost certainly going to be relevant to certain
-        <a>Evaluator</a>s. We have already seen GDPR and various US laws being applied
-        based on where different servers are physically located, with lawsuits brought
-        against server operators. It is inevitable that similar actions will eventually
-        be brought against DID Method operators at various levels.
-      </p>
-      <p>
-        In short, understanding the process for identifying violations and enforcing
-        the rules as set by the rulemakers is vital to a complete Evaluation of the
-        decentralization of a DID Method. We regret that we were not able to sufficiently
-        explore these issues for this rubric and we look forward to working with
-        subsequent collaborators to flesh out criteria that can provide suitable
-        guidance for enforcement criteria.
-      </p>
-      <section>
-        <h4 id="criteria-12">Auditability</h4>
-        <a href="#criteria-12">https://www.w3.org/TR/did-rubric#criteria-12</a>
-        <section>
-          <h5>Question</h5>
-          <p>
-            Who can retrieve cryptographic proof of the history of changes to a given DID
-            Document?
-          </p>
-        </section>
-        <section>
-          <h5>Responses</h5>
-          <ol type="A">
-            <li>
-              Anyone
-            </li>
-            <li>
-              Only a select group, including parties not involved in a given DID transaction
-            </li>
-            <li>
-              Only parties to the transaction
-            </li>
-            <li>
-              Not available
-            </li>
-          </ol>
-        </section>
-        <section>
-          <h5>Relevance</h5>
-          <p>
-            Trustlessness is a prerequisite of a decentralized system. If you have to
-            trust the source of a DID Document (i.e., if you can't verify
-            cryptographically a DID Document that is returned from resolution), then you
-            are at the mercy of a potentially centralized authority. If, instead you have
-            a cryptographic audit trail, then the current state of a DID cannot be
-            compromised by an intermediary or central party.
-          </p>
-        </section>
-        <section>
-          <h5>Examples</h5>
-          <table class="simple">
-            <tr>
-              <th>
-                Method
-              </th>
-              <th>
-                Reg.
-              </th>
-              <th>
-                Notes
-              </th>
-            </tr>
-            <tr>
-              <td>
-                did:peer
-              </td>
-              <td>
-                C-
-              </td>
-              <td>
-                DID:peer maintains a cryptographic journal, but it is only available to the
-                peers and, technically, can be refused (each peer may suspend interactions at
-                any time).
-                [<a href="#eval-1">eval-1</a>]
-              </td>
-            </tr>
-            <tr>
-              <td>
-                did:git
-              </td>
-              <td>
-                B-
-              </td>
-              <td>
-                <em>If</em> you have access to the authoritative git repo, you can see the
-                cryptographic journal. However, within the method specification, there is no
-                way to know if the repo you are inspecting is, in fact, definitive.
-                [<a href="#eval-1">eval-1</a>]
-              </td>
-            </tr>
-            <tr>
-              <td>
-                did:btcr
-              </td>
-              <td>
-                A
-              </td>
-              <td>
-                Anyone can see everything.
-                [<a href="#eval-1">eval-1</a>]
-              </td>
-            </tr>
-            <tr>
-              <td>
-                did:sov
-              </td>
-              <td>
-                A
-              </td>
-              <td>
-                Anyone can see everything&mdash;the Sovrin ledger is completely public.
-                [<a href="#eval-1">eval-1</a>]
-              </td>
-            </tr>
-            <tr>
-              <td>
-                did:ethr
-              </td>
-              <td>
-                A
-              </td>
-              <td>
-                Anyone can see updates and deletes. Creation is private.
-                [<a href="#eval-1">eval-1</a>]
-              </td>
-            </tr>
-            <tr>
-              <td>
-                did:jolo
-              </td>
-              <td>
-                A
-              </td>
-              <td>
-                Anyone can see updates and deletes. Creation is private.
-                [<a href="#eval-1">eval-1</a>]
-              </td>
-            </tr>
-          </table>
-        </section>
-      </section> <!-- auditability -->
-
-    </section> <!-- enforcement -->
-    <section>
-      <h3>Alternatives</h3>
-      <p>
-        For each major software component (Wallet, Resolver, and <a>Registry</a>), ask
-        each of the following questions. In this section, because DIDs are so early in
-        the development lifecycle, most DID methods in production have only one
-        implementation and some have none. Therefore, we have not standardized the
-        responses nor provided examples. Consider these open-ended essay questions for
-        consideration. As the market matures, this subset of questions will improve.
-      </p>
-      <section>
-        <h4 id="criteria-13">Active implementations</h4>
-        <a href="#criteria-13">https://www.w3.org/TR/did-rubric#criteria-13</a>
-        <section>
-          <h5>Question</h5>
-          <p>
-            How many (active) substitutable, interoperable implementations support this
-            Method?
-          </p>
-        </section>
-      </section> <!-- active implementations -->
-
-      <section>
-        <h4 id="criteria-14">Market share</h4>
-        <a href="#criteria-14">https://www.w3.org/TR/did-rubric#criteria-14</a>
-        <section>
-          <h5>Question</h5>
-          <p>
-            How large is the share of use by each of the top three implementations?
-          </p>
-        </section>
-      </section> <!-- market share -->
-
-      <section>
-        <h4 id="criteria-15">Platform support</h4>
-        <a href="#criteria-15">https://www.w3.org/TR/did-rubric#criteria-15</a>
-        <section>
-          <h5>Question</h5>
-          <p>
-            Which platforms have implementations?
-          </p>
-        </section>
-      </section> <!-- platform support -->
-
-      <section>
-        <h4 id="criteria-16">Language support</h4>
-        <a href="#criteria-16">https://www.w3.org/TR/did-rubric#criteria-16</a>
-        <section>
-          <h5>Question</h5>
-          <p>
-            Which programming languages have implementations?
-          </p>
-        </section>
-      </section> <!-- language support -->
-
-      <section>
-        <h4 id="criteria-17">Rogue risk</h4>
-        <a href="#criteria-17">https://www.w3.org/TR/did-rubric#criteria-17</a>
-        <section>
-          <h5>Question</h5>
-          <p>
-            If there is one dominant implementation, how many programmers would need to be
-            compromised to get a back-door into distribution?
-          </p>
-        </section>
-      </section> <!-- rogue risk -->
-
-      <section>
-        <h4 id="criteria-18">Forkability</h4>
-        <a href="#criteria-18">https://www.w3.org/TR/did-rubric#criteria-18</a>
-        <section>
-          <h5>Question</h5>
-          <p>
-            Is it forkable?
-          </p>
-        </section>
-      </section> <!-- forkability -->
-    </section> <!-- alternatives -->
-    <section>
-      <h3>Adoption (and diversity)</h3>
-      <p>
-        Adoption covers questions related to how widely a
-        DID Method is used. Similar to the alternatives section, this
-        section is limited because DID methods are just beginning to reach
-        production, and so we have minimal knowledge of current adoption.
-        As the market matures, we anticipate this section improving.
-      </p>
-
-      <section>
-        <h4 id="criteria-19">Acceptance</h4>
-        <a href="#criteria-19">https://www.w3.org/TR/did-rubric#criteria-19</a>
-        <section>
-          <h5>Question</h5>
-          <p>
-            How many relying parties accept DIDs of this Method?
-          </p>
-        </section>
-      </section> <!-- acceptance -->
-
-      <section>
-        <h4 id="criteria-20">Users</h4>
-        <a href="#criteria-20">https://www.w3.org/TR/did-rubric#criteria-20</a>
-        <section>
-          <h5>Question</h5>
-          <p>
-            How many daily active users use this Method?
-          </p>
-        </section>
-      </section> <!-- users -->
-
-      <section>
-        <h4 id="criteria-21">International adoption</h4>
-        <a href="#criteria-21">https://www.w3.org/TR/did-rubric#criteria-21</a>
-        <section>
-          <h5>Question</h5>
-          <p>
-            How many different countries have significant usage?
-          </p>
-        </section>
-      </section><!-- international -->
-
-      <section>
-        <h4 id="criteria-22">In which countries?</h4>
-        <a href="#criteria-22">https://www.w3.org/TR/did-rubric#criteria-22</a>
-        <section>
-          <h5>Question</h5>
-          <p>
-            Which countries have significant usage?
-          </p>
-        </section>
-      </section><!-- which countries -->
-
-      <section>
-        <h4 id="criteria-23">Language support</h4>
-        <a href="#criteria-23">https://www.w3.org/TR/did-rubric#criteria-23</a>
-        <section>
-          <h5>Question</h5>
-          <p>
-            How many (human) languages are supported?
-          </p>
-        </section>
-      </section>
-    </section> <!-- adoption and diversity -->
-
-    <section>
-      <h3>Security</h3>
-      <p>
-        Security has a strong influence on overall trust in the ecosystem. Different DID
-        methods offer different security guarantees, or guarantees of different strengths.
-      </p>
-
-      <section>
-        <h4 id="criteria-24">Robust Crypto</h4>
-        <a href="#criteria-24">https://www.w3.org/TR/did-rubric#criteria-24</a>
-        <section>
-          <h5>Question</h5>
-          <p>
-            What is the lowest security level ("bits of security", not to be confused with
-            bit size of a key or hash) provided by the combination of algorithms and key
-            types that the method requires its implementations to support?
-          </p>
-        </section>
-        <section>
-          <h5>Responses</h5>
-          <ol type="A">
-            <li>
-              No combination of required features produces a profile with less than
-              256 bits of security.
-            </li>
-            <li>
-              Between 128 and 256 bits. (Conventional wisdom &mdash; NIST
-              recommendation &mdash; says that this level of security is
-              adequate until the next revolutionary breakthrough.)
-            </li>
-            <li>
-              Less than 128 bits. (NIST recommends replacing this security by 2030.)
-            </li>
-            <li>
-              Less than 112 bits. (Security is obsolete today.)
-            </li>
-          </ol>
-        </section>
-        <section>
-          <h5>Relevance</h5>
-          <p>
-            A DID method that requires implementations to support something weak (e.g.,
-            1024-bit RSA) is guaranteeing that its users will cooperate by default with
-            encryption that's relatively easy to crack, with hashing that's not adequately
-            collision-resistant, etc. See
-            <a href="https://csrc.nist.gov/publications/detail/sp/800-57-part-1/rev-3/archive/2012-07-10">
-              NIST 800-57 Part 1, section 5.6.1</a>.
-          </p>
-        </section>
-        <section>
-          <h5>Examples</h5>
-          <table class="simple">
-            <tr>
-              <th>Method</th>
-              <th>Score</th>
-              <th>Notes</th>
-            </tr>
-            <tr>
-              <td>
-                did:ipid
-              </td>
-              <td>
-                C
-              </td>
-              <td>
-                The DID method specific identifier for the IPID DID method is
-                a hash of the public key of an IPFS node. Typically this is a
-                SHA-256 value (256 bits of security), but other hashing
-                algorithms can be plugged in. Ed25519 and RSA are the supported
-                keytypes. Edwards keys are 256-bit but offer 128 bits of
-                security; typical 2048-bit RSA offers 112 bits of security.
-                Access to IPFS via a web service API such as ipfs.io/api uses
-                TLS; spot-checking shows 2048-bit RSA certs.
-                [<a href="#eval-2">eval-2</a>]
-              </td>
-            </tr>
-            <tr>
-              <td>
-                did:web
-              </td>
-              <td>
-                C
-              </td>
-              <td>
-                Although the DNS subsystem that supports did:web does not
-                provide strong security, control of a DID is proved by
-                accessing /.well-known over TLS. Thus, the security is tied
-                to certificate config. Most web server certificates use 2048-
-                bit RSA, which gives 112 bits of security.
-                [<a href="#eval-2">eval-2</a>]
-              </td>
-            </tr>
-            <tr>
-              <td>
-                did:indy
-              </td>
-              <td>
-                B
-              </td>
-              <td>
-                Hashes are SHA2-256. Keys are Ed25519/Curve25519 (128 bits of
-                security). Reads and writes to the Indy ledger use CurveZMQ
-                rather than TLS. This gives 128 bits of security in the
-                aggregate.
-                [<a href="#eval-2">eval-2</a>]
-              </td>
-            </tr>
-          </table>
-        </section>
-      </section>
-      <section>
-        <h4 id="criteria-25">Expert Review</h4>
-        <a href="#criteria-25">https://www.w3.org/TR/did-rubric#criteria-25</a>
-        <section>
-          <h5>Question</h5>
-          <p>
-            Does the system use cryptographic and security primitives that are well vetted
-            by technical experts, and battle hardened in the school of experience?
-          </p>
-        </section>
-        <section>
-          <h5>Responses</h5>
-          <ol type="A">
-            <li>
-              Experts generally consider the system very secure, and this opinion is
-              reinforced by a track record of secure production use.
-            </li>
-            <li>
-              The theoretical security of the system looks excellent, and no known attacks
-              or substantive criticisms are unaddressed. However, limited review or limited
-              experience informs the opinion.
-            </li>
-            <li>
-              Credible reports of vulnerabilities or design shortcomings have not been addressed.
-            </li>
-            <li>
-              The system actively uses mechanisms that are officially deprecated.
-            </li>
-          </ol>
-        </section>
-        <section>
-          <h5>Relevance</h5>
-          <p>
-            Exotic crypto and other security mechanisms without expert review and
-            a production track record is likely to contain hidden risks.
-          </p>
-        </section>
-        <section>
-          <h5>Examples</h5>
-          <table class="simple">
-            <tr>
-              <th>Method</th>
-              <th>Score</th>
-              <th>Notes</th>
-            </tr>
-            <tr>
-              <td>
-                did:iota
-              </td>
-              <td>
-                A
-              </td>
-              <td>
-                The IOTA ecosystem has <a href="https://trinity.iota.org/security/">
-                  published security audits by at least three
-                  independent experts</a>. Its code is open source. It uses cryptographic
-                primitives that are well known (e.g., the Blake256-2b hash). It has
-                been running in production for years with no reported CVEs.
-                [<a href="#eval-2">eval-2</a>]
-              </td>
-            </tr>
-            <tr>
-              <td>
-                did:git
-              </td>
-              <td>
-                C
-              </td>
-              <td>
-                Git uses SHA-1 hashes to identify commits. This hash has known collision
-                attacks.
-                [<a href="#eval-2">eval-2</a>]
-              </td>
-            </tr>
-          </table>
-        </section>
-      </section>
-      <section>
-        <h4 id="criteria-26">Future Proofing</h4>
-        <a href="#criteria-26">https://www.w3.org/TR/did-rubric#criteria-26</a>
-        <section>
-          <h5>Question</h5>
-          <p>
-            How friendly is the system to adopting post-quantum crypto, larger hashes,
-            or other measures that upgrade its security?
-          </p>
-        </section>
-        <section>
-          <h5>Responses</h5>
-          <ol type="A">
-            <li>
-              Any user of the system can easily upgrade their crypto at any time.
-            </li>
-            <li>
-              No code changes are needed, but the whole system needs to be reconfigured
-              to allow new crypto.
-            </li>
-            <li>
-              Code changes must be implemented before new crypto is possible.
-            </li>
-            <li>
-              Code changes must be implemented, and migration of all existing data must
-              be performed, before new crypto is possible.
-            </li>
-          </ol>
-        </section>
-        <section>
-          <h5>Relevance</h5>
-          <p>
-            A DID method that is hard to upgrade with respect to crypto creates incentives
-            to remain with deprecated algorithms beyond their useful lifespan.
-          </p>
-        </section>
-        <section>
-          <h5>Examples</h5>
-          <table class="simple">
-            <tr>
-              <th>Method</th>
-              <th>Score</th>
-              <th>Notes</th>
-            </tr>
-            <tr>
-              <td>
-                did:ipid
-              </td>
-              <td>
-                B
-              </td>
-              <td>
-                The IPFS ecosystem allows a user to use a different hash
-                algorithm as a configuration choice. Since this algorithm
-                is the basis of the CID, which is in turn the basis of the
-                DID value, did:ipid can easily upgrade its DID values if a
-                hash algorithm needs updating. (Score = A) However, did:ipid
-                supports only the Ed25519 and RSA keytypes; upgrading these
-                would require a revised spec and re-implementation. (Score =
-                C).
-                [<a href="#eval-2">eval-2</a>]
-              </td>
-            </tr>
-            <tr>
-              <td>
-                did:peer
-              </td>
-              <td>
-                A
-              </td>
-              <td>
-                The fundamentals of peer DIDs are described without reference
-                to any particular hash or key type. Representations of hashes
-                use multihash, allowing arbitrary upgrade without disruption.
-                Any implementation can begin using new key types at any time.
-                [<a href="#eval-2">eval-2</a>]
-              </td>
-            </tr>
-          </table>
-        </section>
-      </section>
-      <section>
-        <h4 id="criteria-27">Self Certification</h4>
-        <a href="#criteria-27">https://www.w3.org/TR/did-rubric#criteria-27</a>
-        <section>
-          <h5>Question</h5>
-          <p>
-            To what extent is the entropy used to create an identifier demonstrably
-            connected to the party that created its inception key?
-          </p>
-        </section>
-        <section>
-          <h5>Responses</h5>
-          <ol type="A">
-            <li>
-              Identifier entropy is directly derived from inception keys. Initial
-              pre-rotation preserves this quality.
-            </li>
-            <li>
-              Identifiers are assigned by a VDR rather than chosen by users. The VDR uses
-              a cryptographically robust RNG. This creates a chain of custody that's as
-              strong as the VDR's integrity.
-            </li>
-            <li>
-              Identifiers are related to inception keys with some caveats, or they are
-              assigned by a VDR using an algorithm that has vulnerabilities.
-            </li>
-            <li>
-              Identifiers are arbitrary. They have no chain of custody before they are
-              registered on a VDR. DID squatting is possible.
-            </li>
-          </ol>
-        </section>
-        <section>
-          <h5>Relevance</h5>
-          <p>
-            An identifier that has a predictable or manipulable value, or that has
-            inception keys that anyone could have created, is an attack vector.
-          </p>
-        </section>
-        <section>
-          <h5>Examples</h5>
-          <table class="simple">
-            <tr>
-              <th>Method</th>
-              <th>Score</th>
-              <th>Notes</th>
-            </tr>
-            <tr>
-              <td>
-                did:keri
-              </td>
-              <td>
-                A
-              </td>
-              <td>
-                The value of a DID in did:keri is always directly derived from its
-                inception key. This guarantees a chain of custody even before it is
-                registered on a public VDR. The chain of custody cannot be broken
-                without invalidating the DID.
-                [<a href="#eval-2">eval-2</a>]
-              </td>
-            </tr>
-            <tr>
-              <td>
-                did:hedera
-              </td>
-              <td>
-                B
-              </td>
-              <td>
-                The value of a DID in did:hedera is always directly derived from the
-                <code>#did-root-key</code> value. This guarantees a chain of custody for that
-                key. However, the DID doc may contain other keys at inception, which means that
-                they do not have the same chain of custody. This may or may not matter.
-                [<a href="#eval-2">eval-2</a>]
-              </td>
-            </tr>
-            <tr>
-              <td>
-                did:web
-              </td>
-              <td>
-                D
-              </td>
-              <td>
-                No chain of custody is guaranteed; the current owner of a did:web
-                may not be the same as the owner of that domain in the past or the
-                future. Within the lifespan of ownership of a domain, the DNS
-                record and <code>.well-known</code> data are not guaranteed to
-                provide a stable chain of custody for a DID, either.
-                [<a href="#eval-2">eval-2</a>]
-              </td>
-            </tr>
-          </table>
-        </section>
-      </section>
-      <section>
-        <h4 id="criteria-28">Availability</h4>
-        <a href="#criteria-28">https://www.w3.org/TR/did-rubric#criteria-28</a>
-        <section>
-          <h5>Question</h5>
-          <p>
-            How robust are protections against attempts to suppress information flow,
-            whether legal (cease and desist) or technical (denial of service)?
-          </p>
-        </section>
-        <section>
-          <h5>Responses</h5>
-          <ol type="A">
-            <li>
-              The VDR is practically immune from this risk.
-            </li>
-            <li>
-              The VDR has reasonable protections in place. However, motivated and well
-              resourced attackers could temporarily disrupt access in a targeted context.
-            </li>
-            <li>
-              Attackers could permanently disrupt access in a targeted context.
-            </li>
-          </ol>
-        </section>
-        <section>
-          <h5>Relevance</h5>
-          <p>
-            Control over an identifier is far less valuable if the propagation of
-            that control can be limited by someone else. Availability is the "A"
-            in the security evaluation acronym CIA.
-          </p>
-        </section>
-        <section>
-          <h5>Examples</h5>
-          <table class="simple">
-            <tr>
-              <th>Method</th>
-              <th>Score</th>
-              <th>Notes</th>
-            </tr>
-            <tr>
-              <td>
-                did:sov
-              </td>
-              <td>
-                B
-              </td>
-              <td>
-                A Hyperledger Indy blockchain such as Sovrin MainNet returns
-                state proofs that allow a reliable answer even if only a single
-                node responds. It also separates network traffic related to
-                clients from traffic related to inter-node consensus, with
-                consensus occurring on a NIC that blacklists all IP addresses
-                except other nodes. This significantly mitigates denial of service
-                or service interruptions for reading. Writes are submitted to 1/3
-                of the nodes in parallel, so attacks on individual nodes are
-                unlikely to produce downtime. This behavior is validated with
-                careful testing and has been demonstrated through four years of
-                production usage with greater than 99% uptime. Sovrin adds to
-                Indy's guarantees by publishing a
-                <a href="https://sovrin.org/ssi-metrics-dashboards/">
-                  node and network health dashboard</a>, by maintaining statistics
-                about the historic behavior of nodes, by having a
-                <a
-                  href="https://github.com/sovrin-foundation/sovrin-sip/blob/master/text/5001-node-selection-algorithm/README.md">
-                  publicly vetted node selection algorithm</a> that forces nodes
-                in different geographies and legal jurisdictions, and by having a
-                <a
-                  href="https://github.com/sovrin-foundation/sovrin-sip/tree/master/text/5002-sovrin-crisis-management-plan#readme">
-                  written crisis management plan</a> that has been exercised
-                and reviewed by security professionals. However, a determined
-                adversary might be able to reduce network write speed by submitting
-                many transactions in parallel, for a sustained period of time.
-                [<a href="#eval-2">eval-2</a>]
-              </td>
-            </tr>
-            <tr>
-              <td>
-                did:btcr
-              </td>
-              <td>
-                A
-              </td>
-              <td>
-                The global bitcoin network has a
-                <a href="https://bitcoinist.com/better-sov-bitcoin-running-24x7-with-99-98-uptime-since-10-years/">
-                  strong track record of uptime</a>, stretching back for well
-                over a decade, even in the face of motivated attack.
-                [<a href="#eval-2">eval-2</a>]
-              </td>
-            </tr>
-          </table>
-        </section>
-      </section>
-      <section>
-        <h4 id="criteria-29">Evolution</h4>
-        <a href="#criteria-29">https://www.w3.org/TR/did-rubric#criteria-29</a>
-        <section>
-          <h5>Question</h5>
-          <p>
-            Is the current state of a DID document provably correct from a history
-            that's visible to anyone who can resolve the DID?
-          </p>
-        </section>
-        <section>
-          <h5>Responses</h5>
-          <ol type="A">
-            <li>
-              Every evolution of state is recorded, accessible, and linked appropriately
-              to its predecessor. Arbitrary versions can be queried and proved correct,
-              and they have a reasonably useful timestamp.
-            </li>
-            <li>
-              Adequate evidence of proper evolution exists, and a forensic analysis
-              could prove correctness. However, it's not exposed for consumption of
-              ordinary resolvers, it lacks supporting metadata, or it's exposed in
-              a very suboptimal way.
-            </li>
-            <li>
-              Limited evidence of proper evolution exists.
-            </li>
-            <li>
-              No evidence of proper evolution exists; the users have to trust the
-              system's assertion that current state resulted from something appropriate.
-            </li>
-          </ol>
-        </section>
-        <section>
-          <h5>Relevance</h5>
-          <p>
-            It's possible to tamper with systems that don't actively prove the
-            correctness of their current state. Such tampering is not easy to
-            discover.
-          </p>
-        </section>
-        <section>
-          <h5>Examples</h5>
-          <table class="simple">
-            <tr>
-              <th>
-                Method
-              </th>
-              <th>
-                Net.
-              </th>
-              <th>
-                Reg.
-              </th>
-              <th>
-                Notes
-              </th>
-            </tr>
-            <tr>
-              <td>
-                did:foo
-              </td>
-              <td>
-                A
-              </td>
-              <td>
-                D
-              </td>
-              <td>
-                By design, did:foo supports 123.5 bits of security.
-              </td>
-            </tr>
-          </table>
-        </section>
-      </section>
-      <section>
-        <h4 id="criteria-30">Many Eyes</h4>
-        <a href="#criteria-30">https://www.w3.org/TR/did-rubric#criteria-30</a>
-        <section>
-          <h5>Question</h5>
-          <p>
-            Is the code of the method published, does it have many contributors,
-            and does it have a published vulnerability reporting (responsible
-            disclosure) mechanism?
-          </p>
-        </section>
-        <section>
-          <h5>Responses</h5>
-          <ol type="A">
-            <li>
-              The code is public. It has hundreds of contributors. CVEs or similar
-              reports have been published and handled appropriately.
-            </li>
-            <li>
-              The code is public, but the list of contributors is small. No
-              vulnerability reporting mechanism has been announced, or it's
-              been announced but has no demonstrable track record.
-            </li>
-            <li>
-              The code is partly private.
-            </li>
-            <li>
-              The code is entirely private.
-            </li>
-          </ol>
-        </section>
-        <section>
-          <h5>Relevance</h5>
-          <p>
-            Security vulnerabilities tend to be found and fixed best in code that
-            has many active contributions and a strong history of correctly handled
-            responsible disclosure.
-          </p>
-        </section>
-        <section>
-          <h5>Examples</h5>
-          <table class="simple">
-            <tr>
-              <th>Method</th>
-              <th>Score</th>
-              <th>Notes</th>
-            </tr>
-            <tr>
-              <td>
-                did:sov
-              </td>
-              <td>
-                A
-              </td>
-              <td>
-                The most prominent codebases that implement this method,
-                github.com/hyperledger/indy-* have over 1000 forks, about
-                200 unique contributors from over a dozen organizations,
-                spanning 5 years and about 25000 commits as of 2021. Sovrin's
-                Technical Governance Board, which vets some aspects of the
-                design, is composed of numerous independent experts, and
-                meets regularly. Both Hyperledger and Sovrin Foundation
-                have responsible disclosure mechanisms for vulnerabilities,
-                and both have successfully handled vulnerabilities from
-                initial report to patch and public disclosure.
-                [<a href="#eval-2">eval-2</a>]
-              </td>
-            </tr>
-            <tr>
-              <td>
-                did:peer
-              </td>
-              <td>
-                B
-              </td>
-              <td>
-                The spec and implementations of code are entirely public,
-                with incubation through DIF's identifiers WG.
-                However, contributors are limited to a dozen developers,
-                activity is light, and there is no announced vulnerability
-                mechanism.
-                [<a href="#eval-2">eval-2</a>]
-              </td>
-            </tr>
-          </table>
-        </section>
-      </section>
-      <section>
-        <h4 id="criteria-31">Diffuse Control</h4>
-        <a href="#criteria-31">https://www.w3.org/TR/did-rubric#criteria-31</a>
-        <section>
-          <h5>Question</h5>
-          <p>
-            To what extent does the system support mechanisms where DID control
-            is distributed across multiple parties (m-of-n control, threshold
-            signatures, etc.)?
-          </p>
-        </section>
-        <section>
-          <h5>Responses</h5>
-          <ol type="A">
-            <li>
-              Rich diffuse control mechanisms are a first-class feature, and anyone who
-              resolves a DID can see whether they are in use so confidence is increased.
-              This may include device revocation (where keys must be exercised on a
-              particular device to be valid).
-            </li>
-            <li>
-              Some diffuse control is possible but has important deficits in
-              documentation, maturity, or visibility.
-            </li>
-            <li>
-              Multiple parties can exercise control independently. Diffuse control
-              is possible outside the system (e.g., using Shamir secret sharing to
-              reconstitute a single key before updating a DID document). It's not
-              possible to know whether such mechanisms are in use.
-            </li>
-            <li>
-              Only a single party can exercise control at a time.
-            </li>
-          </ol>
-        </section>
-        <section>
-          <h5>Relevance</h5>
-          <p>
-            Diffuse trust makes hacking harder and recovery more robust (but maybe more complex).
-          </p>
-        </section>
-        <section>
-          <h5>Examples</h5>
-          <table class="simple">
-            <tr>
-              <th>Method</th>
-              <th>Score</th>
-              <th>Notes</th>
-            </tr>
-            <tr>
-              <td>
-                did:key
-              </td>
-              <td>
-                C
-              </td>
-              <td>
-                did:key is controlled by a single key. If aggregate control is desired,
-                these keys can be sharded, but that is outside the method's feature set.
-                [<a href="#eval-2">eval-2</a>]
-              </td>
-            </tr>
-            <tr>
-              <td>
-                did:peer
-              </td>
-              <td>
-                A
-              </td>
-              <td>
-                Dynamic peer DIDs explicitly define an m-of-n scheme that can be
-                used to authorize any evolution of state, or any verification
-                method supported by the DID.
-                [<a href="#eval-2">eval-2</a>]
-              </td>
-            </tr>
-          </table>
-        </section>
-      </section>
-      <section>
-        <h4 id="criteria-32">Regulatory Compliance</h4>
-        <a href="#criteria-32">https://www.w3.org/TR/did-rubric#criteria-32</a>
-        <section>
-          <h5>Question</h5>
-          <p>
-            Does the system use cryptographic mechanisms that satisfy legal
-            requirements in relevant jurisdictions (e.g., FIPS-certified
-            algorithms, requirements for encryption back doors, etc.).
-          </p>
-        </section>
-        <section>
-          <h5>Responses</h5>
-          <ol type="A">
-            <li>
-              The method uses only algorithms that are officially endorsed by
-              whatever regulatory bodies are important to the reviewer.
-              For example, a reviewer in the USA might assign this score
-              if cryptography is FIPS-approved.
-            </li>
-            <li>
-              The method uses algorithms that are ignored rather than endorsed by
-              the relevant authority -- or uses a combination of algorithms
-              with the practical outcome that interop is unlikely using only
-              approved settings.
-            </li>
-            <li>
-              The method uses cryptography that is not aligned with requirements
-              of the relevant authority.
-            </li>
-          </ol>
-        </section>
-        <section>
-          <h5>Relevance</h5>
-          <p>Some governments and enterprises may require DID methods that are
-            officially endorsed by the EU, by their own security bureau, etc.
-            Note that being out of harmony with government requirements may be
-            considered a positive property by some reviewers; see
-            <a href="https://www.wired.com/2013/09/nsa-backdoor/">this story</a>
-            for an example.
-          </p>
-        </section>
-        <section>
-          <h5>Examples</h5>
-          <table class="simple">
-            <tr>
-              <th>Method</th><th>Score</th><th>Notes</th>
-            </tr>
-            <tr>
-              <td>
-                did:twit
-              </td>
-              <td>
-                A (for a reviewer suspicious of NIST-approved curves); C (for a
-                reviewer requiring compliance with standards
-                of the Australian government)
-              </td>
-              <td>
-                The did:twit method supports only Ed25519 keys, which are
-                not on the FIPS 186-4 approved curve list required by the
-                Australian government.
-                [<a href="#eval-2">eval-2</a>]
-              </td>
-            </tr>
-            <tr>
-              <td>
-                did:pkh
-              </td>
-              <td>
-                C (for a reviewer requiring compliance with the Chinese
-                government's SM2 cryptosystem); B (for a reviewer wanting to
-                use the system in Canadian government contexts).
-              </td>
-              <td>
-                The `did:phk` method subsumes multiple blockchain ecosystems. Most
-                use the secp256r1 curve, but supporting the method broadly means
-                tolerating a variety of crypto algorithms that are not all
-                equally approved by Canada. None use the SM2 crypto system.
-                [<a href="#eval-2">eval-2</a>]
-              </td>
-            </tr>
-          </table>
-        </section>
-      </section>
 
-    </section> <!-- security -->
 
-    <section>
-      <h3>Privacy</h3>
-      <p>
-        Addresses the ability of a DID method to ensure various privacy
-        mechanisms. When DIDs are used as identifiers for people, it
-        becomes important to consider what tools a DID method offers to
-        operate at different levels of privacy. Use cases that focus on
-        IoT or institutions may not feel that this dimension is especially
-        important (though institutional privacy may sometimes be desirable).
-      </p>
 
-      <p>
-        Privacy tends to surface some interesting tradeoffs. For example, DID
-        methods that score very high in the "transparency" dimension may score
-        low in privacy, and vice versa.
-      </p>
+  <section id="criteria">
+    <h2>The criteria</h2>
 
-      <section>
-        <h4 id="criteria-33">Per-DID constraints on visibility</h4>
-        <a href="#criteria-33">https://www.w3.org/TR/did-rubric#criteria-33</a>
-        <section>
-          <h5>Question</h5>
-          <p>
-            What provisions are made for restricting visibility of DIDs to audiences
-            other than the general public?
-          </p>
-        </section>
-        <section>
-          <h5>Responses</h5>
-          <ol type="A">
-            <li>
-              Fully private is possible.
-            </li>
-            <li>
-              VDR is visible to "all", but "all" is a restricted audience with
-              enforced terms of service or other disincentives to abuse.
-            </li>
-            <li>
-              VDR is fully public with no constraints.
-            </li>
-          </ol>
-        </section>
-        <section>
-          <h5>Relevance</h5>
-          <p>
-            Restricting the audience for a DID is a way to discourage crawling
-            and secondary, possibly abusive publication. However, no mechanism
-            can completely prevent this; creating disincentives, accountability,
-            and/or costs that encourage the DID owner's wishes to be respected
-            is the best we can hope for.
-          </p>
-        </section>
-        <section>
-          <h5>Examples</h5>
-          <table class="simple">
-            <tr>
-              <th>Method</th>
-              <th>Score</th>
-              <th>Notes</th>
-            </tr>
-            <tr>
-              <td>
-                did:twit
-              </td>
-              <td>
-                C
-              </td>
-              <td>
-                A did:tweet is created and updated by posting to a public
-                twitter feed; it is always completely public.
-                [<a href="#eval-2">eval-2</a>]
-              </td>
-            </tr>
-            <tr>
-              <td>
-                did:key
-              </td>
-              <td>
-                A
-              </td>
-              <td>
-                Nothing about the did:key method requires it to be published
-                anywhere. It is as private or as public as the mechanism used
-                to share it.
-                [<a href="#eval-2">eval-2</a>]
-              </td>
-            </tr>
-            <tr>
-              <td>
-                did:trustbloc
-              </td>
-              <td>
-                B
-              </td>
-              <td>
-                A did:trustbloc is public to all users of the Hyperledger Fabric
-                instance where it is published -- but that blockchain may be
-                permissioned and restricted to a private audience.
-                [<a href="#eval-2">eval-2</a>]
-              </td>
-            </tr>
-          </table>
-        </section>
-      </section>
-      <section>
-        <h4 id="criteria-34">Cross-DID Leakage</h4>
-        <a href="#criteria-34">https://www.w3.org/TR/did-rubric#criteria-34</a>
-        <section>
-          <h5>Question</h5>
-          <p>
-            How possible is it to control multiple DIDs, without having an observer
-            of one DID be able to deduce that another DID has the same controller?
-          </p>
-        </section>
-        <section>
-          <h5>Responses</h5>
-          <ol type="A">
-            <li>
-              Each DID is entirely isolated; there is no practical way to infer
-              relationships of common control between them.
-            </li>
-            <li>
-              It may be possible to infer relationships of common control based on
-              timing and the IP address of clients, but not based on data persisted
-              in the VDR itself. Inference is expensive or impractical.
-            </li>
-            <li>
-              It is possible to infer relationships based on data persisted in the
-              VDR itself, and the inference is easy.
-            </li>
-          </ol>
-        </section>
-        <section>
-          <h5>Relevance</h5>
-          <p>
-            Inferring relationships between Bitcoin addresses allowed law enforcement
-            to track down the operators of Silk Road, even though those operators
-            believed they had privacy.
-          </p>
-        </section>
-        <section>
-          <h5>Examples</h5>
-          <table class="simple">
-            <tr>
-              <th>Method</th>
-              <th>Score</th>
-              <th>Notes</th>
-            </tr>
-            <tr>
-              <td>
-                did:pkh
-              </td>
-              <td>
-                B or C
-              </td>
-              <td>
-                Some of the blockchains used by did:pkh have Bitcoin-like traceability.
-                Others have Ethereum-like features, which include mixers or zkSNARKS/zkSTARKS.
-                However, none of them render a user completely anonymous.
-                [<a href="#eval-2">eval-2</a>]
-              </td>
-            </tr>
-            <tr>
-              <td>
-                did:keri
-              </td>
-              <td>
-                B
-              </td>
-              <td>
-                If a did:keri uses a blockchain as a witness, it may acquire some privacy
-                characteristics from that blockchain. However, did:keri in and of itself
-                is not easy to correlate.
-                [<a href="#eval-2">eval-2</a>]
-              </td>
-            </tr>
-          </table>
-        </section>
-      </section>
-      <section>
-        <h4 id="criteria-35">Incentives for Multicontext DIDs</h4>
-        <a href="#criteria-35">https://www.w3.org/TR/did-rubric#criteria-35</a>
-        <section>
-          <h5>Question</h5>
-          <p>
-            To what extent does the method incentivize (due to cost, hassle, etc.)
-            a DID to be reused in multiple contexts?
-          </p>
-        </section>
-        <section>
-          <h5>Responses</h5>
-          <ol type="A">
-            <li>
-              The natural and default behavior is to create a new DID in each new
-              context, and there is no meaningful incentive to do otherwise.
-            </li>
-            <li>
-              It is possible to create and manage numerous DIDs, but the latency,
-              complexity, or monetary expense of doing so results in modest
-              pressure to reuse a DID.
-            </li>
-            <li>
-              Each DID is expensive in at least one important dimension. Incentives to reuse are strong.
-            </li>
-          </ol>
-        </section>
-        <section>
-          <h5>Relevance</h5>
-          <p>
-            People will often trade away privacy for a low price or ease of use.
-            Methods that encourage this tradeoff are less optimal from a privacy
-            perspective, even if their privacy features are theoretically reasonable.
-          </p>
-        </section>
-        <section>
-          <h5>Examples</h5>
-          <table class="simple">
-            <tr>
-              <th>Method</th>
-              <th>Score</th>
-              <th>Notes</th>
-            </tr>
-            <tr>
-              <td>
-                did:btcr
-              </td>
-              <td>
-                C
-              </td>
-              <td>
-                At times when Bitcoin value has spiked, creating a DID on Bitcoin has
-                required an expensive transaction. Finality also takes a significant
-                amount of time. This creates incentives to reuse a DID in multiple
-                contexts.
-                [<a href="#eval-2">eval-2</a>]
-              </td>
-            </tr>
-            <tr>
-              <td>
-                did:sov
-              </td>
-              <td>
-                C
-              </td>
-              <td>
-                The Sovrin ledger deliberately charges for ledger writes to discourage
-                its use for privacy-oriented identifiers.
-                [<a href="#eval-2">eval-2</a>]
-              </td>
-            </tr>
-            <tr>
-              <td>
-                did:peer
-              </td>
-              <td>
-                A
-              </td>
-              <td>
-                Creating a peer DIDs is free and nearly instantaneous. There are no
-                incentives for reuse.
-                [<a href="#eval-2">eval-2</a>]
-              </td>
-            </tr>
-          </table>
-        </section>
-      </section>
-      <section>
-        <h4 id="criteria-36">Revocation of Consent</h4>
-        <a href="#criteria-36">https://www.w3.org/TR/did-rubric#criteria-36</a>
-        <section>
-          <h5>Question</h5>
-          <p>
-            How does one revoke consent for the storage of a DID? (Note how this
-            creates a tension with immutability, which may be valuable in 2.7.1
-            and elsewhere.)
-          </p>
-        </section>
-        <section>
-          <h5>Responses</h5>
-          <ol type="A">
-            <li>
-              The VDR fully supports removal of data that no longer has consent.
-              Once something is removed, nothing internal to the system allows
-              it to be recovered, and the system no longer qualifies as a
-              data controller.
-            </li>
-            <li>
-              The DID method only supports a current view, and the state of an
-              identifier in its VDR can be updated to a deleted or removed state.
-              Thus, the identifier ceases to resolve. However, a permanent record
-              of the previous state of the identifier remains, and could be used
-              to reconstruct historical data. The VDR thus remains a data
-              controller for deleted identifiers, at least in concept.
-            </li>
-            <li>
-              The DID method supports both current and previous views of an
-              identifier. While deletes are possible, the old state of an identifier
-              is a fully supported feature, so adding the identifier to the VDR is
-              irrevocable.
-            </li>
-          </ol>
-        </section>
-        <section>
-          <h5>Relevance</h5>
-          <p>
-            Some legal authorities may require that individuals have redress when
-            they are not satisfied with the actions of a data controller. This might
-            include but go beyond the so-called "right to be forgotten," encompassing
-            geographical or jurisdictional limitations, limits on processing, and
-            so forth. See
-            <a href="https://medium.com/berkman-klein-center/forget-erasure-why-blockchain-is-really-incompatible-with-the-gdpr-9f60374e90f3">
-              this legal analysis</a> for one view, but note that this is not a well
-            settled legal question.
-          </p>
-        </section>
-        <section>
-          <h5>Examples</h5>
-          <table class="simple">
-            <tr>
-              <th>Method</th>
-              <th>Score</th>
-              <th>Notes</th>
-            </tr>
-            <tr>
-              <td>
-                did:peer
-              </td>
-              <td>
-                A
-              </td>
-              <td>
-                A peer DID is designed to be shared only with the party that has
-                direct need to process it. That party is a single legal entity
-                that can be held responsible for their behavior. The peer DID
-                protocol includes a way to tell that party that the DID must be
-                deleted. Once deletion has occurred, nothing in the peer DID
-                mechanism preserves inappropriate data.
-                [<a href="#eval-2">eval-2</a>]
-              </td>
-            </tr>
-            <tr>
-              <td>
-                did:jlinc
-              </td>
-              <td>
-                B
-              </td>
-              <td>
-                The `did:jlinc` method supports deletion, and refuses to resolve
-                DIDs that have been deleted. It is also predicated on sophisticated
-                data-sharing agreements that can provide substantial protection for
-                individuals. However, it persists data to an immutable blockchain,
-                meaning that a deleted DID can be reconstructed outside the method,
-                using data that the method created.
-                [<a href="#eval-2">eval-2</a>]
-              </td>
-            </tr>
-          </table>
-        </section>
-      </section>
-    </section> <!-- privacy -->
 
-    <section>
-      <h3>Other criteria</h3>
-      <p>
-        We reviewed a lot of proposed criteria for inclusion in this
-        rubric. Not all of them turned out to be a good fit. We've
-        included a list of additional considered criteria in
-        <a href="#possible-additional-criteria"></a>.
-      </p>
-      <p>
-        We encourage everyone using this rubric to consider it as one tool
-        for evaluating DID Methods. Other <a>Evaluations</a> will also be
-        necessary to make a fully informed decision about adopting,
-        supporting, or contributing to any given Method.
-      </p>
-    </section> <!-- other criteria -->
   </section> <!-- criteria -->
   <section>
     <h2>Conclusion</h2>
diff --git a/rubric/criteria/1-open-contribution-participation.json b/rubric/criteria/1-open-contribution-participation.json
new file mode 100644
index 0000000..4888ed4
--- /dev/null
+++ b/rubric/criteria/1-open-contribution-participation.json
@@ -0,0 +1,89 @@
+{
+  "name": "Open contribution (participation)",
+  "id": "https://www.w3.org/TR/did-rubric#criteria-1",
+  "source": ".",
+  "version": "1.0.1",
+  "question": {
+    "question": "How open is participation in governance decisions?"
+  },
+  "response": {
+    "type": "multipleChoice",
+    "possibleResponses": [
+      {
+        "label": "A",
+        "meaning": "Anyone can participate in an open, fair process where all participants have equal opportunity to be heard and influence decisions."
+      },
+      {
+        "label": "B",
+        "meaning": "Anyone can comment and contribute to open debate, but decisions are ultimately made by a closed group."
+      },
+      {
+        "label": "C",
+        "meaning": "Debate is restricted to a selected but known group."
+      },
+      {
+        "label": "D",
+        "meaning": "Debate is conducted in secret by an unknown group."
+      }
+    ]
+  },
+  "relevance": "Governance determines how the rules of the underlying network are set and maintained. The more parties that are able to contribute to governance debates, the more decentralized the governance.",
+  "assessmentTemplate": {
+    "columns": [
+      {
+        "heading": "Method",
+        "type": "method",
+        "propertyRef": "method"
+      },
+      {
+        "heading": "Spec.",
+        "type": "enhancedLetter",
+        "propertyRef": "spec"
+      },
+      {
+        "heading": "Net.",
+        "type": "enhancedLetter",
+        "propertyRef": "net"
+      },
+      {
+        "heading": "Reg.",
+        "type": "enhancedLetter",
+        "propertyRef": "reg"
+      },
+      {
+        "heading": "Notes",
+        "type": "note",
+        "propertyRef": "note"
+      }
+    ]
+  },
+  "exampleAssessments": [
+    {
+      "id": "a-1",
+      "method": "did:web",
+      "spec": "A",
+      "net": "B",
+      "reg": "C/D",
+      "note": "Spec (A): Owned by CCG at W3C, anyone can join.\rNet (B): Most of the network is controlled by public or private entities.\nReg: Controlled by the Domain Holder, which is a restricted set (C) and in some cases may not be known to the resolving party (D).",
+      "evaluationCitation": "#eval-4"
+    },
+    {
+      "id": "a-2",
+      "method": "did:git",
+      "spec": "B",
+      "net": "C",
+      "reg": "D",
+      "evaluationCitation": "#eval-1",
+      "note": "The git network is the git source code, which is controlled (currently) by 16 people. They do not have a public issues process. The spec is openly developed on github by a listed set of contributors and issues may be raised by anyone. Each registry is controlled by potentially unknown parties as negotiated in \"meatspace\"."
+    },
+    {
+      "id": "a-3",
+      "method": "did:btcr",
+      "spec": "B",
+      "net": "D",
+      "reg": "D",
+      "evaluationCitation": "#eval-1",
+      "note": "Changes to the bitcoin protocol are chaotic and uncertain. They use BIPs, but the path to adoption is uncertain and the relative power of developers, miners, and users is open to debate. The spec is openly developed on github by a listed set of contributors and issues may be raised by anyone."
+    }
+  ]
+}
diff --git a/rubric/criteria/10-limited-resource-resolution.json b/rubric/criteria/10-limited-resource-resolution.json
new file mode 100644
index 0000000..3ffb813
--- /dev/null
+++ b/rubric/criteria/10-limited-resource-resolution.json
@@ -0,0 +1,105 @@
+{
+  "name": "Limited resource resolution",
+  "id": "https://www.w3.org/TR/did-rubric#criteria-10",
+  "source": ".",
+  "version": "1.0.0",
+  "question": {
+    "question": "How much memory is required for DID resolution, without relying on authoritative intermediaries (e.g. blockchain explorer APIs)? We consider the amount of memory required to fully resolve a DID of the method, whether that memory is stored locally or processed ephemerally via communications."
+  },
+  "response": {
+    "type": "multipleChoice",
+    "possibleResponses": [
+      {
+        "label": "A",
+        "meaning": "Minimal. Less than 1MB"
+      },
+      {
+        "label": "B",
+        "meaning": "Modest. 1MB to 1GB"
+      },
+      {
+        "label": "C",
+        "meaning": "Substantial. 1GB to 128 GB"
+      },
+      {
+        "label": "D",
+        "meaning": "Exceptional. Over 128GB in memory"
+      }
+    ]
+  },
+  "relevance": "Whether or not one can resolve a DID directly on a resource-constrained device affects the granularity at which smaller devices can be part of the ecosystem. If small edge devices, such as a smart watch, smart speaker, or even a mobile phone, are incapable of directly resolving a DID of the DID Method, then the method will lead to cloud-based services like blockchain explorer APIs, which themselves become a point of centralization. Many find this option an acceptable engineering trade-off. Others would prefer solutions that allow even the smallest devices to be fully capable of resolving DIDs in an authoritative manner.",
+  "assessmentTemplate": {
+    "columns": [
+      {
+        "heading": "Method",
+        "type": "method",
+        "propertyRef": "method"
+      },
+      {
+        "heading": "Net.",
+        "type": "enhancedLetter",
+        "propertyRef": "net"
+      },
+      {
+        "heading": "Reg.",
+        "type": "enhancedLetter",
+        "propertyRef": "reg"
+      },
+      {
+        "heading": "Notes",
+        "type": "note",
+        "propertyRef": "note"
+      }
+    ]
+  },
+  "exampleAssessments": [
+    {
+      "id": "a-49",
+      "method": "did:peer",
+      "net": "A",
+      "reg": "A",
+      "evaluationCitation": "#eval-2",
+      "note": "Resolution typically requires looking up a file in the file system, which uses minimal RAM."
+    },
+    {
+      "id": "a-50",
+      "method": "did:git",
+      "net": "B",
+      "reg": "varies",
+      "evaluationCitation": "#eval-1",
+      "note": "Git for Windows is just shy of 50 MB (please update if there are smaller versions available). However, one must still download the entire repo containing the registry material."
+    },
+    {
+      "id": "a-51",
+      "method": "did:btcr",
+      "net": "D",
+      "reg": "D",
+      "evaluationCitation": "#eval-1",
+      "note": "To definitively resolve, one must operate a full node."
+    },
+    {
+      "id": "a-52",
+      "method": "did:sov",
+      "net": "A",
+      "reg": "A",
+      "evaluationCitation": "#eval-1",
+      "note": "The Sovrin ledger is based on Hyperledger Indy which supports highly efficient state proofs for cryptographic verification of resolution responses. A full node is not required."
+    },
+    {
+      "id": "a-53",
+      "method": "did:ethr",
+      "net": "B",
+      "reg": "B",
+      "evaluationCitation": "#eval-1",
+      "note": "A full ethereum node takes >100GB, but a light ethereum node can support this method with less than 256kb."
+    },
+    {
+      "id": "a-54",
+      "method": "did:jolo",
+      "net": "B",
+      "reg": "B",
+      "evaluationCitation": "#eval-1",
+      "note": "A full ethereum node takes >100GB, but a light ethereum node can support this method with less than 256kb."
+    }
+  ]
+}
diff --git a/rubric/criteria/11-limited-resource-registration.json b/rubric/criteria/11-limited-resource-registration.json
new file mode 100644
index 0000000..c3919b6
--- /dev/null
+++ b/rubric/criteria/11-limited-resource-registration.json
@@ -0,0 +1,105 @@
+{
+  "name": "Limited resource registration",
+  "id": "https://www.w3.org/TR/did-rubric#criteria-11",
+  "source": ".",
+  "version": "1.0.0",
+  "question": {
+    "question": "What are the minimum resources required to create a trusted DID without relying on intermediaries?"
+  },
+  "response": {
+    "type": "multipleChoice",
+    "possibleResponses": [
+      {
+        "label": "A",
+        "meaning": "Minimal. Less than 1MB"
+      },
+      {
+        "label": "B",
+        "meaning": "Modest. 1MB to 1GB"
+      },
+      {
+        "label": "C",
+        "meaning": "Substantial. 1GB to 128 GB"
+      },
+      {
+        "label": "D",
+        "meaning": "Exceptional. Over 128GB in memory"
+      }
+    ]
+  },
+  "relevance": "Being able to create a DID in constrained situations enables certain types of decentralized applications that otherwise are not possible. On the edge, many devices rely on gateways to manage compute-, memory-, and bandwidth- intensive tasks. For example, while a smart lightbulb might use ZigBee or 6LowPAN, it will typically use a hub to connect to the Internet, even for access from devices within the local IP network. The more resources it takes for small devices to participate in registration, the greater the percentage of those that will need to rely on centralizing factors like hubs and gateways.",
+  "assessmentTemplate": {
+    "columns": [
+      {
+        "heading": "Method",
+        "type": "method",
+        "propertyRef": "method"
+      },
+      {
+        "heading": "Net.",
+        "type": "enhancedLetter",
+        "propertyRef": "net"
+      },
+      {
+        "heading": "Reg.",
+        "type": "enhancedLetter",
+        "propertyRef": "reg"
+      },
+      {
+        "heading": "Notes",
+        "type": "note",
+        "propertyRef": "note"
+      }
+    ]
+  },
+  "exampleAssessments": [
+    {
+      "id": "a-55",
+      "method": "did:peer",
+      "net": "A",
+      "reg": "A",
+      "evaluationCitation": "#eval-2",
+      "note": "Registration may require a few KB of RAM as a DID doc is written to disk."
+    },
+    {
+      "id": "a-56",
+      "method": "did:git",
+      "net": "B",
+      "reg": "varies",
+      "evaluationCitation": "#eval-1",
+      "note": "Git for Windows is just shy of 50 MB (please update if there are smaller versions available). However, one must still download the entire repo containing the registry material."
+    },
+    {
+      "id": "a-57",
+      "method": "did:btcr",
+      "net": "A-",
+      "reg": "A-",
+      "evaluationCitation": "#eval-1",
+      "note": "To register a DID, one must simply get a transaction on the ledger, unless you choose to host a continuation DID Document elsewhere, which would require its own resources."
+    },
+    {
+      "id": "a-58",
+      "method": "did:sov",
+      "net": "A",
+      "reg": "A",
+      "evaluationCitation": "#eval-1",
+      "note": "Registration of a DID is a single transaction that can be performed by a thin client."
+    },
+    {
+      "id": "a-59",
+      "method": "did:ethr",
+      "net": "A+",
+      "reg": "A+",
+      "evaluationCitation": "#eval-1",
+      "note": "The smart contract used for did:ethr recognizes any valid public key as a DID, without requiring registration. This means DIDs can even be created offline with full usability. Only rotation and the registration of service endpoints require network access."
+    },
+    {
+      "id": "a-60",
+      "method": "did:jolo",
+      "net": "A+",
+      "reg": "A+",
+      "evaluationCitation": "#eval-1",
+      "note": "The smart contract used for did:ethr recognizes any valid public key as a DID, without requiring registration. Only rotation and the registration of service endpoints require network access."
+    }
+  ]
+}
diff --git a/rubric/criteria/12-auditability.json b/rubric/criteria/12-auditability.json
new file mode 100644
index 0000000..4a1285d
--- /dev/null
+++ b/rubric/criteria/12-auditability.json
@@ -0,0 +1,73 @@
+{
+  "name": "Auditability",
+  "id": "https://www.w3.org/TR/did-rubric#criteria-12",
+  "source": ".",
+  "question": {
+    "question": "Who can retrieve cryptographic proof of the history of changes to a given DID Document?"
+  },
+  "response": {
+    "type": "multipleChoice",
+    "possibleResponses": [
+      {
+        "label": "A",
+        "meaning": "Anyone"
+      },
+      {
+        "label": "B",
+        "meaning": "Only a select group, including parties not involved in a given DID transaction"
+      },
+      {
+        "label": "C",
+        "meaning": "Only parties to the transaction"
+      },
+      {
+        "label": "D",
+        "meaning": "Not available"
+      }
+    ]
+  },
+  "relevance": "Trustlessness is a prerequisite of a decentralized system. If you have to trust the source of a DID Document (i.e., if you can’t verify cryptographically a DID Document that is returned from resolution), then you are at the mercy of a potentially centralized authority. If, instead, you have a cryptographic audit trail, then the current state of a DID cannot be compromised by an intermediary or central party.",
+  "assessmentTemplate": {
+    "columns": [
+      {
+        "heading": "Method",
+        "type": "method",
+        "propertyRef": "method"
+      },
+      {
+        "heading": "Reg.",
+        "type": "enhancedLetter",
+        "propertyRef": "reg"
+      },
+      {
+        "heading": "Notes",
+        "type": "note",
+        "propertyRef": "note"
+      }
+    ]
+  },
+  "version": "1.0.1",
+  "exampleAssessments": [
+    {
+      "id": "a-81",
+      "method": "did:btcr",
+      "reg": "A",
+      "evaluationCitation": "#eval-1",
+      "note": "Anyone can see everything."
+    },
+    {
+      "id": "a-82",
+      "method": "did:git",
+      "reg": "B-",
+      "evaluationCitation": "#eval-1",
+      "note": "If you have access to the authoritative git repo, you can see the cryptographic journal. However, within the method specification, there is no way to know if the repo you are inspecting is, in fact, definitive."
+    },
+    {
+      "id": "a-83",
+      "method": "did:web",
+      "reg": "D",
+      "note": "The web server hosting the DID Document has no requirement to preserve cryptographic history.",
+      "evaluationCitation": "#eval-4"
+    }
+  ]
+}
diff --git a/rubric/criteria/13-active-implementations.json b/rubric/criteria/13-active-implementations.json
new file mode 100644
index 0000000..1c9b220
--- /dev/null
+++ b/rubric/criteria/13-active-implementations.json
@@ -0,0 +1,13 @@
+{
+  "name": "Active implementations",
+  "id": "https://www.w3.org/TR/did-rubric#criteria-13",
+  "source": ".",
+  "version": "1.0.0",
+  "question": {
+    "question": "How many (active) substitutable, interoperable implementations support this Method?"
+  },
+  "response": {},
+  "relevance": "",
+  "assessmentTemplate": {},
+  "exampleAssessments": []
+}
diff --git a/rubric/criteria/14-market-share.json b/rubric/criteria/14-market-share.json
new file mode 100644
index 0000000..c3a2068
--- /dev/null
+++ b/rubric/criteria/14-market-share.json
@@ -0,0 +1,13 @@
+{
+  "name": "Market share",
+  "id": "https://www.w3.org/TR/did-rubric#criteria-14",
+  "source": ".",
+  "version": "1.0.0",
+  "question": {
+    "question": "How large is the share of use by each of the top three implementations?"
+  },
+  "response": {},
+  "relevance": "",
+  "assessmentTemplate": {},
+  "exampleAssessments": []
+}
diff --git a/rubric/criteria/15-platform-support.json b/rubric/criteria/15-platform-support.json
new file mode 100644
index 0000000..95e65c0
--- /dev/null
+++ b/rubric/criteria/15-platform-support.json
@@ -0,0 +1,13 @@
+{
+  "name": "Platform support",
+  "id": "https://www.w3.org/TR/did-rubric#criteria-15",
+  "source": ".",
+  "version": "1.0.0",
+  "question": {
+    "question": "Which platforms have implementations?"
+  },
+  "response": {},
+  "relevance": "",
+  "assessmentTemplate": {},
+  "exampleAssessments": []
+}
diff --git a/rubric/criteria/16-language-support.json b/rubric/criteria/16-language-support.json
new file mode 100644
index 0000000..6ce65df
--- /dev/null
+++ b/rubric/criteria/16-language-support.json
@@ -0,0 +1,13 @@
+{
+  "name": "Language support",
+  "id": "https://www.w3.org/TR/did-rubric#criteria-16",
+  "source": ".",
+  "version": "1.0.0",
+  "question": {
+    "question": "Which programming languages have implementations?"
+  },
+  "response": {},
+  "relevance": "",
+  "assessmentTemplate": {},
+  "exampleAssessments": []
+}
diff --git a/rubric/criteria/17-rogue-risk.json b/rubric/criteria/17-rogue-risk.json
new file mode 100644
index 0000000..bc257fc
--- /dev/null
+++ b/rubric/criteria/17-rogue-risk.json
@@ -0,0 +1,13 @@
+{
+  "name": "Rogue risk",
+  "id": "https://www.w3.org/TR/did-rubric#criteria-17",
+  "source": ".",
+  "version": "1.0.0",
+  "question": {
+    "question": "If there is one dominant implementation, how many programmers would need to be compromised to get a back-door into distribution?"
+  },
+  "response": {},
+  "relevance": "",
+  "assessmentTemplate": {},
+  "exampleAssessments": []
+}
diff --git a/rubric/criteria/18-forkability.json b/rubric/criteria/18-forkability.json
new file mode 100644
index 0000000..094ed0d
--- /dev/null
+++ b/rubric/criteria/18-forkability.json
@@ -0,0 +1,13 @@
+{
+  "name": "Forkability",
+  "id": "https://www.w3.org/TR/did-rubric#criteria-18",
+  "source": ".",
+  "version": "1.0.0",
+  "question": {
+    "question": "Is it forkable?"
+  },
+  "response": {},
+  "relevance": "",
+  "assessmentTemplate": {},
+  "exampleAssessments": []
+}
diff --git a/rubric/criteria/19-acceptance.json b/rubric/criteria/19-acceptance.json
new file mode 100644
index 0000000..919972b
--- /dev/null
+++ b/rubric/criteria/19-acceptance.json
@@ -0,0 +1,13 @@
+{
+  "name": "Acceptance",
+  "id": "https://www.w3.org/TR/did-rubric#criteria-19",
+  "source": ".",
+  "version": "1.0.0",
+  "question": {
+    "question": "How many relying parties accept DIDs of this Method?"
+  },
+  "response": {},
+  "relevance": "",
+  "assessmentTemplate": {},
+  "exampleAssessments": []
+}
diff --git a/rubric/criteria/2-transparency.json b/rubric/criteria/2-transparency.json
new file mode 100644
index 0000000..311c5df
--- /dev/null
+++ b/rubric/criteria/2-transparency.json
@@ -0,0 +1,92 @@
+{
+  "name": "Transparency",
+  "id": "https://www.w3.org/TR/did-rubric#criteria-2",
+  "source": ".",
+  "question": {
+    "question": "How visible are rulemaking processes?"
+  },
+  "response": {
+    "type": "multipleChoice",
+    "possibleResponses": [
+      {
+        "label": "A",
+        "meaning": "Agendas and participation details for all meetings are publicly announced, the meetings are broadcast in real-time to any listeners, and all minutes and recordings are captured in realtime and publicly reviewable in perpetuity."
+      },
+      {
+        "label": "B",
+        "meaning": "Minutes of meetings are reviewable by the public, including all votes and who cast them, but real-time observation may be limited."
+      },
+      {
+        "label": "C",
+        "meaning": "All current rules are publicly available."
+      },
+      {
+        "label": "D",
+        "meaning": "Rules may be changed without public notice."
+      }
+    ],
+    "possibleResponses[0]": {
+      "meaning": "Agendas and participation details for all governance discussions are publicly announced, any meetings are broadcast in real-time to any listeners, and all minutes and recordings are captured in realtime and publicly reviewable in perpetuity."
+    }
+  },
+  "relevance": "While participation measures active contribution, transparency measures the visibility of discussions affecting rule making. If such discussions are only visible to a limited group, it centralizes decision making in ways that Evaluators and users cannot easily see.",
+  "assessmentTemplate": {
+    "columns": [
+      {
+        "heading": "Method",
+        "type": "method",
+        "propertyRef": "method"
+      },
+      {
+        "heading": "Spec.",
+        "type": "enhancedLetter",
+        "propertyRef": "spec"
+      },
+      {
+        "heading": "Net.",
+        "type": "enhancedLetter",
+        "propertyRef": "net"
+      },
+      {
+        "heading": "Reg.",
+        "type": "enhancedLetter",
+        "propertyRef": "reg"
+      },
+      {
+        "heading": "Notes",
+        "type": "note",
+        "propertyRef": "note"
+      }
+    ]
+  },
+  "version": "1.0.1",
+  "exampleAssessments": [
+    {
+      "id": "a-4",
+      "method": "did:btcr",
+      "spec": "C",
+      "net": "C",
+      "reg": "C",
+      "evaluationCitation": "#eval-1",
+      "note": "The spec is maintained by volunteers, operating in an open fashion but without formal processes for announcements and meeting notes. The network and registry are bitcoin, which has a fairly public but messy innovation process, without formal meetings or votes."
+    },
+    {
+      "id": "a-5",
+      "method": "did:ion",
+      "spec": "A",
+      "net": "A-/A",
+      "reg": "A-/A",
+      "note": "Spec (A): method spec maintained by DIF, using open and transparent processes.\nNet (A-/A) and Reg (A-/A): It can be hard to track conversations about Bitcoin Improvement Proposals (BIPs) and decision processes differ for different BIPs, which can affect visibility (A-). IPFS has great support for realtime zoom participation and Notes(A)",
+      "evaluationCitation": "#eval-5"
+    },
+    {
+      "id": "a-6",
+      "method": "did:peer",
+      "spec": "C",
+      "net": "n/a",
+      "reg": "B",
+      "evaluationCitation": "#eval-1",
+      "note": "Rules for accepting changes to the business rules are bilaterally negotiated between the peers, subject to conformance with the specification."
+    }
+  ]
+}
diff --git a/rubric/criteria/20-users.json b/rubric/criteria/20-users.json
new file mode 100644
index 0000000..a3fb141
--- /dev/null
+++ b/rubric/criteria/20-users.json
@@ -0,0 +1,13 @@
+{
+  "name": "Users",
+  "id": "https://www.w3.org/TR/did-rubric#criteria-20",
+  "source": ".",
+  "version": "1.0.0",
+  "question": {
+    "question": "How many daily active users use this Method?"
+  },
+  "response": {},
+  "relevance": "",
+  "assessmentTemplate": {},
+  "exampleAssessments": []
+}
diff --git a/rubric/criteria/21-international-adoption.json b/rubric/criteria/21-international-adoption.json
new file mode 100644
index 0000000..1b232d3
--- /dev/null
+++ b/rubric/criteria/21-international-adoption.json
@@ -0,0 +1,13 @@
+{
+  "name": "International adoption",
+  "id": "https://www.w3.org/TR/did-rubric#criteria-21",
+  "source": ".",
+  "version": "1.0.0",
+  "question": {
+    "question": "How many different countries have significant usage?"
+  },
+  "response": {},
+  "relevance": "",
+  "assessmentTemplate": {},
+  "exampleAssessments": []
+}
diff --git a/rubric/criteria/22-in-which-countries.json b/rubric/criteria/22-in-which-countries.json
new file mode 100644
index 0000000..1c02a50
--- /dev/null
+++ b/rubric/criteria/22-in-which-countries.json
@@ -0,0 +1,13 @@
+{
+  "name": "In which countries?",
+  "id": "https://www.w3.org/TR/did-rubric#criteria-22",
+  "source": ".",
+  "version": "1.0.0",
+  "question": {
+    "question": "Which countries have significant usage?"
+  },
+  "response": {},
+  "relevance": "",
+  "assessmentTemplate": {},
+  "exampleAssessments": []
+}
diff --git a/rubric/criteria/23-language-support.json b/rubric/criteria/23-language-support.json
new file mode 100644
index 0000000..2bd6f15
--- /dev/null
+++ b/rubric/criteria/23-language-support.json
@@ -0,0 +1,13 @@
+{
+  "name": "Language support",
+  "id": "https://www.w3.org/TR/did-rubric#criteria-23",
+  "source": ".",
+  "version": "1.0.0",
+  "question": {
+    "question": "How many (human) languages are supported?"
+  },
+  "response": {},
+  "relevance": "",
+  "assessmentTemplate": {},
+  "exampleAssessments": []
+}
diff --git a/rubric/criteria/24-robust-crypto.json b/rubric/criteria/24-robust-crypto.json
new file mode 100644
index 0000000..e396a3b
--- /dev/null
+++ b/rubric/criteria/24-robust-crypto.json
@@ -0,0 +1,83 @@
+{
+  "name": "Robust Crypto",
+  "id": "https://www.w3.org/TR/did-rubric#criteria-24",
+  "source": ".",
+  "question": {
+    "question": "What is the lowest security level (“bits of security”) allowed in the processes that ensure integrity of the verifiable data registry?",
+    "instruction": "Evaluate the security level according to https://en.wikipedia.org/wiki/Security_level"
+  },
+  "response": {
+    "type": "multipleChoice",
+    "possibleResponses": [
+      {
+        "label": "A",
+        "meaning": "No combination of required features produces a profile with less than 256 bits of security."
+      },
+      {
+        "label": "B",
+        "meaning": "Between 128 and 256 bits. (Conventional wisdom — NIST recommendation — says that this level of security is adequate until the next revolutionary breakthrough.)"
+      },
+      {
+        "label": "C",
+        "meaning": "Less than 128 bits. (NIST recommends replacing this security by 2030.)"
+      },
+      {
+        "label": "D",
+        "meaning": "Less than 112 bits. (Security is obsolete today.)"
+      }
+    ],
+    "possibleResponses[1]": {
+      "meaning": "Between 128 and 256 bits"
+    },
+    "possibleResponses[2]": {
+      "meaning": "Less than 128 bits"
+    },
+    "possibleResponses[3]": {
+      "meaning": "Less than 64 bits"
+    }
+  },
+  "relevance": "A DID method that requires implementations to support something weak (e.g., 1024-bit RSA) is guaranteeing that its users will cooperate by default with encryption that's relatively easy to crack, with hashing that's not adequately collision-resistant, etc.",
+  "assessmentTemplate": {
+    "columns": [
+      {
+        "heading": "Method",
+        "type": "method",
+        "propertyRef": "method"
+      },
+      {
+        "heading": "Reg.",
+        "type": "enhancedLetter",
+        "propertyRef": "reg"
+      },
+      {
+        "heading": "Notes",
+        "type": "note",
+        "propertyRef": "note"
+      }
+    ]
+  },
+  "version": "2.0.0",
+  "exampleAssessments": [
+    {
+      "id": "a-74",
+      "method": "did:web",
+      "reg": "C",
+      "evaluationCitation": "#eval-2",
+      "note": "Although the DNS subsystem that supports did:web does not provide strong security, control of a DID is proved by accessing /.well-known over TLS. Thus, the security is tied to certificate config. Most web server certificates use 2048- bit RSA, which gives 112 bits of security."
+    },
+    {
+      "id": "a-75",
+      "method": "did:indy",
+      "reg": "B",
+      "evaluationCitation": "#eval-2",
+      "note": "Hashes are SHA2-256. Keys are Ed25519/Curve25519 (128 bits of security). Reads and writes to the Indy ledger use CurveZMQ rather than TLS. This gives 128 bits of security in the aggregate."
+    },
+    {
+      "id": "a-251",
+      "method": "did:ion",
+      "reg": "B-",
+      "note": "Secp256k1 theoretically guarantees 128 bit security. However, some theoretical attacks have shown a reduction of approximately 5 bits. (B-)",
+      "evaluationCitation": "#eval-5"
+    }
+  ]
+}
diff --git a/rubric/criteria/25-expert-review-cryptography.json b/rubric/criteria/25-expert-review-cryptography.json
new file mode 100644
index 0000000..5bc970c
--- /dev/null
+++ b/rubric/criteria/25-expert-review-cryptography.json
@@ -0,0 +1,84 @@
+{
+  "name": "Expert Review (Cryptography)",
+  "question": {
+    "question": "Does the system use cryptographic and security primitives that are well vetted by technical experts, and battle hardened in the school of experience?"
+  },
+  "assessmentTemplate": {
+    "columns": [
+      {
+        "heading": "Method",
+        "type": "method",
+        "propertyRef": "method"
+      },
+      {
+        "heading": "Reg.",
+        "type": "enhancedLetter",
+        "propertyRef": "reg"
+      },
+      {
+        "heading": "Notes",
+        "type": "note",
+        "propertyRef": "note"
+      }
+    ]
+  },
+  "source": ".",
+  "response": {
+    "type": "multipleChoice",
+    "possibleResponses": [
+      {
+        "label": "A",
+        "meaning": "Experts generally consider the system very secure, and this opinion is reinforced by a track record of secure production use."
+      },
+      {
+        "label": "B",
+        "meaning": "The theoretical security of the system looks excellent, and no known attacks or substantive criticisms are unaddressed. However, limited review or limited experience informs the opinion."
+      },
+      {
+        "label": "C",
+        "meaning": "Credible reports of vulnerabilities or design shortcomings have not been addressed."
+      },
+      {
+        "label": "D",
+        "meaning": "The system actively uses mechanisms that are officially deprecated."
+      },
+      {
+        "label": "E",
+        "meaning": "The system uses mechanisms that have not been vetted."
+      }
+    ]
+  },
+  "relevance": "Exotic crypto and other security mechanisms without expert review and a production track record is likely to contain hidden risks.",
+  "id": "https://www.w3.org/TR/did-rubric#criteria-25",
+  "version": "1.0.0",
+  "exampleAssessments": [
+    {
+      "id": "a-127",
+      "method": "did:v1.testnet",
+      "reg": "A",
+      "note": "Ed25519 and SHA256 are highly regarded cryptographic algorithms and are the only cryptographic primitives used in Veres One. (A)",
+      "evaluationCitation": "#eval-3"
+    },
+    {
+      "id": "a-128",
+      "method": "did:v1.production",
+      "reg": "A",
+      "note": "Ed25519 and SHA256 are highly regarded cryptographic algorithms and are the only cryptographic primitives used in Veres One. (A)",
+      "evaluationCitation": "#eval-3"
+    },
+    {
+      "id": "a-129",
+      "method": "did:web",
+      "reg": "A/E",
+      "note": "TLS/SSL (a requirement for did:web) is the most widespread adoption of cryptographic technology with well-tested, proven implementations (A). The method itself does not require any additional cryptographic primitives. The did:web method does inherit the known short-comings of DNS, which can be mitigated with DNSSec, in some cases. However, this is not a cryptographic problem. In addition, each webserver is free to use any authentication and authorization technique for creating, updating, and deactivating a DID and DID Document. The method relies on this layer to function, but the implementation of this layer may or may not use vetted cryptography (E).",
+      "evaluationCitation": "#eval-4"
+    },
+    {
+      "id": "a-130",
+      "method": "did:ion",
+      "reg": "A",
+      "note": "Bitcoin’s security has proven robust. (A)",
+      "evaluationCitation": "#eval-5"
+    }
+  ]
+}
diff --git a/rubric/criteria/28-availability.json b/rubric/criteria/28-availability.json
new file mode 100644
index 0000000..0595d5c
--- /dev/null
+++ b/rubric/criteria/28-availability.json
@@ -0,0 +1,69 @@
+{
+  "name": "Availability",
+  "id": "https://www.w3.org/TR/did-rubric#criteria-28",
+  "source": ".",
+  "question": {
+    "question": "How robust are protections against attempts to suppress information flow, whether legal (cease and desist) or technical (denial of service)?"
+  },
+  "response": {
+    "type": "multipleChoice",
+    "possibleResponses": [
+      {
+        "label": "A",
+        "meaning": "The VDR is practically immune from this risk."
+      },
+      {
+        "label": "B",
+        "meaning": "The VDR has reasonable protections in place. However, motivated and well resourced attackers could temporarily disrupt access in a targeted context."
+      },
+      {
+        "label": "C",
+        "meaning": "Attackers could permanently disrupt access in a targeted context."
+      }
+    ]
+  },
+  "relevance": "Control over an identifier is far less valuable if the propagation of that control can be limited by someone else.",
+  "assessmentTemplate": {
+    "columns": [
+      {
+        "heading": "Method",
+        "type": "method",
+        "propertyRef": "method"
+      },
+      {
+        "heading": "Reg.",
+        "type": "enhancedLetter",
+        "propertyRef": "reg"
+      },
+      {
+        "heading": "Notes",
+        "type": "note",
+        "propertyRef": "note"
+      }
+    ]
+  },
+  "version": "2.0.0",
+  "exampleAssessments": [
+    {
+      "id": "a-84",
+      "method": "did:btcr",
+      "reg": "A",
+      "evaluationCitation": "#eval-2",
+      "note": "The global bitcoin network has a strong track record of uptime , stretching back for well over a decade, even in the face of motivated attack."
+    },
+    {
+      "id": "a-261",
+      "method": "did:v1.production",
+      "reg": "B",
+      "note": "Veres One is operated by known parties; if all such parties are attacked, especially via legal means, the network could be shut down or additional rules applied. However, no single party can deny the consensus process. Like any publicly accessible service, Veres One is subject to distributed denial of service attacks. Counter measures are in place, but cannot be 100% ameliorated. (B)",
+      "evaluationCitation": "#eval-3"
+    },
+    {
+      "id": "a-262",
+      "method": "did:web",
+      "reg": "C",
+      "note": "There are a number of attack vectors for each layer in the system; however, each layer also has its own mechanisms for addressing disruption. (C)",
+      "evaluationCitation": "#eval-4"
+    }
+  ]
+}
diff --git a/rubric/criteria/29-provenance.json b/rubric/criteria/29-provenance.json
new file mode 100644
index 0000000..22a7e59
--- /dev/null
+++ b/rubric/criteria/29-provenance.json
@@ -0,0 +1,80 @@
+{
+  "name": "Provenance",
+  "question": {
+    "question": "Is the current state of a DID document provably correct from a history that's visible to anyone who can resolve the DID?"
+  },
+  "assessmentTemplate": {
+    "columns": [
+      {
+        "heading": "Method",
+        "type": "method",
+        "propertyRef": "method"
+      },
+      {
+        "heading": "Reg.",
+        "type": "enhancedLetter",
+        "propertyRef": "reg"
+      },
+      {
+        "heading": "Notes",
+        "type": "note",
+        "propertyRef": "note"
+      }
+    ]
+  },
+  "source": ".",
+  "response": {
+    "type": "multipleChoice",
+    "possibleResponses": [
+      {
+        "label": "A",
+        "meaning": "The update history of the DID document is recorded, accessible, and linked appropriately to its predecessor. Arbitrary versions can be queried and proved correct, and they have a reasonably useful timestamp."
+      },
+      {
+        "label": "B",
+        "meaning": "The update history of the DID document exists, and a forensic analysis could prove correctness. However, it's not exposed for consumption of ordinary resolvers, it lacks supporting metadata, or it's exposed in a very suboptimal way."
+      },
+      {
+        "label": "C",
+        "meaning": "Limited evidence of proper DID document updates exists."
+      },
+      {
+        "label": "D",
+        "meaning": "No evidence of proper DID document updates exist; the user has to trust the system's assertion that the current state resulted from something appropriate."
+      }
+    ]
+  },
+  "relevance": "It's possible to tamper with systems that don't actively prove the correctness of their current state. Such tampering is not easy to discover.",
+  "id": "https://www.w3.org/TR/did-rubric#criteria-29",
+  "version": "1.0.0",
+  "exampleAssessments": [
+    {
+      "id": "a-135",
+      "method": "did:v1.testnet",
+      "reg": "A",
+      "note": "All document updates are recorded in a non-repudiable manner on the Veres One Ledger.",
+      "evaluationCitation": "#eval-3"
+    },
+    {
+      "id": "a-136",
+      "method": "did:v1.production",
+      "reg": "A",
+      "note": "All document updates are recorded in a non-repudiable manner on the Veres One Ledger.",
+      "evaluationCitation": "#eval-3"
+    },
+    {
+      "id": "a-137",
+      "method": "did:web",
+      "reg": "D",
+      "note": "The method does not require the website serving the DID Document to demonstrate any form of provenance.",
+      "evaluationCitation": "#eval-4"
+    },
+    {
+      "id": "a-138",
+      "method": "did:ion",
+      "reg": "B",
+      "note": "As long as the IPFS-based transaction bundles are available (either via IPFS or somewhere else), the provenance of each DID Document is independently validatable. Similarly, if bitcoin state is lost, it would be impossible to verify the provenance of did:ion DID Documents. In both cases, it is relatively straightforward to address this by retaining your own copy of the state information, e.g., running your own bitcoin node and hosting the did:ion transaction bundles on your own IPFS node. In addition, late publishing https://identity.foundation/sidetree/spec/#late-publishing could allow multiple versions of DID Documents to be simultaneously seen as canonical.",
+      "evaluationCitation": "#eval-5"
+    }
+  ]
+}
diff --git a/rubric/criteria/30-many-eyes.json b/rubric/criteria/30-many-eyes.json
new file mode 100644
index 0000000..43e101b
--- /dev/null
+++ b/rubric/criteria/30-many-eyes.json
@@ -0,0 +1,66 @@
+{
+  "name": "Many Eyes",
+  "id": "https://www.w3.org/TR/did-rubric#criteria-30",
+  "source": ".",
+  "version": "1.0.0",
+  "question": {
+    "question": "Is the code of the method published, does it have many contributors, and does it have a published vulnerability reporting (responsible disclosure) mechanism?"
+  },
+  "response": {
+    "type": "multipleChoice",
+    "possibleResponses": [
+      {
+        "label": "A",
+        "meaning": "The code is public. It has hundreds of contributors. CVEs or similar reports have been published and handled appropriately."
+      },
+      {
+        "label": "B",
+        "meaning": "The code is public, but the list of contributors is small. No vulnerability reporting mechanism has been announced, or it's been announced but has no demonstrable track record."
+      },
+      {
+        "label": "C",
+        "meaning": "The code is partly private."
+      },
+      {
+        "label": "D",
+        "meaning": "The code is entirely private."
+      }
+    ]
+  },
+  "relevance": "Security vulnerabilities tend to be found and fixed best in code that has many active contributions and a strong history of correctly handled responsible disclosure.",
+  "assessmentTemplate": {
+    "columns": [
+      {
+        "heading": "Method",
+        "type": "method",
+        "propertyRef": "method"
+      },
+      {
+        "heading": "Score",
+        "type": "enhancedLetter",
+        "propertyRef": "score"
+      },
+      {
+        "heading": "Notes",
+        "type": "note",
+        "propertyRef": "note"
+      }
+    ]
+  },
+  "exampleAssessments": [
+    {
+      "id": "a-123",
+      "method": "did:sov",
+      "score": "A",
+      "evaluationCitation": "#eval-2",
+      "note": "The most prominent codebases that implement this method, github.com/hyperledger/indy-* have over 1000 forks, about 200 unique contributors from over a dozen organizations, spanning 5 years and about 25000 commits as of 2021. Sovrin's Technical Governance Board, which vets some aspects of the design, is composed of numerous independent experts, and meets regularly. Both Hyperledger and Sovrin Foundation have responsible disclosure mechanisms for vulnerabilities, and both have successfully handled vulnerabilities from initial report to patch and public disclosure."
+    },
+    {
+      "id": "a-124",
+      "method": "did:peer",
+      "score": "B",
+      "evaluationCitation": "#eval-2",
+      "note": "The spec and implementations of code are entirely public, with incubation through DIF's identifiers WG. However, contributors are limited to a dozen developers, activity is light, and there is no announced vulnerability mechanism."
+    }
+  ]
+}
diff --git a/rubric/criteria/31-diffuse-control.json b/rubric/criteria/31-diffuse-control.json
new file mode 100644
index 0000000..37d6e8f
--- /dev/null
+++ b/rubric/criteria/31-diffuse-control.json
@@ -0,0 +1,66 @@
+{
+  "name": "Diffuse Control",
+  "id": "https://www.w3.org/TR/did-rubric#criteria-31",
+  "source": ".",
+  "version": "1.0.0",
+  "question": {
+    "question": "To what extent does the system support mechanisms where DID control is distributed across multiple parties (m-of-n control, threshold signatures, etc.)?"
+  },
+  "response": {
+    "type": "multipleChoice",
+    "possibleResponses": [
+      {
+        "label": "A",
+        "meaning": "Rich diffuse control mechanisms are a first-class feature, and anyone who resolves a DID can see whether they are in use so confidence is increased. This may include device revocation (where keys must be exercised on a particular device to be valid)."
+      },
+      {
+        "label": "B",
+        "meaning": "Some diffuse control is possible but has important deficits in documentation, maturity, or visibility."
+      },
+      {
+        "label": "C",
+        "meaning": "Multiple parties can exercise control independently. Diffuse control is possible outside the system (e.g., using Shamir secret sharing to reconstitute a single key before updating a DID document). It's not possible to know whether such mechanisms are in use."
+      },
+      {
+        "label": "D",
+        "meaning": "Only a single party can exercise control at a time."
+      }
+    ]
+  },
+  "relevance": "Diffuse trust makes hacking harder and recovery more robust (but maybe more complex).",
+  "assessmentTemplate": {
+    "columns": [
+      {
+        "heading": "Method",
+        "type": "method",
+        "propertyRef": "method"
+      },
+      {
+        "heading": "Score",
+        "type": "enhancedLetter",
+        "propertyRef": "score"
+      },
+      {
+        "heading": "Notes",
+        "type": "note",
+        "propertyRef": "note"
+      }
+    ]
+  },
+  "exampleAssessments": [
+    {
+      "id": "a-125",
+      "method": "did:key",
+      "score": "C",
+      "evaluationCitation": "#eval-2",
+      "note": "did:key is controlled by a single key. If aggregate control is desired, these keys can be sharded, but that is outside the method's feature set."
+    },
+    {
+      "id": "a-126",
+      "method": "did:peer",
+      "score": "A",
+      "evaluationCitation": "#eval-2",
+      "note": "Dynamic peer DIDs explicitly define an m-of-n scheme that can be used to authorize any evolution of state, or any verification method supported by the DID."
+    }
+  ]
+}
diff --git a/rubric/criteria/33-per-did-constraints-on-visibility.json b/rubric/criteria/33-per-did-constraints-on-visibility.json
new file mode 100644
index 0000000..cdbcec5
--- /dev/null
+++ b/rubric/criteria/33-per-did-constraints-on-visibility.json
@@ -0,0 +1,69 @@
+{
+  "name": "Per-DID constraints on visibility",
+  "id": "https://www.w3.org/TR/did-rubric#criteria-33",
+  "source": ".",
+  "version": "1.0.0",
+  "question": {
+    "question": "What provisions are made for restricting visibility of DIDs to audiences other than the general public?"
+  },
+  "response": {
+    "type": "multipleChoice",
+    "possibleResponses": [
+      {
+        "label": "A",
+        "meaning": "Fully private is possible."
+      },
+      {
+        "label": "B",
+        "meaning": "VDR is visible to \"all\", but \"all\" is a restricted audience with enforced terms of service or other disincentives to abuse."
+      },
+      {
+        "label": "C",
+        "meaning": "VDR is fully public with no constraints."
+      }
+    ]
+  },
+  "relevance": "Restricting the audience for a DID is a way to discourage crawling and secondary, possibly abusive publication. However, no mechanism can completely prevent this; creating disincentives, accountability, and/or costs that encourage the DID owner's wishes to be respected is the best we can hope for.",
+  "assessmentTemplate": {
+    "columns": [
+      {
+        "heading": "Method",
+        "type": "method",
+        "propertyRef": "method"
+      },
+      {
+        "heading": "Score",
+        "type": "enhancedLetter",
+        "propertyRef": "score"
+      },
+      {
+        "heading": "Notes",
+        "type": "note",
+        "propertyRef": "note"
+      }
+    ]
+  },
+  "exampleAssessments": [
+    {
+      "id": "a-143",
+      "method": "did:twit",
+      "score": "C",
+      "evaluationCitation": "#eval-2",
+      "note": "A did:tweet is created and updated by posting to a public twitter feed; it is always completely public."
+    },
+    {
+      "id": "a-144",
+      "method": "did:key",
+      "score": "A",
+      "evaluationCitation": "#eval-2",
+      "note": "Nothing about the did:key method requires it to be published anywhere. It is as private or as public as the mechanism used to share it."
+    },
+    {
+      "id": "a-145",
+      "method": "did:trustbloc",
+      "score": "B",
+      "evaluationCitation": "#eval-2",
+      "note": "A did:trustbloc is public to all users of the Hyperledger Fabric instance where it is published -- but that blockchain may be permissioned and restricted to a private audience."
+    }
+  ]
+}
diff --git a/rubric/criteria/34-cross-did-leakage.json b/rubric/criteria/34-cross-did-leakage.json
new file mode 100644
index 0000000..3509b20
--- /dev/null
+++ b/rubric/criteria/34-cross-did-leakage.json
@@ -0,0 +1,62 @@
+{
+  "name": "Cross-DID Leakage",
+  "id": "https://www.w3.org/TR/did-rubric#criteria-34",
+  "source": ".",
+  "version": "1.0.0",
+  "question": {
+    "question": "How possible is it to control multiple DIDs, without having an observer of one DID be able to deduce that another DID has the same controller?"
+  },
+  "response": {
+    "type": "multipleChoice",
+    "possibleResponses": [
+      {
+        "label": "A",
+        "meaning": "Each DID is entirely isolated; there is no practical way to infer relationships of common control between them."
+      },
+      {
+        "label": "B",
+        "meaning": "It may be possible to infer relationships of common control based on timing and the IP address of clients, but not based on data persisted in the VDR itself. Inference is expensive or impractical."
+      },
+      {
+        "label": "C",
+        "meaning": "It is possible to infer relationships based on data persisted in the VDR itself, and the inference is easy."
+      }
+    ]
+  },
+  "relevance": "Inferring relationships between Bitcoin addresses allowed law enforcement to track down the operators of Silk Road, even though those operators believed they had privacy.",
+  "assessmentTemplate": {
+    "columns": [
+      {
+        "heading": "Method",
+        "type": "method",
+        "propertyRef": "method"
+      },
+      {
+        "heading": "Score",
+        "type": "enhancedLetter",
+        "propertyRef": "score"
+      },
+      {
+        "heading": "Notes",
+        "type": "note",
+        "propertyRef": "note"
+      }
+    ]
+  },
+  "exampleAssessments": [
+    {
+      "id": "a-146",
+      "method": "did:pkh",
+      "score": "B or C",
+      "evaluationCitation": "#eval-2",
+      "note": "Some of the blockchains used by did:pkh have Bitcoin-like traceability. Others have Ethereum-like features, which include mixers or zkSNARKS/zkSTARKS. However, none of them render a user completely anonymous."
+    },
+    {
+      "id": "a-147",
+      "method": "did:keri",
+      "score": "B",
+      "evaluationCitation": "#eval-2",
+      "note": "If a did:keri uses a blockchain as a witness, it may acquire some privacy characteristics from that blockchain. However, did:keri in and of itself is not easy to correlate."
+    }
+  ]
+}
diff --git a/rubric/criteria/35-incentives-for-multicontext-dids.json b/rubric/criteria/35-incentives-for-multicontext-dids.json
new file mode 100644
index 0000000..a8177d1
--- /dev/null
+++ b/rubric/criteria/35-incentives-for-multicontext-dids.json
@@ -0,0 +1,69 @@
+{
+  "name": "Incentives for Multicontext DIDs",
+  "id": "https://www.w3.org/TR/did-rubric#criteria-35",
+  "source": ".",
+  "version": "1.0.0",
+  "question": {
+    "question": "To what extent does the method incentivize (due to cost, hassle, etc.) a DID to be reused in multiple contexts?"
+  },
+  "response": {
+    "type": "multipleChoice",
+    "possibleResponses": [
+      {
+        "label": "A",
+        "meaning": "The natural and default behavior is to create a new DID in each new context, and there is no meaningful incentive to do otherwise."
+      },
+      {
+        "label": "B",
+        "meaning": "It is possible to create and manage numerous DIDs, but the latency, complexity, or monetary expense of doing so results in modest pressure to reuse a DID."
+      },
+      {
+        "label": "C",
+        "meaning": "Each DID is expensive in at least one important dimension. Incentives to reuse are strong."
+      }
+    ]
+  },
+  "relevance": "People will often trade away privacy for a low price or ease of use. Methods that encourage this tradeoff are less optimal from a privacy perspective, even if their privacy features are theoretically reasonable.",
+  "assessmentTemplate": {
+    "columns": [
+      {
+        "heading": "Method",
+        "type": "method",
+        "propertyRef": "method"
+      },
+      {
+        "heading": "Score",
+        "type": "enhancedLetter",
+        "propertyRef": "score"
+      },
+      {
+        "heading": "Notes",
+        "type": "note",
+        "propertyRef": "note"
+      }
+    ]
+  },
+  "exampleAssessments": [
+    {
+      "id": "a-148",
+      "method": "did:btcr",
+      "score": "C",
+      "evaluationCitation": "#eval-2",
+      "note": "At times when Bitcoin value has spiked, creating a DID on Bitcoin has required an expensive transaction. Finality also takes a significant amount of time. This creates incentives to reuse a DID in multiple contexts."
+    },
+    {
+      "id": "a-149",
+      "method": "did:sov",
+      "score": "C",
+      "evaluationCitation": "#eval-2",
+      "note": "The Sovrin ledger deliberately charges for ledger writes to discourage its use for privacy-oriented identifiers."
+    },
+    {
+      "id": "a-150",
+      "method": "did:peer",
+      "score": "A",
+      "evaluationCitation": "#eval-2",
+      "note": "Creating a peer DIDs is free and nearly instantaneous. There are no incentives for reuse."
+    }
+  ]
+}
diff --git a/rubric/criteria/36-revocation-of-consent.json b/rubric/criteria/36-revocation-of-consent.json
new file mode 100644
index 0000000..e9a4056
--- /dev/null
+++ b/rubric/criteria/36-revocation-of-consent.json
@@ -0,0 +1,62 @@
+{
+  "name": "Revocation of Consent",
+  "id": "https://www.w3.org/TR/did-rubric#criteria-36",
+  "source": ".",
+  "version": "1.0.0",
+  "question": {
+    "question": "How does one revoke consent for the storage of a DID? (Note how this creates a tension with immutability, which may be valuable in 2.7.1 and elsewhere.)"
+  },
+  "response": {
+    "type": "multipleChoice",
+    "possibleResponses": [
+      {
+        "label": "A",
+        "meaning": "The VDR fully supports removal of data that no longer has consent. Once something is removed, nothing internal to the system allows it to be recovered, and the system no longer qualifies as a data controller."
+      },
+      {
+        "label": "B",
+        "meaning": "The DID method only supports a current view, and the state of an identifier in its VDR can be updated to a deleted or removed state. Thus, the identifier ceases to resolve. However, a permanent record of the previous state of the identifier remains, and could be used to reconstruct historical data. The VDR thus remains a data controller for deleted identifiers, at least in concept."
+      },
+      {
+        "label": "C",
+        "meaning": "The DID method supports both current and previous views of an identifier. While deletes are possible, the old state of an identifier is a fully supported feature, so adding the identifier to the VDR is irrevocable."
+      }
+    ]
+  },
+  "relevance": "Some legal authorities may require that individuals have redress when they are not satisfied with the actions of a data controller. This might include but go beyond the so-called \"right to be forgotten,\" encompassing geographical or jurisdictional limitations, limits on processing, and so forth. Seethis legal analysisfor one view, but note that this is not a well settled legal question.",
+  "assessmentTemplate": {
+    "columns": [
+      {
+        "heading": "Method",
+        "type": "method",
+        "propertyRef": "method"
+      },
+      {
+        "heading": "Score",
+        "type": "enhancedLetter",
+        "propertyRef": "score"
+      },
+      {
+        "heading": "Notes",
+        "type": "note",
+        "propertyRef": "note"
+      }
+    ]
+  },
+  "exampleAssessments": [
+    {
+      "id": "a-151",
+      "method": "did:peer",
+      "score": "A",
+      "evaluationCitation": "#eval-2",
+      "note": "A peer DID is designed to be shared only with the party that has direct need to process it. That party is a single legal entity that can be held responsible for their behavior. The peer DID protocol includes a way to tell that party that the DID must be deleted. Once deletion has occurred, nothing in the peer DID mechanism preserves inappropriate data."
+    },
+    {
+      "id": "a-152",
+      "method": "did:jlinc",
+      "score": "B",
+      "evaluationCitation": "#eval-2",
+      "note": "The `did:jlinc` method supports deletion, and refuses to resolve DIDs that have been deleted. It is also predicated on sophisticated data-sharing agreements that can provide substantial protection for individuals. However, it persists data to an immutable blockchain, meaning that a deleted DID can be reconstructed outside the method, using data that the method created."
+    }
+  ]
+}
diff --git a/rubric/criteria/37-separation-of-power.json b/rubric/criteria/37-separation-of-power.json
new file mode 100644
index 0000000..9e5185b
--- /dev/null
+++ b/rubric/criteria/37-separation-of-power.json
@@ -0,0 +1,61 @@
+{
+  "name": "Separation of Power",
+  "question": {
+    "question": "What decision making bodies are involved in rulemaking?"
+  },
+  "assessmentTemplate": {
+    "columns": [
+      {
+        "heading": "Method",
+        "type": "method",
+        "propertyRef": "method"
+      },
+      {
+        "heading": "Decision Making Body",
+        "type": "enhancedLetter",
+        "propertyRef": "decision making body"
+      },
+      {
+        "heading": "Notes",
+        "type": "note",
+        "propertyRef": "note"
+      }
+    ]
+  },
+  "source": "https://didcriteria.com/criteria/1",
+  "response": {
+    "type": "multipleChoice",
+    "possibleResponses": [
+      {
+        "label": "A",
+        "meaning": "Rulemaking rarely occurs in simple structures. Identifying the different organizational entities that participate in setting rules allows evaluators to understand how rules get made. Understanding how rules get helps predict possible future developments."
+      }
+    ]
+  },
+  "relevance": "It is worth noting that all entities who are beholden to sovereign states, which is pretty much all corporations, non-profits, and individuals, have consequences for violating the laws, regulations, and lawful court orders within their jurisdiction. Some decentralized systems go to great lengths to minimize the impact of possible coercion, including actions by nation states. It is understood that any participant in the process may be subject to the rule of law from any number of jurisdictions, e.g., patent law, employment law, financial reporting laws, dumping laws, zoning, environmental regulations, etc. As a result, all decision making bodies are subject to the jurisdictions in which they operate.This complexity is true for all DID methods and, to our knowledge, most, if not all, DID methods have no intrinsic relationship to any particular jurisdiction. As such, we do not recommend including jurisdictional players, e.g., nation-states, cities, provinces, etc., as distinct operational layers, unless those players have a distinct role to play for that particular DID method.",
+  "id": "https://www.w3.org/TR/did-rubric#criteria-37",
+  "version": "1.0.0",
+  "exampleAssessments": [
+    {
+      "id": "a-7",
+      "method": "did:v1.testnet",
+      "decision making body": "Digital Bazaar",
+      "note": "Digital Bazaar created Veres One and is shepherding it through development to production.",
+      "evaluationCitation": "#eval-3"
+    },
+    {
+      "id": "a-8",
+      "method": "did:v1.production",
+      "decision making body": "Veres One Community Group",
+      "note": "In production, the Veres One Community Group is the public-facing decision making body designed for discussing technical matters.",
+      "evaluationCitation": "#eval-3"
+    },
+    {
+      "id": "a-9",
+      "method": "did:v1.production",
+      "decision making body": "Veres Foundation Board",
+      "note": "The Veres Foundation holds responsibility for the financial and legal decisions necessary to keep the network operational.",
+      "evaluationCitation": "#eval-3"
+    }
+  ]
+}
diff --git a/rubric/criteria/38-decision-making-structures.json b/rubric/criteria/38-decision-making-structures.json
new file mode 100644
index 0000000..25640d1
--- /dev/null
+++ b/rubric/criteria/38-decision-making-structures.json
@@ -0,0 +1,106 @@
+{
+  "name": "Decision Making Structures",
+  "question": {
+    "question": "How is each decision making body structured?",
+    "instruction": "Evaluate this criteria for each decision making body from https://www.w3.org/TR/did-rubric#criteria-37."
+  },
+  "assessmentTemplate": {
+    "columns": [
+      {
+        "heading": "Method",
+        "type": "method",
+        "propertyRef": "method"
+      },
+      {
+        "heading": "Decision Making Body",
+        "type": "enhancedLetter",
+        "propertyRef": "decision making body"
+      },
+      {
+        "heading": "Governance Structure",
+        "type": "enhancedLetter",
+        "propertyRef": "governance structure"
+      },
+      {
+        "heading": "Notes",
+        "type": "note",
+        "propertyRef": "note"
+      }
+    ]
+  },
+  "source": "https://didcriteria.com/criteria/2",
+  "response": {
+    "type": "multipleChoice",
+    "possibleResponses": [
+      {
+        "label": "A",
+        "meaning": "Individual. Sole proprietorship"
+      },
+      {
+        "label": "B",
+        "meaning": "Informal Group. Unincorporated Partnership / Open Community"
+      },
+      {
+        "label": "C",
+        "meaning": "For-profit formal organization. For-profit Corporation / LLC / Partnership"
+      },
+      {
+        "label": "D",
+        "meaning": "Quasi not-for-profit formal organization. B-Corp https://bcorporation.net/  / CIC https://en.wikipedia.org/wiki/Community_interest_company"
+      },
+      {
+        "label": "E",
+        "meaning": "Recognized not-for-profit formal organization. Not-for-profit public benefit organization (NGOs, 501c(3/4/6), etc)"
+      },
+      {
+        "label": "F",
+        "meaning": "NGO"
+      },
+      {
+        "label": "G",
+        "meaning": "Trade Association"
+      },
+      {
+        "label": "H",
+        "meaning": "Charity"
+      },
+      {
+        "label": "I",
+        "meaning": "Public agency (federal, state, or local)"
+      },
+      {
+        "label": "J",
+        "meaning": "Other"
+      }
+    ]
+  },
+  "relevance": "Different governance structures have different implications for how decisions are made and who wields influence throughout the process.",
+  "id": "https://www.w3.org/TR/did-rubric#criteria-38",
+  "version": "1.0.0",
+  "exampleAssessments": [
+    {
+      "id": "a-10",
+      "method": "did:v1.testnet",
+      "decision making body": "Digital Bazaar",
+      "governance structure": "C",
+      "note": "Digital Bazaar is a closely held startup with a seventeen year track record. (C)",
+      "evaluationCitation": "#eval-3"
+    },
+    {
+      "id": "a-11",
+      "method": "did:v1.production",
+      "decision making body": "Veres One Community Group",
+      "governance structure": "E",
+      "note": "The Veres One Community Group is a community group operating under the rules of the World Wide Web Consortium. Open to the public, self-elected leadership (E)",
+      "evaluationCitation": "#eval-3"
+    },
+    {
+      "id": "a-12",
+      "method": "did:v1.production",
+      "decision making body": "Veres Foundation Board",
+      "governance structure": "E",
+      "note": "The Veres Foundation operates under the non-profit regulations of Ontario, Canada. Self-propagating board of directors overseeing a non-profit organization. (E)",
+      "evaluationCitation": "#eval-3"
+    }
+  ]
+}
diff --git a/rubric/criteria/39-cost-to-introduce-rule-change.json b/rubric/criteria/39-cost-to-introduce-rule-change.json
new file mode 100644
index 0000000..a06d538
--- /dev/null
+++ b/rubric/criteria/39-cost-to-introduce-rule-change.json
@@ -0,0 +1,86 @@
+{
+  "name": "Cost to introduce rule change",
+  "question": {
+    "question": "How expensive is it to get a governance decision before each of the deliberating bodies?",
+    "instruction": "Evaluate this criteria for each decision making body from https://www.w3.org/TR/did-rubric#criteria-37."
+  },
+  "assessmentTemplate": {
+    "columns": [
+      {
+        "heading": "Method",
+        "type": "method",
+        "propertyRef": "method"
+      },
+      {
+        "heading": "Decision Making Body",
+        "type": "enhancedLetter",
+        "propertyRef": "decision making body"
+      },
+      {
+        "heading": "Cost",
+        "type": "enhancedLetter",
+        "propertyRef": "cost"
+      },
+      {
+        "heading": "Notes",
+        "type": "note",
+        "propertyRef": "note"
+      }
+    ]
+  },
+  "source": "https://didcriteria.com/criteria/3",
+  "response": {
+    "type": "multipleChoice",
+    "possibleResponses": [
+      {
+        "label": "A",
+        "meaning": "Free to all"
+      },
+      {
+        "label": "B",
+        "meaning": "Inexpensive, but accessible"
+      },
+      {
+        "label": "C",
+        "meaning": "Modest cost for interested parties"
+      },
+      {
+        "label": "D",
+        "meaning": "Expensive and restricted"
+      },
+      {
+        "label": "E",
+        "meaning": "Not possible to participate because the rules are immutable"
+      }
+    ]
+  },
+  "relevance": "Governance takes resources, which can limit the ability of interested parties to influence rulemaking. Generally, the more expensive it is to participate, the more governance centralizes to those parties most able to make the investment.",
+  "id": "https://www.w3.org/TR/did-rubric#criteria-39",
+  "version": "1.0.0",
+  "exampleAssessments": [
+    {
+      "id": "a-13",
+      "method": "did:v1.testnet",
+      "decision making body": "Digital Bazaar",
+      "cost": "D+",
+      "note": "Digital Bazaar is a small development team working with select customers to define Veres One. There is no explicit mechanism for outside participation, however, the governance framework has been developed with high transparency through github and the W3C Veres One Community Group. (D+)",
+      "evaluationCitation": "#eval-3"
+    },
+    {
+      "id": "a-14",
+      "method": "did:v1.production",
+      "decision making body": "Veres One Community Group",
+      "cost": "B",
+      "note": "Community group is open to the public. Any member of the community group can propose changes to the method. Group consensus then determines which proposals advance to the Veres Foundation. (B)",
+      "evaluationCitation": "#eval-3"
+    },
+    {
+      "id": "a-15",
+      "method": "did:v1.production",
+      "decision making body": "Veres Foundation Board",
+      "cost": "C-",
+      "note": "For technical decisions, the Foundation strongly prefers proposals to reach consensus in the community group. For operational, financial, and legal decisions, the board will likely reserve the right to make decisions independent of the community group. Board bylaws are under development as of this evaluation. (C-)",
+      "evaluationCitation": "#eval-3"
+    }
+  ]
+}
diff --git a/rubric/criteria/40-cost-to-decide-on-rule-changes.json b/rubric/criteria/40-cost-to-decide-on-rule-changes.json
new file mode 100644
index 0000000..818ed6b
--- /dev/null
+++ b/rubric/criteria/40-cost-to-decide-on-rule-changes.json
@@ -0,0 +1,86 @@
+{
+  "name": "Cost to decide on rule changes",
+  "question": {
+    "question": "How expensive is it to participate as a peer in a governance decision by the governing body?",
+    "instruction": "Evaluate this criteria for each decision making body from https://www.w3.org/TR/did-rubric#criteria-37."
+  },
+  "assessmentTemplate": {
+    "columns": [
+      {
+        "heading": "Method",
+        "type": "method",
+        "propertyRef": "method"
+      },
+      {
+        "heading": "Decision Making Body",
+        "type": "enhancedLetter",
+        "propertyRef": "decision making body"
+      },
+      {
+        "heading": "Cost",
+        "type": "enhancedLetter",
+        "propertyRef": "cost"
+      },
+      {
+        "heading": "Notes",
+        "type": "note",
+        "propertyRef": "note"
+      }
+    ]
+  },
+  "source": "https://didcriteria.com/criteria/4",
+  "response": {
+    "type": "multipleChoice",
+    "possibleResponses": [
+      {
+        "label": "A",
+        "meaning": "Free to all"
+      },
+      {
+        "label": "B",
+        "meaning": "Inexpensive, but accessible"
+      },
+      {
+        "label": "C",
+        "meaning": "Modest cost for interested parties"
+      },
+      {
+        "label": "D",
+        "meaning": "Expensive and restricted"
+      },
+      {
+        "label": "E",
+        "meaning": "Not possible to participate because the rules are immutable"
+      }
+    ]
+  },
+  "relevance": "Governance takes resources, which can limit the ability of interested parties to influence rulemaking. Generally, the more expensive it is to participate, the more governance centralizes to those parties most able to make the investment.",
+  "id": "https://www.w3.org/TR/did-rubric#criteria-40",
+  "version": "1.0.0",
+  "exampleAssessments": [
+    {
+      "id": "a-16",
+      "method": "did:v1.testnet",
+      "decision making body": "Digital Bazaar",
+      "cost": "D",
+      "note": "The most common way to be involved is by invitation from Digital Bazaar, either as an employee, subcontractor, or advisor. (D)",
+      "evaluationCitation": "#eval-3"
+    },
+    {
+      "id": "a-17",
+      "method": "did:v1.production",
+      "decision making body": "Veres One Community Group",
+      "cost": "B",
+      "note": "The largest cost is time to participate and a track record for credibility. (B)",
+      "evaluationCitation": "#eval-3"
+    },
+    {
+      "id": "a-18",
+      "method": "did:v1.production",
+      "decision making body": "Veres Foundation Board",
+      "cost": "D",
+      "note": "Foundation leadership is initially selected by Digital Bazaar and self-selecting thereafter. (D)",
+      "evaluationCitation": "#eval-3"
+    }
+  ]
+}
diff --git a/rubric/criteria/41-cryptocurrency.json b/rubric/criteria/41-cryptocurrency.json
new file mode 100644
index 0000000..e7edd8f
--- /dev/null
+++ b/rubric/criteria/41-cryptocurrency.json
@@ -0,0 +1,72 @@
+{
+  "name": "Cryptocurrency",
+  "question": {
+    "question": "What cryptocurrency, if any, is required for Method operations?"
+  },
+  "assessmentTemplate": {
+    "columns": [
+      {
+        "heading": "Method",
+        "type": "method",
+        "propertyRef": "method"
+      },
+      {
+        "heading": "Spec.",
+        "type": "enhancedLetter",
+        "propertyRef": "spec"
+      },
+      {
+        "heading": "Notes",
+        "type": "note",
+        "propertyRef": "note"
+      }
+    ]
+  },
+  "response": {
+    "type": "multipleChoice",
+    "possibleResponses": [
+      {
+        "label": "A",
+        "meaning": "None"
+      },
+      {
+        "label": "B",
+        "meaning": "At least one. [List the required crypto-currencies in the Notes]"
+      }
+    ]
+  },
+  "relevance": "The use of particular cryptocurrencies create a long term dependency on the viability of those currencies. Such dependency may be a deterrent for some applications. Similarly, if no cryptocurrency is used, there is likely a dependency elsewhere, such as on the organization managing consensus rules and operation.",
+  "id": "https://www.w3.org/TR/did-rubric#criteria-41",
+  "version": "1.0.0",
+  "source": "https://didcriteria.com/criteria/5",
+  "exampleAssessments": [
+    {
+      "id": "a-25",
+      "method": "did:v1.testnet",
+      "spec": "A",
+      "note": "Spec (A): The V1 DID Method operates on its own blockchain with a novel, non-cryptocurrency consensus algorithm.",
+      "evaluationCitation": "#eval-3"
+    },
+    {
+      "id": "a-26",
+      "method": "did:v1.production",
+      "spec": "A",
+      "note": "Spec (A): The V1 DID Method operates on its own blockchain with a novel, non-cryptocurrency consensus algorithm.",
+      "evaluationCitation": "#eval-3"
+    },
+    {
+      "id": "a-27",
+      "method": "did:web",
+      "spec": "A",
+      "note": "Spec (B): did:web, which is based on the World Wide Web and DNS does not rely on any cryptocurrency.",
+      "evaluationCitation": "#eval-4"
+    },
+    {
+      "id": "a-28",
+      "method": "did:ion",
+      "spec": "B",
+      "note": "Spec (B): One must use bitcoin. BTC is required for anchoring transactions. The IPFS layer does not require cryptocurrency, but the bitcoin layer is required for all operations.",
+      "evaluationCitation": "#eval-5"
+    }
+  ]
+}
diff --git a/rubric/criteria/42-offline-creation.json b/rubric/criteria/42-offline-creation.json
new file mode 100644
index 0000000..4dc47ba
--- /dev/null
+++ b/rubric/criteria/42-offline-creation.json
@@ -0,0 +1,80 @@
+{
+  "name": "Offline creation",
+  "question": {
+    "question": "Does the Method require network communications to create a DID?"
+  },
+  "assessmentTemplate": {
+    "columns": [
+      {
+        "heading": "Method",
+        "type": "method",
+        "propertyRef": "method"
+      },
+      {
+        "heading": "Spec.",
+        "type": "enhancedLetter",
+        "propertyRef": "spec"
+      },
+      {
+        "heading": "Notes",
+        "type": "note",
+        "propertyRef": "note"
+      }
+    ]
+  },
+  "response": {
+    "type": "multipleChoice",
+    "possibleResponses": [
+      {
+        "label": "A",
+        "meaning": "No. Creation is expected to be off-line. Only resolution, updates and deactivations require network or registry interaction"
+      },
+      {
+        "label": "B",
+        "meaning": "Yes. Creation requires network coordination with a single party to complete the DID creation"
+      },
+      {
+        "label": "C",
+        "meaning": "Yes. Creation requires network coordination with multiple parties in a known, constrained group to complete the DID creation"
+      },
+      {
+        "label": "D",
+        "meaning": "Yes. Creation requires network coordination with and acceptance by an open, global consensus system to complete DID creation"
+      }
+    ]
+  },
+  "relevance": "Communication is costly, with increasing costs the more parties are involved. This cost is not just in terms of the connection expense, but also the latency in processing transactions. The ability to create a DID without registering it on a global shared state greatly reduces the technical and financial cost of the method.",
+  "id": "https://www.w3.org/TR/did-rubric#criteria-42",
+  "version": "1.0.0",
+  "source": "https://didcriteria.com/criteria/7",
+  "exampleAssessments": [
+    {
+      "id": "a-29",
+      "method": "did:v1.testnet",
+      "spec": "A",
+      "note": "Veres One DID creation is a local cryptographic process. There is no network or registry involved.",
+      "evaluationCitation": "#eval-3"
+    },
+    {
+      "id": "a-30",
+      "method": "did:v1.production",
+      "spec": "A",
+      "note": "Veres One DID creation is a local cryptographic process. There is no network or registry involved.",
+      "evaluationCitation": "#eval-3"
+    },
+    {
+      "id": "a-31",
+      "method": "did:web",
+      "spec": "B+",
+      "note": "The DID controller must be able to communicate with the web server that is hosting the DID Document. However, in some configurations, this may not mean accessing the global network. For example, if you are physically present at the hosting server, one can create the DID Document files directly without network access. To resolve the DID Document those files must be published at an accessible endpoint, but creation doesn’t need the network.",
+      "evaluationCitation": "#eval-4"
+    },
+    {
+      "id": "a-32",
+      "method": "did:ion",
+      "spec": "A",
+      "note": "All new did:ions start offline. Only updates need to be published.",
+      "evaluationCitation": "#eval-5"
+    }
+  ]
+}
diff --git a/rubric/criteria/43-update-scalability.json b/rubric/criteria/43-update-scalability.json
new file mode 100644
index 0000000..8ccfb23
--- /dev/null
+++ b/rubric/criteria/43-update-scalability.json
@@ -0,0 +1,88 @@
+{
+  "name": "Update Scalability",
+  "question": {
+    "question": "Assuming an average of no more than 1 update per quarter, how many DIDs can this method support?"
+  },
+  "assessmentTemplate": {
+    "columns": [
+      {
+        "heading": "Method",
+        "type": "method",
+        "propertyRef": "method"
+      },
+      {
+        "heading": "Reg.",
+        "type": "enhancedLetter",
+        "propertyRef": "reg"
+      },
+      {
+        "heading": "Notes",
+        "type": "note",
+        "propertyRef": "note"
+      }
+    ]
+  },
+  "response": {
+    "type": "multipleChoice",
+    "possibleResponses": [
+      {
+        "label": "A",
+        "meaning": "Greater than 5 billion"
+      },
+      {
+        "label": "B",
+        "meaning": "Greater than 1 billion"
+      },
+      {
+        "label": "C",
+        "meaning": "Greater than 500 million"
+      },
+      {
+        "label": "D",
+        "meaning": "Greater than 50 million"
+      },
+      {
+        "label": "E",
+        "meaning": "Greater than 5 million"
+      },
+      {
+        "label": "F",
+        "meaning": "Less than 5 million"
+      }
+    ]
+  },
+  "relevance": "Some DID methods may be able to support the world's population, others may be more suitable to a particular type of use where only a small number of DIDs need to be supported. This gives a rough idea of the population base you may expect a particular DID method to support.",
+  "id": "https://www.w3.org/TR/did-rubric#criteria-43",
+  "version": "1.0.0",
+  "source": "https://didcriteria.com/criteria/8",
+  "exampleAssessments": [
+    {
+      "id": "a-33",
+      "method": "did:v1.testnet",
+      "reg": "C",
+      "note": "Veres One can handle ~750 million updates per quarter at the current architecture of 13 witnesses running stock amazon instances. Performance can be improved through a variety of approaches with different cost and engineering tradeoffs.",
+      "evaluationCitation": "#eval-3"
+    },
+    {
+      "id": "a-34",
+      "method": "did:v1.production",
+      "reg": "C",
+      "note": "Veres One can handle ~750 million updates per quarter at the current architecture of 13 witnesses running stock amazon instances. Performance can be improved through a variety of approaches with different cost and engineering tradeoffs.",
+      "evaluationCitation": "#eval-3"
+    },
+    {
+      "id": "a-35",
+      "method": "did:web",
+      "reg": "A",
+      "note": "did:web is a partitioned namespace where any given partition could support billions of DIDs. The URL behind the DID could be hosted by a small hosting service that can only handle a limited # of DIDs, but the hosting of a given domain could also be scaled arbitrarily.",
+      "evaluationCitation": "#eval-4"
+    },
+    {
+      "id": "a-36",
+      "method": "did:ion",
+      "reg": "A",
+      "note": "A single did:ion node, which limits its operations to 10,000 ops per transaction, is capable of anchoring ~131 million DIDs, updated every quarter. However, any number of did:ion nodes can independently anchor different did:ion operations, making the capacity effectively limited only by the blocksize of bitcoin (and the impact from other transactions competing for space in each block).",
+      "evaluationCitation": "#eval-5"
+    }
+  ]
+}
diff --git a/rubric/criteria/44-creation-cost.json b/rubric/criteria/44-creation-cost.json
new file mode 100644
index 0000000..7185dc4
--- /dev/null
+++ b/rubric/criteria/44-creation-cost.json
@@ -0,0 +1,88 @@
+{
+  "name": "Creation Cost",
+  "question": {
+    "question": "How much does it cost a DID creator to create a DID?"
+  },
+  "assessmentTemplate": {
+    "columns": [
+      {
+        "heading": "Method",
+        "type": "method",
+        "propertyRef": "method"
+      },
+      {
+        "heading": "Reg.",
+        "type": "enhancedLetter",
+        "propertyRef": "reg"
+      },
+      {
+        "heading": "Notes",
+        "type": "note",
+        "propertyRef": "note"
+      }
+    ]
+  },
+  "response": {
+    "type": "multipleChoice",
+    "possibleResponses": [
+      {
+        "label": "A",
+        "meaning": "Only operational costs of running the algorithm (no externalized expense)"
+      },
+      {
+        "label": "B",
+        "meaning": "Less than $0.01"
+      },
+      {
+        "label": "C",
+        "meaning": "Less than $0.10"
+      },
+      {
+        "label": "D",
+        "meaning": "Less than $1"
+      },
+      {
+        "label": "E",
+        "meaning": "Less than $10"
+      },
+      {
+        "label": "F",
+        "meaning": "$10 or greater"
+      }
+    ]
+  },
+  "relevance": "Almost all operations are sensitive to the cost of creating the underlying identifiers. If such costs are close to zero, broad use of ephemeral keys is possible. As costs increase, it becomes more and more necessary to limit the number of identifiers created in order to keep systems.",
+  "id": "https://www.w3.org/TR/did-rubric#criteria-44",
+  "version": "1.0.0",
+  "source": "https://didcriteria.com/criteria/9",
+  "exampleAssessments": [
+    {
+      "id": "a-37",
+      "method": "did:v1.testnet",
+      "reg": "A",
+      "note": "Creation is FREE",
+      "evaluationCitation": "#eval-3"
+    },
+    {
+      "id": "a-38",
+      "method": "did:v1.production",
+      "reg": "A",
+      "note": "Creation is FREE",
+      "evaluationCitation": "#eval-3"
+    },
+    {
+      "id": "a-39",
+      "method": "did:web",
+      "reg": "A",
+      "note": "Assuming you already have a hosting provider providing a website, this cost is essentially free. If you don’t, you may incur the cost of establishing a website (and perhaps a domain purchase or TLD application).",
+      "evaluationCitation": "#eval-4"
+    },
+    {
+      "id": "a-40",
+      "method": "did:ion",
+      "reg": "A",
+      "note": "Offline creation has no network costs, just local computation.",
+      "evaluationCitation": "#eval-5"
+    }
+  ]
+}
diff --git a/rubric/criteria/45-update-deletion-cost-out-of-pocket.json b/rubric/criteria/45-update-deletion-cost-out-of-pocket.json
new file mode 100644
index 0000000..ab42c11
--- /dev/null
+++ b/rubric/criteria/45-update-deletion-cost-out-of-pocket.json
@@ -0,0 +1,88 @@
+{
+  "name": "Update & Deletion Cost (Out-of-pocket)",
+  "question": {
+    "question": "How much does it cost*, out of pocket, to update or deactivate a DID Document? If the method has a tiered or variable cost structure, list all responses that apply and specify the cost structure in the Notes *This is the cost to the DID Document controller."
+  },
+  "assessmentTemplate": {
+    "columns": [
+      {
+        "heading": "Method",
+        "type": "method",
+        "propertyRef": "method"
+      },
+      {
+        "heading": "Reg.",
+        "type": "enhancedLetter",
+        "propertyRef": "reg"
+      },
+      {
+        "heading": "Notes",
+        "type": "note",
+        "propertyRef": "note"
+      }
+    ]
+  },
+  "response": {
+    "type": "multipleChoice",
+    "possibleResponses": [
+      {
+        "label": "A",
+        "meaning": "Only operational costs of running the algorithm (no externalized expense)"
+      },
+      {
+        "label": "B",
+        "meaning": "Less than $0.01"
+      },
+      {
+        "label": "C",
+        "meaning": "Less than $0.10"
+      },
+      {
+        "label": "D",
+        "meaning": "Less than $1"
+      },
+      {
+        "label": "E",
+        "meaning": "Less than $10"
+      },
+      {
+        "label": "F",
+        "meaning": "$10 or greater"
+      }
+    ]
+  },
+  "relevance": "Depending on the method and governance, the price of updating and deleting a DID Document will inform the cost of doing business with the particular method. Depending on the use case in mind this can be used, along with the scalability questions, to estimate the cost of maintaining a network using this DID method.",
+  "id": "https://www.w3.org/TR/did-rubric#criteria-45",
+  "version": "1.0.0",
+  "source": "https://didcriteria.com/criteria/10",
+  "exampleAssessments": [
+    {
+      "id": "a-41",
+      "method": "did:v1.testnet",
+      "reg": "n/a",
+      "note": "Veres One Test Net does not have pricing.",
+      "evaluationCitation": "#eval-3"
+    },
+    {
+      "id": "a-42",
+      "method": "did:v1.production",
+      "reg": "D/A",
+      "note": "Veres One updates target a retail cost of ~$0.25, which will be set based on operational costs of the Veres Foundation, for wholesale pricing. Accelerators may mark up these prices based on their business model and approach. The estimates for these costs are currently under evaluation. Prices will also vary based on the size of the update, with larger updates costing more. (D)\nThe costs and in-kind requirements will be managed by the Foundation based on market dynamics. (A)",
+      "evaluationCitation": "#eval-3"
+    },
+    {
+      "id": "a-43",
+      "method": "did:web",
+      "reg": "A",
+      "note": "Assuming you already have a hosting provider providing a website, this cost is essentially free. If you don’t, you may incur the cost of establishing a website (and perhaps a domain purchase or TLD application).",
+      "evaluationCitation": "#eval-4"
+    },
+    {
+      "id": "a-44",
+      "method": "did:ion",
+      "reg": "B/C",
+      "note": "Node operators who have staked ~$100,000 USD in BTC may update 10,000 DIDs in a single bitcoin transaction; at an average transaction fee of $3 (the current annualized average), that is $0.0003 per update. (B)\nNode operators who have not staked any BTC may update up to 100 DIDs in a single bitcoin transaction; at an average transaction fee of $3 (the current annualized average), that is $0.03 per update. (C)\nCost scales deterministically between these two ends of the price spectrum.",
+      "evaluationCitation": "#eval-5"
+    }
+  ]
+}
diff --git a/rubric/criteria/46-update-deletion-cost-in-kind.json b/rubric/criteria/46-update-deletion-cost-in-kind.json
new file mode 100644
index 0000000..9c56b84
--- /dev/null
+++ b/rubric/criteria/46-update-deletion-cost-in-kind.json
@@ -0,0 +1,88 @@
+{
+  "name": "Update & Deletion Cost (in-kind)",
+  "question": {
+    "question": "How much does it cost to update or deactivate a DID Document using in-kind contributions?"
+  },
+  "assessmentTemplate": {
+    "columns": [
+      {
+        "heading": "Method",
+        "type": "method",
+        "propertyRef": "method"
+      },
+      {
+        "heading": "Reg.",
+        "type": "enhancedLetter",
+        "propertyRef": "reg"
+      },
+      {
+        "heading": "Notes",
+        "type": "note",
+        "propertyRef": "note"
+      }
+    ]
+  },
+  "response": {
+    "type": "multipleChoice",
+    "possibleResponses": [
+      {
+        "label": "A",
+        "meaning": "Only operational costs of running the algorithm (no externalized expense)"
+      },
+      {
+        "label": "B",
+        "meaning": "Less than $0.01"
+      },
+      {
+        "label": "C",
+        "meaning": "Less than $0.10"
+      },
+      {
+        "label": "D",
+        "meaning": "Less than $1"
+      },
+      {
+        "label": "E",
+        "meaning": "Less than $10"
+      },
+      {
+        "label": "F",
+        "meaning": "$10 or greater"
+      }
+    ]
+  },
+  "relevance": "Depending on the method and governance, there may be ways of reducing (or removing) the cost of Updating or Deleting a DID Document, such as volunteering with the governance body or doing a set of work the network needs done.",
+  "id": "https://www.w3.org/TR/did-rubric#criteria-46",
+  "version": "1.0.0",
+  "source": "https://didcriteria.com/criteria/11",
+  "exampleAssessments": [
+    {
+      "id": "a-45",
+      "method": "did:v1.testnet",
+      "reg": "n/a",
+      "note": "Veres One Testnet does not have pricing.",
+      "evaluationCitation": "#eval-3"
+    },
+    {
+      "id": "a-46",
+      "method": "did:v1.production",
+      "reg": "B",
+      "note": "The Foundation-established cost can be earned by in-kind contributions, allowing hosted participants to post transactions without out-of-pocket expense. The amortized cost of this is expected to be less than “retail” but remain subject to several variables. For this evaluation, we estimate the in-kind costs for Veres One can be reduced to less than $0.01 per update, but ultimately this will be subject both to the Foundation’s in-kind rules as well as the marginal cost of satisfying those rules.",
+      "evaluationCitation": "#eval-3"
+    },
+    {
+      "id": "a-47",
+      "method": "did:web",
+      "reg": "n/a",
+      "note": "The method itself does not provide for in-kind contributions.",
+      "evaluationCitation": "#eval-4"
+    },
+    {
+      "id": "a-48",
+      "method": "did:ion",
+      "reg": "n/a",
+      "note": "The method does not provide for any kind of in-kind contributions. It is worth noting that some node operators are offering free updates to the public based on a modest Proof of Work.",
+      "evaluationCitation": "#eval-5"
+    }
+  ]
+}
diff --git a/rubric/criteria/47-transactional-performance-global-create-bandwidth.json b/rubric/criteria/47-transactional-performance-global-create-bandwidth.json
new file mode 100644
index 0000000..0db0fc7
--- /dev/null
+++ b/rubric/criteria/47-transactional-performance-global-create-bandwidth.json
@@ -0,0 +1,105 @@
+{
+  "name": "Transactional Performance - Global Create Bandwidth",
+  "question": {
+    "question": "How many DIDs of this method can be created per time period, globally?"
+  },
+  "assessmentTemplate": {
+    "columns": [
+      {
+        "heading": "Method",
+        "type": "method",
+        "propertyRef": "method"
+      },
+      {
+        "heading": "Net.",
+        "type": "enhancedLetter",
+        "propertyRef": "net"
+      },
+      {
+        "heading": "Reg.",
+        "type": "enhancedLetter",
+        "propertyRef": "reg"
+      },
+      {
+        "heading": "Notes",
+        "type": "note",
+        "propertyRef": "note"
+      }
+    ]
+  },
+  "response": {
+    "type": "multipleChoice",
+    "possibleResponses": [
+      {
+        "label": "A",
+        "meaning": "More than 1,000,000 Transactions Per Second"
+      },
+      {
+        "label": "B",
+        "meaning": "100,001 - 1,000,000 TPS"
+      },
+      {
+        "label": "C",
+        "meaning": "10,001 - 100,000 TPS"
+      },
+      {
+        "label": "D",
+        "meaning": "1,001 - 10,000 TPS"
+      },
+      {
+        "label": "E",
+        "meaning": "101 - 1,000 TPS"
+      },
+      {
+        "label": "F",
+        "meaning": "11 - 100 TPS"
+      },
+      {
+        "label": "G",
+        "meaning": "1-10 TPS"
+      },
+      {
+        "label": "H",
+        "meaning": "Less than 1 TPS"
+      }
+    ]
+  },
+  "relevance": "The number of new DIDs that can be created in a second inform the scalability of the network in regards to onboarding new users and allowing for new uses by existing users.",
+  "id": "https://www.w3.org/TR/did-rubric#criteria-47",
+  "version": "1.0.0",
+  "source": "https://didcriteria.com/criteria/13",
+  "exampleAssessments": [
+    {
+      "id": "a-61",
+      "method": "did:v1.testnet",
+      "net": "n/a",
+      "reg": "n/a",
+      "note": "Net (n/a) and Reg (n/a): Veres One DID creation is a local cryptographic process. There is no network or registry involved.",
+      "evaluationCitation": "#eval-3"
+    },
+    {
+      "id": "a-62",
+      "method": "did:v1.production",
+      "net": "n/a",
+      "reg": "n/a",
+      "note": "Net (n/a) and Reg (n/a): Veres One DID creation is a local cryptographic process. There is no network or registry involved.",
+      "evaluationCitation": "#eval-3"
+    },
+    {
+      "id": "a-63",
+      "method": "did:web",
+      "net": "A",
+      "reg": "A",
+      "note": "Net (A) and Reg (A): Architecturally, the World Wide Web can easily handle +1,000,000 transactions per second. Thanks to the way domain names can be routed to specific servers in a round-robin fashion, a given domain could, theoretically, reach 1,000,000 TPS. However, we know of no single domain currently engineered to handle that scale.",
+      "evaluationCitation": "#eval-4"
+    },
+    {
+      "id": "a-64",
+      "method": "did:ion",
+      "net": "n/a",
+      "reg": "n/a",
+      "note": "Net (n/a) and Reg (n/a): Creation is offline, so there is effectively no limit.",
+      "evaluationCitation": "#eval-5"
+    }
+  ]
+}
diff --git a/rubric/criteria/48-transactional-performance-global-update-bandwidth.json b/rubric/criteria/48-transactional-performance-global-update-bandwidth.json
new file mode 100644
index 0000000..6ee8c21
--- /dev/null
+++ b/rubric/criteria/48-transactional-performance-global-update-bandwidth.json
@@ -0,0 +1,88 @@
+{
+  "name": "Transactional Performance -- Global Update Bandwidth",
+  "question": {
+    "question": "How many DIDs can be updated per second, globally?"
+  },
+  "assessmentTemplate": {
+    "columns": [
+      {
+        "heading": "Method",
+        "type": "method",
+        "propertyRef": "method"
+      },
+      {
+        "heading": "Reg.",
+        "type": "enhancedLetter",
+        "propertyRef": "reg"
+      },
+      {
+        "heading": "Notes",
+        "type": "note",
+        "propertyRef": "note"
+      }
+    ]
+  },
+  "response": {
+    "type": "multipleChoice",
+    "possibleResponses": [
+      {
+        "label": "A",
+        "meaning": "More than 1,000,000 Transactions Per Second"
+      },
+      {
+        "label": "B",
+        "meaning": "10,001 - 1,000,000 TPS"
+      },
+      {
+        "label": "C",
+        "meaning": "101 - 10,000 TPS"
+      },
+      {
+        "label": "D",
+        "meaning": "11 - 100 TPS"
+      },
+      {
+        "label": "E",
+        "meaning": "1-10 TPS"
+      },
+      {
+        "label": "F",
+        "meaning": "Less than 1 TPS"
+      }
+    ]
+  },
+  "relevance": "Along with creation, update performance of the registry can inform as to how many users make use of the Method at any given time.",
+  "id": "https://www.w3.org/TR/did-rubric#criteria-48",
+  "version": "1.0.0",
+  "source": "https://didcriteria.com/criteria/14",
+  "exampleAssessments": [
+    {
+      "id": "a-65",
+      "method": "did:v1.testnet",
+      "reg": "C",
+      "note": "Updates on Veres One have been demonstrated at >100 TPS. This could go considerably higher with various technical trade-offs.",
+      "evaluationCitation": "#eval-3"
+    },
+    {
+      "id": "a-66",
+      "method": "did:v1.production",
+      "reg": "C",
+      "note": "Updates on Veres One have been demonstrated at >100 TPS. This could go considerably higher with various technical trade-offs.",
+      "evaluationCitation": "#eval-3"
+    },
+    {
+      "id": "a-67",
+      "method": "did:web",
+      "reg": "A",
+      "note": "DID:web update performance is highly sensitive to both implementation choices (http server, database, etc.) and network latency.",
+      "evaluationCitation": "#eval-4"
+    },
+    {
+      "id": "a-68",
+      "method": "did:ion",
+      "reg": "B",
+      "note": "Assuming 500 bytes per BTC tx, 1 MB block size, and 1 block per 10 minutes, if ALL transactions in a BTC block contain updates, there could be as many as 35,000 updates per second with did:ion.",
+      "evaluationCitation": "#eval-5"
+    }
+  ]
+}
diff --git a/rubric/criteria/49-update-latency.json b/rubric/criteria/49-update-latency.json
new file mode 100644
index 0000000..63429dd
--- /dev/null
+++ b/rubric/criteria/49-update-latency.json
@@ -0,0 +1,105 @@
+{
+  "name": "Update Latency",
+  "question": {
+    "question": "How much time does it take for an update to become globally available after submission by the DID controller?"
+  },
+  "assessmentTemplate": {
+    "columns": [
+      {
+        "heading": "Method",
+        "type": "method",
+        "propertyRef": "method"
+      },
+      {
+        "heading": "Net",
+        "type": "enhancedLetter",
+        "propertyRef": "net"
+      },
+      {
+        "heading": "Reg",
+        "type": "enhancedLetter",
+        "propertyRef": "reg"
+      },
+      {
+        "heading": "Notes",
+        "type": "note",
+        "propertyRef": "note"
+      }
+    ]
+  },
+  "response": {
+    "type": "multipleChoice",
+    "possibleResponses": [
+      {
+        "label": "A",
+        "meaning": "Less than 1 second"
+      },
+      {
+        "label": "B",
+        "meaning": "1 to < 60 seconds"
+      },
+      {
+        "label": "C",
+        "meaning": "1 to < 10 min"
+      },
+      {
+        "label": "D",
+        "meaning": "10 min to < 1 hour"
+      },
+      {
+        "label": "E",
+        "meaning": "1 hour to < 1 day"
+      },
+      {
+        "label": "F",
+        "meaning": "1 day to 2 weeks"
+      },
+      {
+        "label": "G",
+        "meaning": "Greater than two weeks"
+      },
+      {
+        "label": "H",
+        "meaning": "Updates not guaranteed"
+      }
+    ]
+  },
+  "relevance": "Different registry mechanisms have different guarantees for some notion of finality. The longer one has to wait for confirmation, the greater the latency for high security transactions. The shorter the duration, the more one has to critically validate the race conditions that may be present in determining finality. Depending on the algorithm, there are likely trade-offs between the stability of consensus and the speed at which consensus is pursued.",
+  "id": "https://www.w3.org/TR/did-rubric#criteria-49",
+  "version": "1.0.0",
+  "source": "https://didcriteria.com/criteria/15",
+  "exampleAssessments": [
+    {
+      "id": "a-69",
+      "method": "did:v1.testnet",
+      "net": "B",
+      "reg": "B",
+      "note": "Net (B) and Reg (B):Provable Finality for Veres One updates ranged from 1 to 60 seconds in testing (1-3 seconds in a single data center)",
+      "evaluationCitation": "#eval-3"
+    },
+    {
+      "id": "a-70",
+      "method": "did:v1.production",
+      "net": "B",
+      "reg": "B",
+      "note": "Net (B) and Reg (B):Provable Finality for Veres One updates ranged from 1 to 60 seconds in testing (1-3 seconds in a single data center)",
+      "evaluationCitation": "#eval-3"
+    },
+    {
+      "id": "a-71",
+      "method": "did:web",
+      "net": "B",
+      "reg": "B",
+      "note": "Net (B) and Reg (B): Depends on your network (and network configuration), but generally, did:web document updates are as fast as updates to any web resource.",
+      "evaluationCitation": "#eval-4"
+    },
+    {
+      "id": "a-72",
+      "method": "did:ion",
+      "net": "D/H",
+      "reg": "D/H",
+      "note": "Net and Reg:Updates to did:ion DIDs are ultimately anchored on BTC, which averages one block per every ten minutes. Some nodes may batch the BTC anchor operation, which could add to the delay, but this is not a requirement of the method. (D and D)\nSimilarly, due to the dynamically adjusting market for bitcoin transactions, it is possible for a controller to submit a transaction to the ION node and for it to go un-anchored because the ION node is not configured with a competitively priced bitcoin transaction fee. (H and H)",
+      "evaluationCitation": "#eval-5"
+    }
+  ]
+}
diff --git a/rubric/criteria/50-operational-reliability.json b/rubric/criteria/50-operational-reliability.json
new file mode 100644
index 0000000..d80aabd
--- /dev/null
+++ b/rubric/criteria/50-operational-reliability.json
@@ -0,0 +1,93 @@
+{
+  "name": "Operational Reliability",
+  "question": {
+    "question": "For each layer, how many operational components may be offline without that layer losing availability?"
+  },
+  "assessmentTemplate": {
+    "columns": [
+      {
+        "heading": "Method",
+        "type": "method",
+        "propertyRef": "method"
+      },
+      {
+        "heading": "Layer",
+        "type": "enhancedLetter",
+        "propertyRef": "layer"
+      },
+      {
+        "heading": "Response",
+        "type": "enhancedLetter",
+        "propertyRef": "response"
+      },
+      {
+        "heading": "Notes",
+        "type": "note",
+        "propertyRef": "note"
+      }
+    ]
+  },
+  "source": "https://didcriteria.com/criteria/16",
+  "response": {
+    "type": "multipleChoice",
+    "possibleResponses": [
+      {
+        "label": "A",
+        "meaning": "Equation based on the consensus algorithm"
+      },
+      {
+        "label": "B",
+        "meaning": "Known number"
+      },
+      {
+        "label": "C",
+        "meaning": "Percentage"
+      },
+      {
+        "label": "D",
+        "meaning": "NONE (specific components MUST be operational)"
+      },
+      {
+        "label": "E",
+        "meaning": "OPTIONAL (operations do not depend on the layer being available)"
+      }
+    ]
+  },
+  "relevance": "Along with the type of consensus algorithm the number of offline nodes has both security--i.e. DDOS attacks--and reliability implications.",
+  "id": "https://www.w3.org/TR/did-rubric#criteria-50",
+  "version": "1.0.0",
+  "exampleAssessments": [
+    {
+      "id": "a-73",
+      "method": "did:v1.testnet",
+      "layer": "Witnesses",
+      "response": "4",
+      "note": "The BFT consensus algorithm used by Veres One requires a supermajority of 9/13 witness nodes to formulate consensus.",
+      "evaluationCitation": "#eval-3"
+    },
+    {
+      "id": "a-74",
+      "method": "did:v1.testnet",
+      "layer": "Peers",
+      "response": "N/A",
+      "note": "Peer nodes are not needed in the formulation of consensus.",
+      "evaluationCitation": "#eval-3"
+    },
+    {
+      "id": "a-75",
+      "method": "did:v1.production",
+      "layer": "Witnesses",
+      "response": "4",
+      "note": "The BFT consensus algorithm used by Veres One requires a supermajority of 9/13 witness nodes to formulate consensus.",
+      "evaluationCitation": "#eval-3"
+    },
+    {
+      "id": "a-76",
+      "method": "did:v1.production",
+      "layer": "Peers",
+      "response": "N/A",
+      "note": "Peer nodes are not needed in the formulation of consensus.",
+      "evaluationCitation": "#eval-3"
+    }
+  ]
+}
diff --git a/rubric/criteria/51-operational-security.json b/rubric/criteria/51-operational-security.json
new file mode 100644
index 0000000..6fb1620
--- /dev/null
+++ b/rubric/criteria/51-operational-security.json
@@ -0,0 +1,93 @@
+{
+  "name": "Operational Security",
+  "question": {
+    "question": "How many operational components may be compromised without compromising the network?"
+  },
+  "assessmentTemplate": {
+    "columns": [
+      {
+        "heading": "Method",
+        "type": "method",
+        "propertyRef": "method"
+      },
+      {
+        "heading": "Layer",
+        "type": "enhancedLetter",
+        "propertyRef": "layer"
+      },
+      {
+        "heading": "Response",
+        "type": "enhancedLetter",
+        "propertyRef": "response"
+      },
+      {
+        "heading": "Notes",
+        "type": "note",
+        "propertyRef": "note"
+      }
+    ]
+  },
+  "source": "https://didcriteria.com/criteria/17",
+  "response": {
+    "type": "multipleChoice",
+    "possibleResponses": [
+      {
+        "label": "A",
+        "meaning": "Equation based on the consensus algorithm"
+      },
+      {
+        "label": "B",
+        "meaning": "Known number"
+      },
+      {
+        "label": "C",
+        "meaning": "Percentage"
+      },
+      {
+        "label": "D",
+        "meaning": "Unknown"
+      },
+      {
+        "label": "E",
+        "meaning": "N/A -- If the algorithm isn’t dependent on the particular layer"
+      }
+    ]
+  },
+  "relevance": "Informs how easy it may be to orchestrate a take over of the network and get false transactions accepted by the consensus mechanism.",
+  "id": "https://www.w3.org/TR/did-rubric#criteria-51",
+  "version": "1.0.0",
+  "exampleAssessments": [
+    {
+      "id": "a-77",
+      "method": "did:v1.testnet",
+      "layer": "Witnesses",
+      "response": "4",
+      "note": "Since a supermajority of 9/13 witness nodes is needed for consensus to be reached, compromising more than 4 of these nodes means an attacker could halt consensus formulation.",
+      "evaluationCitation": "#eval-3"
+    },
+    {
+      "id": "a-78",
+      "method": "did:v1.testnet",
+      "layer": "Peers",
+      "response": "N/A",
+      "note": "Peers being compromised does not lead to network failure.",
+      "evaluationCitation": "#eval-3"
+    },
+    {
+      "id": "a-79",
+      "method": "did:v1.production",
+      "layer": "Witnesses",
+      "response": "4",
+      "note": "Since a supermajority of 9/13 witness nodes is needed for consensus to be reached, compromising more than 4 of these nodes means an attacker could halt consensus formulation.",
+      "evaluationCitation": "#eval-3"
+    },
+    {
+      "id": "a-80",
+      "method": "did:v1.production",
+      "layer": "Peers",
+      "response": "N/A",
+      "note": "Peers being compromised does not lead to network failure.",
+      "evaluationCitation": "#eval-3"
+    }
+  ]
+}
diff --git a/rubric/criteria/52-governance-jurisdiction.json b/rubric/criteria/52-governance-jurisdiction.json
new file mode 100644
index 0000000..eead08b
--- /dev/null
+++ b/rubric/criteria/52-governance-jurisdiction.json
@@ -0,0 +1,53 @@
+{
+  "name": "Governance Jurisdiction",
+  "question": {
+    "question": "In which jurisdiction is the governing body located?"
+  },
+  "assessmentTemplate": {
+    "columns": [
+      {
+        "heading": "Method",
+        "type": "method",
+        "propertyRef": "method"
+      },
+      {
+        "heading": "Decision Making Body",
+        "type": "enhancedLetter",
+        "propertyRef": "decision making body"
+      },
+      {
+        "heading": "Notes",
+        "type": "note",
+        "propertyRef": "note"
+      }
+    ]
+  },
+  "source": "https://didcriteria.com/criteria/18",
+  "relevance": "Different jurisdictions have different laws which may affect the operation of the method.",
+  "response": {},
+  "id": "https://www.w3.org/TR/did-rubric#criteria-52",
+  "version": "1.0.0",
+  "exampleAssessments": [
+    {
+      "id": "a-84",
+      "method": "did:v1.testnet",
+      "decision making body": "Digital Bazaar, Inc.",
+      "note": "Digital Bazaar created Veres One. It is a corporation formed in the commonwealth of Virginia, USA.",
+      "evaluationCitation": "#eval-3"
+    },
+    {
+      "id": "a-85",
+      "method": "did:v1.production",
+      "decision making body": "Veres One Community Group",
+      "note": "In production, the Veres One Community Group is the public-facing decision making body designed for discussing technical matters. It operates under the auspices of the World Wide Web Consortium. The W3C does not have a single physical headquarters. There are four institutions that \"host\" W3C: MIT (in Cambridge, MA, USA), ERCIM (in Sophia-Antipolis, France), Keio University (near Tokyo, Japan), and Beihang University (in Beijing, China).",
+      "evaluationCitation": "#eval-3"
+    },
+    {
+      "id": "a-86",
+      "method": "did:v1.production",
+      "decision making body": "Veres Foundation Board",
+      "note": "The Veres Foundation holds responsibility for the financial and legal decisions necessary to keep the network operational. It is based in Ottawa, Canada.",
+      "evaluationCitation": "#eval-3"
+    }
+  ]
+}
diff --git a/rubric/criteria/53-operational-diversity.json b/rubric/criteria/53-operational-diversity.json
new file mode 100644
index 0000000..26c199a
--- /dev/null
+++ b/rubric/criteria/53-operational-diversity.json
@@ -0,0 +1,80 @@
+{
+  "name": "Operational Diversity",
+  "question": {
+    "question": "How many independent legal entities currently maintain the operational integrity of the Verifiable Data Registries?"
+  },
+  "assessmentTemplate": {
+    "columns": [
+      {
+        "heading": "Method",
+        "type": "method",
+        "propertyRef": "method"
+      },
+      {
+        "heading": "Reg.",
+        "type": "enhancedLetter",
+        "propertyRef": "reg"
+      },
+      {
+        "heading": "Notes",
+        "type": "note",
+        "propertyRef": "note"
+      }
+    ]
+  },
+  "response": {
+    "type": "multipleChoice",
+    "possibleResponses": [
+      {
+        "label": "A",
+        "meaning": "Open ended, unknown, or unknowable."
+      },
+      {
+        "label": "B",
+        "meaning": "Capped. [State lower and upper bounds in Notes]"
+      },
+      {
+        "label": "C",
+        "meaning": "One"
+      },
+      {
+        "label": "D",
+        "meaning": "Zero"
+      }
+    ]
+  },
+  "relevance": "Singular--or small numbers of--entities controlling the consensus of a network can orchestrate malicious attacks.",
+  "id": "https://www.w3.org/TR/did-rubric#criteria-53",
+  "version": "1.0.0",
+  "source": "https://didcriteria.com/criteria/19",
+  "exampleAssessments": [
+    {
+      "id": "a-87",
+      "method": "did:v1.testnet",
+      "reg": "B [13]",
+      "note": "Veres One is designed for 13 Witnesses; only Witnesses are able to approve updates to the chain. The propagation rules of the peer network restrict the ability for Witnesses to selectively approve transactions, but ultimately, the decision remains with a supermajority of nine Witnesses.",
+      "evaluationCitation": "#eval-3"
+    },
+    {
+      "id": "a-88",
+      "method": "did:v1.production",
+      "reg": "B [13]",
+      "note": "Veres One is designed for 13 Witnesses; only Witnesses are able to approve updates to the chain. The propagation rules of the peer network restrict the ability for Witnesses to selectively approve transactions, but ultimately, the decision remains with a supermajority of nine Witnesses.",
+      "evaluationCitation": "#eval-3"
+    },
+    {
+      "id": "a-89",
+      "method": "did:web",
+      "reg": "C",
+      "note": "Any of the layers could be compromised by that particular party.",
+      "evaluationCitation": "#eval-4"
+    },
+    {
+      "id": "a-90",
+      "method": "did:ion",
+      "reg": "A",
+      "note": "Bitcoin and IPFS allow any number of legal entities to participate in consensus.",
+      "evaluationCitation": "#eval-5"
+    }
+  ]
+}
diff --git a/rubric/criteria/54-registry-consensus.json b/rubric/criteria/54-registry-consensus.json
new file mode 100644
index 0000000..5e4abf6
--- /dev/null
+++ b/rubric/criteria/54-registry-consensus.json
@@ -0,0 +1,96 @@
+{
+  "name": "Registry Consensus",
+  "question": {
+    "question": "What type of integrity mechanism is used by the method’s Verifiable Data Registry?"
+  },
+  "assessmentTemplate": {
+    "columns": [
+      {
+        "heading": "Method",
+        "type": "method",
+        "propertyRef": "method"
+      },
+      {
+        "heading": "Reg.",
+        "type": "enhancedLetter",
+        "propertyRef": "reg"
+      },
+      {
+        "heading": "Notes",
+        "type": "note",
+        "propertyRef": "note"
+      }
+    ]
+  },
+  "response": {
+    "type": "multipleChoice",
+    "possibleResponses": [
+      {
+        "label": "A",
+        "meaning": "Proof of Work"
+      },
+      {
+        "label": "B",
+        "meaning": "Proof of Stake"
+      },
+      {
+        "label": "C",
+        "meaning": "BFT algorithm based"
+      },
+      {
+        "label": "D",
+        "meaning": "Electoral ‒ Select parties vote with thresholds"
+      },
+      {
+        "label": "E",
+        "meaning": "Unanimous ‒ All parties countersign"
+      },
+      {
+        "label": "F",
+        "meaning": "Unilateral ‒ Latest signed version defined as authentic"
+      },
+      {
+        "label": "G",
+        "meaning": "Standards-based specifications determined by institutional authority, used by anyone"
+      },
+      {
+        "label": "H",
+        "meaning": "Other ‒ Add your own"
+      }
+    ]
+  },
+  "relevance": "The consensus mechanism used by the method registry has implications for scalability, speed of operations, security and possibly environmental impact.",
+  "id": "https://www.w3.org/TR/did-rubric#criteria-54",
+  "version": "1.0.0",
+  "source": "https://didcriteria.com/criteria/20",
+  "exampleAssessments": [
+    {
+      "id": "a-91",
+      "method": "did:v1.testnet",
+      "reg": "C",
+      "note": "There Veres One registry consensus algorithm uses a BFT algorithm which formulates consensus through a super majority of witness nodes with any number of peer nodes allowed to participate in the gossip network.",
+      "evaluationCitation": "#eval-3"
+    },
+    {
+      "id": "a-92",
+      "method": "did:v1.production",
+      "reg": "C",
+      "note": "There Veres One registry consensus algorithm uses a BFT algorithm which formulates consensus through a super majority of 13 witness nodes with any number of peer nodes allowed to participate in the gossip network.",
+      "evaluationCitation": "#eval-3"
+    },
+    {
+      "id": "a-93",
+      "method": "did:web",
+      "reg": "F/G",
+      "note": "ICANN sets the specification for consensus (F). DNS works by participants agreeing that ICANN’s rules determine global state.",
+      "evaluationCitation": "#eval-4"
+    },
+    {
+      "id": "a-94",
+      "method": "did:ion",
+      "reg": "A",
+      "note": "The VDR for did:ion is Bitcoin, which is Proof of Work",
+      "evaluationCitation": "#eval-5"
+    }
+  ]
+}
diff --git a/rubric/criteria/55-operational-layers.json b/rubric/criteria/55-operational-layers.json
new file mode 100644
index 0000000..3220377
--- /dev/null
+++ b/rubric/criteria/55-operational-layers.json
@@ -0,0 +1,69 @@
+{
+  "name": "Operational Layers",
+  "question": {
+    "question": "What layers of operational components establish and maintain integrity of the Verifiable Data Registry?",
+    "instruction": "For each layer, evaluate criteria https://www.w3.org/TR/did-rubric#criteria-50, https://www.w3.org/TR/did-rubric#criteria-51, and https://www.w3.org/TR/did-rubric#criteria-56."
+  },
+  "assessmentTemplate": {
+    "columns": [
+      {
+        "heading": "Method",
+        "type": "method",
+        "propertyRef": "method"
+      },
+      {
+        "heading": "Layer",
+        "type": "enhancedLetter",
+        "propertyRef": "layer"
+      },
+      {
+        "heading": "Notes",
+        "type": "note",
+        "propertyRef": "note"
+      }
+    ]
+  },
+  "response": {
+    "type": "multipleChoice",
+    "possibleResponses": [
+      {
+        "label": "A",
+        "meaning": "List each layer"
+      }
+    ]
+  },
+  "relevance": "The manner in which a Verifiable Data Registry (VDR) manages integrity defines how that integrity might be compromised. To understand how the VDR of a given Method maintains integrity, this criteria identifies the operational components of the VDR for further evaluation in other criteria, namely https://www.w3.org/TR/did-rubric#criteria-50, https://www.w3.org/TR/did-rubric#criteria-51, and https://www.w3.org/TR/did-rubric#criteria-56. Unfortunately, network topology inevitably introduces parties that may be able to disrupt or compromise network interactions. For example, DNS servers--often under the control of the user’s ISP or the corporate IT department--can return “fake” IP addresses; corporate firewalls can prevent traffic to or from certain addresses; corporate system administrators may prevent users from configuring alternative Certificate Authorities, even international internet traffic can be restricted or denied, purely at the network layer.Because nearly every DID method known at this point depends on Internet-based networking, every DID method faces these same problems. As such, we don’t recommend specifying common network components as distinct layers unless those layers have specific roles unique to the particular DID method.For this criteria, we are talking about the operational components that have specific, unique, or privileged roles with regard to the evaluated DID Method(s). The parties which fulfill said roles should be considered when evaluating the fitness of the given method(s).",
+  "id": "https://www.w3.org/TR/did-rubric#criteria-55",
+  "version": "1.0.0",
+  "source": "https://didcriteria.com/criteria/21",
+  "exampleAssessments": [
+    {
+      "id": "a-95",
+      "method": "did:v1.testnet",
+      "layer": "Witnesses",
+      "note": "In the test net the number of peer nodes is limited but the same number of witness nodes are used as in production.",
+      "evaluationCitation": "#eval-3"
+    },
+    {
+      "id": "a-96",
+      "method": "did:v1.testnet",
+      "layer": "Peers",
+      "note": "",
+      "evaluationCitation": "#eval-3"
+    },
+    {
+      "id": "a-97",
+      "method": "did:v1.production",
+      "layer": "Witnesses",
+      "note": "In production the number of peer nodes is expected to increase greatly.",
+      "evaluationCitation": "#eval-3"
+    },
+    {
+      "id": "a-98",
+      "method": "did:v1.production",
+      "layer": "Peers",
+      "note": "",
+      "evaluationCitation": "#eval-3"
+    }
+  ]
+}
diff --git a/rubric/criteria/56-layer-diversity.json b/rubric/criteria/56-layer-diversity.json
new file mode 100644
index 0000000..d61c8c2
--- /dev/null
+++ b/rubric/criteria/56-layer-diversity.json
@@ -0,0 +1,85 @@
+{
+  "name": "Layer Diversity",
+  "question": {
+    "question": "How many operational components need to be compromised to compromise the verifiable data registry (evaluate for each operational component)?"
+  },
+  "assessmentTemplate": {
+    "columns": [
+      {
+        "heading": "Method",
+        "type": "method",
+        "propertyRef": "method"
+      },
+      {
+        "heading": "Layer",
+        "type": "enhancedLetter",
+        "propertyRef": "layer"
+      },
+      {
+        "heading": "Response",
+        "type": "enhancedLetter",
+        "propertyRef": "response"
+      },
+      {
+        "heading": "Notes",
+        "type": "note",
+        "propertyRef": "note"
+      }
+    ]
+  },
+  "source": "https://didcriteria.com/criteria/22",
+  "response": {
+    "type": "multipleChoice",
+    "possibleResponses": [
+      {
+        "label": "A",
+        "meaning": "Open ended, unknown, or unknowable."
+      },
+      {
+        "label": "B",
+        "meaning": "Capped. [State upper and lower bounds in Notes]"
+      },
+      {
+        "label": "C",
+        "meaning": "One"
+      }
+    ]
+  },
+  "relevance": "Along with the type of consensus algorithm, the number of nodes that can participate in consensus has implications towards network security and reliability.",
+  "id": "https://www.w3.org/TR/did-rubric#criteria-56",
+  "version": "1.0.0",
+  "exampleAssessments": [
+    {
+      "id": "a-99",
+      "method": "did:v1.testnet",
+      "layer": "Witnesses",
+      "response": "B [4]",
+      "note": "Veres One’s consensus requires 9 of 13 Witness nodes to agree, as such if more than 4 were compromised the network may cease to function. (B)",
+      "evaluationCitation": "#eval-3"
+    },
+    {
+      "id": "a-100",
+      "method": "did:v1.testnet",
+      "layer": "Peers",
+      "response": "A",
+      "note": "Peer nodes are not directly involved in maintaining the verifiable data registry and only propagate state. As such compromising any number of Peer nodes does not compromise the network. (A)",
+      "evaluationCitation": "#eval-3"
+    },
+    {
+      "id": "a-101",
+      "method": "did:v1.production",
+      "layer": "Witnesses",
+      "response": "B [4]",
+      "note": "Veres One’s consensus requires 9 of 13 Witness nodes to agree, as such if more than 4 were compromised the network may cease to function. (B)",
+      "evaluationCitation": "#eval-3"
+    },
+    {
+      "id": "a-102",
+      "method": "did:v1.production",
+      "layer": "Peers",
+      "response": "A",
+      "note": "Peer nodes are not directly involved in maintaining the verifiable data registry and only propagate state. As such compromising any number of Peer nodes does not compromise the network. (A)",
+      "evaluationCitation": "#eval-3"
+    }
+  ]
+}
diff --git a/rubric/criteria/57-verification-relationships.json b/rubric/criteria/57-verification-relationships.json
new file mode 100644
index 0000000..f05b81d
--- /dev/null
+++ b/rubric/criteria/57-verification-relationships.json
@@ -0,0 +1,96 @@
+{
+  "name": "Verification Relationships",
+  "question": {
+    "question": "What verification relationships are supported by the method per specification?"
+  },
+  "assessmentTemplate": {
+    "columns": [
+      {
+        "heading": "Method",
+        "type": "method",
+        "propertyRef": "method"
+      },
+      {
+        "heading": "Spec.",
+        "type": "enhancedLetter",
+        "propertyRef": "spec"
+      },
+      {
+        "heading": "Notes",
+        "type": "note",
+        "propertyRef": "note"
+      }
+    ]
+  },
+  "response": {
+    "type": "multipleChoice",
+    "possibleResponses": [
+      {
+        "label": "A",
+        "meaning": "None"
+      },
+      {
+        "label": "B",
+        "meaning": "Authentication"
+      },
+      {
+        "label": "C",
+        "meaning": "AssertionMethod"
+      },
+      {
+        "label": "D",
+        "meaning": "Key Agreement"
+      },
+      {
+        "label": "E",
+        "meaning": "CapabilityInvocation"
+      },
+      {
+        "label": "F",
+        "meaning": "CapabilityDelegation"
+      },
+      {
+        "label": "G",
+        "meaning": "Other"
+      },
+      {
+        "label": "H",
+        "meaning": "Any"
+      }
+    ]
+  },
+  "relevance": "The verification relationships a method supports inform the ways in which DIDs of the method can be used. See section 5.3 of the DID-Core specification for details on verification relationships. https://www.w3.org/TR/did-core/#verification-relationships",
+  "id": "https://www.w3.org/TR/did-rubric#criteria-57",
+  "version": "1.0.0",
+  "source": "https://didcriteria.com/criteria/23",
+  "exampleAssessments": [
+    {
+      "id": "a-103",
+      "method": "did:v1.testnet",
+      "spec": "H",
+      "note": "The did.v1 specification does not have any restrictions to the Verification Relationships supported.",
+      "evaluationCitation": "#eval-3"
+    },
+    {
+      "id": "a-104",
+      "method": "did:v1.production",
+      "spec": "H",
+      "note": "The did.v1 specification does not have any restrictions to the Verification Relationships supported.",
+      "evaluationCitation": "#eval-3"
+    },
+    {
+      "id": "a-105",
+      "method": "did:web",
+      "spec": "H",
+      "note": "The did:web specification does not restrict Verification Relationships.",
+      "evaluationCitation": "#eval-4"
+    },
+    {
+      "id": "a-106",
+      "method": "did:ion",
+      "spec": "B,C,D,E,F",
+      "note": "The did:ion specification only enumerates the Verification Relationships as they appear at the time of this assessment in the did-core specification.",
+      "evaluationCitation": "#eval-5"
+    }
+  ]
+}
diff --git a/rubric/criteria/58-authentication-model.json b/rubric/criteria/58-authentication-model.json
new file mode 100644
index 0000000..9b5d183
--- /dev/null
+++ b/rubric/criteria/58-authentication-model.json
@@ -0,0 +1,92 @@
+{
+  "name": "Authentication Model",
+  "question": {
+    "question": "How does the method authenticate a given DID operation as coming from the legitimate DID controller?",
+    "instruction": "Include as many as apply to this Method."
+  },
+  "assessmentTemplate": {
+    "columns": [
+      {
+        "heading": "Method",
+        "type": "method",
+        "propertyRef": "method"
+      },
+      {
+        "heading": "Response",
+        "type": "multipleChoice",
+        "propertyRef": "response"
+      },
+      {
+        "heading": "Notes",
+        "type": "note",
+        "propertyRef": "note"
+      }
+    ]
+  },
+  "response": {
+    "type": "multipleChoice",
+    "possibleResponses": [
+      {
+        "label": "A",
+        "meaning": "None"
+      },
+      {
+        "label": "B",
+        "meaning": "Cryptographically signed transactions"
+      },
+      {
+        "label": "C",
+        "meaning": "Cryptographic challenge string & signed response"
+      },
+      {
+        "label": "D",
+        "meaning": "Authenticator App"
+      },
+      {
+        "label": "E",
+        "meaning": "Biometrics"
+      },
+      {
+        "label": "F",
+        "meaning": "Email"
+      },
+      {
+        "label": "G",
+        "meaning": "DNS Record"
+      },
+      {
+        "label": "H",
+        "meaning": "HTML over HTTP"
+      },
+      {
+        "label": "I",
+        "meaning": "SMS/MMS"
+      },
+      {
+        "label": "J",
+        "meaning": "DID document update"
+      },
+      {
+        "label": "K",
+        "meaning": "Other"
+      },
+      {
+        "label": "L",
+        "meaning": "Any"
+      }
+    ]
+  },
+  "relevance": "The way in which DID updates are authenticated can have implications on not only the trustworthiness of the method but also informs someone who wants to use the method what they may need to implement technologically to properly make use of the method.",
+  "id": "https://www.w3.org/TR/did-rubric#criteria-58",
+  "version": "1.0.0",
+  "source": "https://didcriteria.com/criteria/24",
+  "exampleAssessments": [
+    {
+      "id": "a-64",
+      "method": "did:ion",
+      "response": "B",
+      "note": "ION uses JWK and JWS to ensure that DID operations are properly authorized.",
+      "evaluationCitation": "#eval-5"
+    }
+  ]
+}
diff --git a/rubric/criteria/59-financial-entanglements.json b/rubric/criteria/59-financial-entanglements.json
new file mode 100644
index 0000000..e78076a
--- /dev/null
+++ b/rubric/criteria/59-financial-entanglements.json
@@ -0,0 +1,114 @@
+{
+  "name": "Financial Entanglements",
+  "question": {
+    "question": "How was the Method funded?"
+  },
+  "assessmentTemplate": {
+    "columns": [
+      {
+        "heading": "Method",
+        "type": "method",
+        "propertyRef": "method"
+      },
+      {
+        "heading": "Spec.",
+        "type": "enhancedLetter",
+        "propertyRef": "spec"
+      },
+      {
+        "heading": "Net.",
+        "type": "enhancedLetter",
+        "propertyRef": "net"
+      },
+      {
+        "heading": "Reg.",
+        "type": "enhancedLetter",
+        "propertyRef": "reg"
+      },
+      {
+        "heading": "Notes",
+        "type": "note",
+        "propertyRef": "note"
+      }
+    ]
+  },
+  "response": {
+    "type": "multipleChoice",
+    "possibleResponses": [
+      {
+        "label": "A",
+        "meaning": "State-sponsored funding"
+      },
+      {
+        "label": "B",
+        "meaning": "Regulated not-for-profit entity"
+      },
+      {
+        "label": "C",
+        "meaning": "Private equity"
+      },
+      {
+        "label": "D",
+        "meaning": "Operational budget"
+      },
+      {
+        "label": "E",
+        "meaning": "Cryptocurrency"
+      },
+      {
+        "label": "F",
+        "meaning": "Tokenized Initial Coin Offering"
+      },
+      {
+        "label": "G",
+        "meaning": "Initial Public Offering (public equity funding)"
+      },
+      {
+        "label": "H",
+        "meaning": "Other -- State what in the notes"
+      }
+    ]
+  },
+  "relevance": "Funding can create financial entanglements. Those methods that depend on outside financing should be further evaluated to understand the potential consequences of funding to-date.",
+  "id": "https://www.w3.org/TR/did-rubric#criteria-59",
+  "version": "1.0.0",
+  "source": "https://didcriteria.com/criteria/25",
+  "exampleAssessments": [
+    {
+      "id": "a-107",
+      "method": "did:v1.testnet",
+      "spec": "D",
+      "net": "D",
+      "reg": "D",
+      "note": "Spec (D), Net (D), and Reg (D): did:v1 was funded by Digital Bazaar through internal operational budgets",
+      "evaluationCitation": "#eval-3"
+    },
+    {
+      "id": "a-108",
+      "method": "did:v1.production",
+      "spec": "D",
+      "net": "D",
+      "reg": "D",
+      "note": "Spec (D), Net (D), and Reg (D): did:v1 was funded by Digital Bazaar through internal operational budgets",
+      "evaluationCitation": "#eval-3"
+    },
+    {
+      "id": "a-109",
+      "method": "did:web",
+      "spec": "D",
+      "net": "A/B/C/D/G",
+      "reg": "H",
+      "note": "Spec (D): Specification was developed largely by independent firms using operational budgets .\nNet: The web was funded initially by the US Department of Defense and national TLD Administrators are funded by nation-states (A). Network infrastructure of TLD Administrators, hosting services, etc., have largely been funded by non-profits (B), private firms using either private equity (C), operational budgets (D), or public equity offerings (G).\nReg (H): Individual websites and network services have been funded in just about every way imaginable.",
+      "evaluationCitation": "#eval-4"
+    },
+    {
+      "id": "a-110",
+      "method": "did:ion",
+      "spec": "D",
+      "net": "E/C/D",
+      "reg": "E/C/D",
+      "note": "Spec (D): Specification was developed largely by independent firms using operational budgets\nNet and Reg: Bitcoin is a self-funding cryptocurrency (E), IPFS was developed by Protocol Labs, using some combination of private equity and operating budget (C/D).",
+      "evaluationCitation": "#eval-5"
+    }
+  ]
+}
diff --git a/rubric/criteria/6-permissioned-operation.json b/rubric/criteria/6-permissioned-operation.json
new file mode 100644
index 0000000..d2b9905
--- /dev/null
+++ b/rubric/criteria/6-permissioned-operation.json
@@ -0,0 +1,81 @@
+{
+  "name": "Permissioned Operation",
+  "id": "https://www.w3.org/TR/did-rubric#criteria-6",
+  "source": ".",
+  "question": {
+    "question": "Does one need permission to use the DID Method?"
+  },
+  "response": {
+    "type": "multipleChoice",
+    "possibleResponses": [
+      {
+        "label": "A",
+        "meaning": "Anyone can participate fully (full read/write and participation in consensus)."
+      },
+      {
+        "label": "B",
+        "meaning": "Anyone can read/write, but consensus mechanism is permissioned."
+      },
+      {
+        "label": "C",
+        "meaning": "Anyone can read, but writing and consensus is permissioned."
+      },
+      {
+        "label": "D",
+        "meaning": "All participation is permissioned."
+      }
+    ]
+  },
+  "relevance": "Permissioned operation impacts the availability of the network to various participants, which can affect inclusivity with regard to underserved or vulnerable populations. Permissioned networks also expose the permission giver to legal or other attacks.",
+  "assessmentTemplate": {
+    "columns": [
+      {
+        "heading": "Method",
+        "type": "method",
+        "propertyRef": "method"
+      },
+      {
+        "heading": "Net.",
+        "type": "enhancedLetter",
+        "propertyRef": "net"
+      },
+      {
+        "heading": "Reg.",
+        "type": "enhancedLetter",
+        "propertyRef": "reg"
+      },
+      {
+        "heading": "Notes",
+        "type": "note",
+        "propertyRef": "note"
+      }
+    ]
+  },
+  "version": "1.0.1",
+  "exampleAssessments": [
+    {
+      "id": "a-19",
+      "method": "did:ethr",
+      "net": "A",
+      "reg": "A",
+      "evaluationCitation": "#eval-1",
+      "note": "Ethereum is open to anyone. The registry is accessible to anyone."
+    },
+    {
+      "id": "a-20",
+      "method": "did:v1.production",
+      "net": "B+",
+      "reg": "B+",
+      "note": "Net (B+) and Reg (B+)The ledger is available to the public for reading, and anyone can submit a transaction (either through paying an accelerator or in-kind contribution), however, only Witnesses are able to approve updates to the chain. The propagation rules of the peer network restrict the ability for Witnesses to selectively approve transactions, but ultimately, the decision remains with a supermajority of Witnesses.",
+      "evaluationCitation": "#eval-3"
+    },
+    {
+      "id": "a-21",
+      "method": "did:git",
+      "net": "A",
+      "reg": "D",
+      "evaluationCitation": "#eval-1",
+      "note": "Git software is available to anyone. Participation and access is controlled by the repo maintainers."
+    }
+  ]
+}
diff --git a/rubric/criteria/60-organizational-maturity-in-time.json b/rubric/criteria/60-organizational-maturity-in-time.json
new file mode 100644
index 0000000..338d408
--- /dev/null
+++ b/rubric/criteria/60-organizational-maturity-in-time.json
@@ -0,0 +1,106 @@
+{
+  "name": "Organizational Maturity in Time",
+  "question": {
+    "question": "How long has the organization(s) behind the Method been operational?"
+  },
+  "assessmentTemplate": {
+    "columns": [
+      {
+        "heading": "Method",
+        "type": "method",
+        "propertyRef": "method"
+      },
+      {
+        "heading": "Spec.",
+        "type": "enhancedLetter",
+        "propertyRef": "spec"
+      },
+      {
+        "heading": "Net.",
+        "type": "enhancedLetter",
+        "propertyRef": "net"
+      },
+      {
+        "heading": "Reg.",
+        "type": "enhancedLetter",
+        "propertyRef": "reg"
+      },
+      {
+        "heading": "Notes",
+        "type": "note",
+        "propertyRef": "note"
+      }
+    ]
+  },
+  "response": {
+    "type": "multipleChoice",
+    "possibleResponses": [
+      {
+        "label": "A",
+        "meaning": "Over 20 years"
+      },
+      {
+        "label": "B",
+        "meaning": "Over 10 years"
+      },
+      {
+        "label": "C",
+        "meaning": "Over 5 years"
+      },
+      {
+        "label": "D",
+        "meaning": "Over 1 year"
+      },
+      {
+        "label": "E",
+        "meaning": "Less than 1 year"
+      },
+      {
+        "label": "F",
+        "meaning": "There is no organization per se"
+      }
+    ]
+  },
+  "relevance": "The age of the organization(s) behind a Method can be used to give an idea into organizational maturity. It is not a sole indicator and should be taken as a data point in evaluating the Method organization’s current state.",
+  "id": "https://www.w3.org/TR/did-rubric#criteria-60",
+  "version": "1.0.0",
+  "source": "https://didcriteria.com/criteria/26",
+  "exampleAssessments": [
+    {
+      "id": "a-111",
+      "method": "did:v1.testnet",
+      "spec": "B",
+      "net": "D",
+      "reg": "D",
+      "note": "Spec: Digital Bazaar, the team behind the spec has been in business for over 17 years. (B)\nNet (D) and Reg (D): The Veres One Foundation was founded in 2019.",
+      "evaluationCitation": "#eval-3"
+    },
+    {
+      "id": "a-112",
+      "method": "did:v1.production",
+      "spec": "B",
+      "net": "D",
+      "reg": "D",
+      "note": "Spec: Digital Bazaar, the team behind the spec has been in business for over 17 years. (B)\nNet (D) and Reg (D): The Veres One Foundation was founded in 2019.",
+      "evaluationCitation": "#eval-3"
+    },
+    {
+      "id": "a-113",
+      "method": "did:web",
+      "spec": "F",
+      "net": "A",
+      "reg": "*",
+      "note": "Spec (F): did:web specification development began in earnest in 2019 by a variety of interested parties.\nNet (A): The Internet and the World Wide Web have been around for over 20 years.\nReg (*): The individual web servers that might be used depend on the organizational maturity of the hosting company and the website operator.",
+      "evaluationCitation": "#eval-4"
+    },
+    {
+      "id": "a-114",
+      "method": "did:ion",
+      "spec": "A/D",
+      "net": "C",
+      "reg": "C",
+      "note": "Spec: The major organizations behind the did:ion specification are DIF (D) and Microsoft (A). DIF is also the organization driving the Sidetree specification, which did:ion is based on.\nNet (C) and Reg (C): Are based on bitcoin and IPFS\nMicrosoft has existed for more than 20 years. DIF and Protocol Labs (the organization behind IPFS) are younger, but each have existed for at least five years. Bitcoin started in 2009, but really has no formal organization.",
+      "evaluationCitation": "#eval-5"
+    }
+  ]
+}
diff --git a/rubric/criteria/61-release-status.json b/rubric/criteria/61-release-status.json
new file mode 100644
index 0000000..9bfb1b0
--- /dev/null
+++ b/rubric/criteria/61-release-status.json
@@ -0,0 +1,89 @@
+{
+  "name": "Release Status",
+  "question": {
+    "question": "Can the method be used for production today?"
+  },
+  "assessmentTemplate": {
+    "columns": [
+      {
+        "heading": "Method",
+        "type": "method",
+        "propertyRef": "method"
+      },
+      {
+        "heading": "Net.",
+        "type": "enhancedLetter",
+        "propertyRef": "net"
+      },
+      {
+        "heading": "Reg.",
+        "type": "enhancedLetter",
+        "propertyRef": "reg"
+      },
+      {
+        "heading": "Notes",
+        "type": "note",
+        "propertyRef": "note"
+      }
+    ]
+  },
+  "response": {
+    "type": "multipleChoice",
+    "possibleResponses": [
+      {
+        "label": "A",
+        "meaning": "Yes. A production system is available to the general population."
+      },
+      {
+        "label": "B",
+        "meaning": "No. A test network is operational."
+      },
+      {
+        "label": "C",
+        "meaning": "No. Only an internal developer network is operational."
+      },
+      {
+        "label": "D",
+        "meaning": "No. The software is not yet running on any network."
+      }
+    ]
+  },
+  "relevance": "Some errors only become apparent after sufficient time to test edge cases and performance boundaries.",
+  "id": "https://www.w3.org/TR/did-rubric#criteria-61",
+  "version": "1.0.0",
+  "source": "https://didcriteria.com/criteria/27",
+  "exampleAssessments": [
+    {
+      "id": "a-115",
+      "method": "did:v1.testnet",
+      "net": "B",
+      "reg": "B",
+      "note": "Net (B) and Reg (B): The Veres One test network has been operational for over 3 years, in three major release iterations. It is not yet in production.",
+      "evaluationCitation": "#eval-3"
+    },
+    {
+      "id": "a-116",
+      "method": "did:v1.production",
+      "net": "B",
+      "reg": "B",
+      "note": "Net (B) and Reg (B): The Veres One test network has been operational for over 3 years, in three major release iterations. It is not yet in production.",
+      "evaluationCitation": "#eval-3"
+    },
+    {
+      "id": "a-117",
+      "method": "did:web",
+      "net": "A",
+      "reg": "A",
+      "note": "Net (A) and Reg (A): The web has been in general use for 30+ years. Multiple production deployments are in use today.",
+      "evaluationCitation": "#eval-4"
+    },
+    {
+      "id": "a-118",
+      "method": "did:ion",
+      "net": "A",
+      "reg": "A",
+      "note": "Net (A) and Reg (A): All major components are in production and available to the public.",
+      "evaluationCitation": "#eval-5"
+    }
+  ]
+}
diff --git a/rubric/criteria/62-maturity.json b/rubric/criteria/62-maturity.json
new file mode 100644
index 0000000..5462052
--- /dev/null
+++ b/rubric/criteria/62-maturity.json
@@ -0,0 +1,93 @@
+{
+  "name": "Maturity",
+  "question": {
+    "question": "How long has the underlying network/registry been available to third parties for non-trivial use?"
+  },
+  "assessmentTemplate": {
+    "columns": [
+      {
+        "heading": "Method",
+        "type": "method",
+        "propertyRef": "method"
+      },
+      {
+        "heading": "Net.",
+        "type": "enhancedLetter",
+        "propertyRef": "net"
+      },
+      {
+        "heading": "Reg.",
+        "type": "enhancedLetter",
+        "propertyRef": "reg"
+      },
+      {
+        "heading": "Notes",
+        "type": "note",
+        "propertyRef": "note"
+      }
+    ]
+  },
+  "response": {
+    "type": "multipleChoice",
+    "possibleResponses": [
+      {
+        "label": "A",
+        "meaning": "The network/registry has been operationalized for ten years or more."
+      },
+      {
+        "label": "B",
+        "meaning": "The network/registry has been operationalized for five years or more"
+      },
+      {
+        "label": "C",
+        "meaning": "The network/registry has been operationalized for one year or more"
+      },
+      {
+        "label": "D",
+        "meaning": "The network/registry has been operationalized for less than one year"
+      },
+      {
+        "label": "E",
+        "meaning": "The network/registry is not operationalized for non-trivial use"
+      }
+    ]
+  },
+  "relevance": "Some errors only become apparent after sufficient time to test edge cases and performance boundaries.",
+  "id": "https://www.w3.org/TR/did-rubric#criteria-62",
+  "version": "1.0.0",
+  "source": "https://didcriteria.com/criteria/28",
+  "exampleAssessments": [
+    {
+      "id": "a-119",
+      "method": "did:v1.testnet",
+      "net": "C",
+      "reg": "C",
+      "note": "Net (C) and Reg (C): The Veres One test network has been operational for over 3 years in three major release iterations.",
+      "evaluationCitation": "#eval-3"
+    },
+    {
+      "id": "a-120",
+      "method": "did:v1.production",
+      "net": "E",
+      "reg": "E",
+      "note": "Net (E) and Reg (E): The Veres One production network has not yet been released.",
+      "evaluationCitation": "#eval-3"
+    },
+    {
+      "id": "a-121",
+      "method": "did:web",
+      "net": "A",
+      "reg": "D",
+      "note": "Net (A): The web has been around since 1991.\nReg (D): We know of no websites that have operationalized did:web earlier than July 2021.",
+      "evaluationCitation": "#eval-4"
+    },
+    {
+      "id": "a-122",
+      "method": "did:ion",
+      "net": "D/A/B",
+      "reg": "D/A/B",
+      "note": "Net and Reg: did:ion entered production on Jan 22, 2021 (less than one year at the point of this Evaluation) (D). Bitcoin has been in operation since 2009 (A) and IPFS since 2015 (B).",
+      "evaluationCitation": "#eval-5"
+    }
+  ]
+}
diff --git a/rubric/criteria/63-expert-review-consensus.json b/rubric/criteria/63-expert-review-consensus.json
new file mode 100644
index 0000000..4d6aa85
--- /dev/null
+++ b/rubric/criteria/63-expert-review-consensus.json
@@ -0,0 +1,89 @@
+{
+  "name": "Expert Review (Consensus)",
+  "question": {
+    "question": "If the method makes use of a distributed consensus mechanism, has the registry’s consensus mechanism undergone sufficient review?"
+  },
+  "assessmentTemplate": {
+    "columns": [
+      {
+        "heading": "Method",
+        "type": "method",
+        "propertyRef": "method"
+      },
+      {
+        "heading": "Net.",
+        "type": "enhancedLetter",
+        "propertyRef": "net"
+      },
+      {
+        "heading": "Reg.",
+        "type": "enhancedLetter",
+        "propertyRef": "reg"
+      },
+      {
+        "heading": "Notes",
+        "type": "note",
+        "propertyRef": "note"
+      }
+    ]
+  },
+  "response": {
+    "type": "multipleChoice",
+    "possibleResponses": [
+      {
+        "label": "A",
+        "meaning": "Yes. A formal proof has been published in a peer reviewed journal"
+      },
+      {
+        "label": "B",
+        "meaning": "Yes. A formal proof has been published"
+      },
+      {
+        "label": "C",
+        "meaning": "No. An informal argument has been published"
+      },
+      {
+        "label": "D",
+        "meaning": "No. The consensus algorithm is opaque to registry users."
+      }
+    ]
+  },
+  "relevance": "Decentralized systems are notoriously difficult to get right. Consensus ordering, in particular, is known to be a hard problem solved by distributed ledgers. Even simpler registries may trade off provable finality with probabilistic finality. It is vital that the Method used for high-value or life-critical application be rigorously evaluated for potential flaws.",
+  "id": "https://www.w3.org/TR/did-rubric#criteria-63",
+  "version": "1.0.0",
+  "source": "https://didcriteria.com/criteria/29",
+  "exampleAssessments": [
+    {
+      "id": "a-131",
+      "method": "did:v1.testnet",
+      "net": "B",
+      "reg": "B",
+      "note": "Net (B) and Reg (B): Mathematical proofs have been peer reviewed for publication in a not-yet-published book on consensus algorithms and as a special IEEE journal publication on network consensus algorithms.",
+      "evaluationCitation": "#eval-3"
+    },
+    {
+      "id": "a-132",
+      "method": "did:v1.production",
+      "net": "B",
+      "reg": "B",
+      "note": "Net (B) and Reg (B): Mathematical proofs have been peer reviewed for publication in a not-yet-published book on consensus algorithms and as a special IEEE journal publication on network consensus algorithms.",
+      "evaluationCitation": "#eval-3"
+    },
+    {
+      "id": "a-133",
+      "method": "did:web",
+      "net": "A",
+      "reg": "n/a",
+      "note": "Net (A): The DNS and TLS systems have been thoroughly reviewed in academic literature in research about the Internet and the World Wide Web.\nReg (n/a) : The method provides no consensus mechanism with regard to the https server itself. The entity controlling the server operates independently. (n/a)",
+      "evaluationCitation": "#eval-4"
+    },
+    {
+      "id": "a-134",
+      "method": "did:ion",
+      "net": "A",
+      "reg": "A",
+      "note": "Net (A) and Reg (A): Bitcoin’s proof of work consensus algorithm has been thoroughly reviewed. IPFS uses a Kademlia hash table algorithm, which has also undergone thorough academic review since publication in 2002. However, compromising the hash table would not compromise the content of a DID Document; rather it would affect the ability to resolve the DID to that DID Document. IPFS’s content-hash addressing is based on multihash, and did:ion requires using the SHA-256 variant of multihash. SHA-256 is extremely well reviewed.",
+      "evaluationCitation": "#eval-5"
+    }
+  ]
+}
diff --git a/rubric/criteria/64-united-states-federal-compliance.json b/rubric/criteria/64-united-states-federal-compliance.json
new file mode 100644
index 0000000..152755a
--- /dev/null
+++ b/rubric/criteria/64-united-states-federal-compliance.json
@@ -0,0 +1,94 @@
+{
+  "name": "United States Federal Compliance",
+  "question": {
+    "question": "Is the Method compliant with US Federal requirements for the use of cryptography?"
+  },
+  "assessmentTemplate": {
+    "columns": [
+      {
+        "heading": "Method",
+        "type": "method",
+        "propertyRef": "method"
+      },
+      {
+        "heading": "Spec.",
+        "type": "enhancedLetter",
+        "propertyRef": "spec"
+      },
+      {
+        "heading": "Net.",
+        "type": "enhancedLetter",
+        "propertyRef": "net"
+      },
+      {
+        "heading": "Reg.",
+        "type": "enhancedLetter",
+        "propertyRef": "reg"
+      },
+      {
+        "heading": "Notes",
+        "type": "note",
+        "propertyRef": "note"
+      }
+    ]
+  },
+  "response": {
+    "type": "multipleChoice",
+    "possibleResponses": [
+      {
+        "label": "A",
+        "meaning": "Both registry consensus *and* transaction validation are compliant"
+      },
+      {
+        "label": "B",
+        "meaning": "Transaction validation is compliant but consensus is not"
+      },
+      {
+        "label": "C",
+        "meaning": "No. Neither consensus nor transactions are compliant"
+      }
+    ]
+  },
+  "relevance": "Many US Federal programs and projects require use of cryptography according to standards set by the National Institute of Standards and Technology (NIST), such as:FIPS 186-5 (https://csrc.nist.gov/publications/detail/fips/186/5/draft)NIST 800-131Ar2 (https://csrc.nist.gov/publications/detail/sp/800-131a/rev-2/final)SP 800-186 (https://csrc.nist.gov/publications/detail/sp/800-186/draft)NIST FIPS 186-4 https://csrc.nist.gov/publications/detail/fips/186/4/final)NIST 800-38D (https://csrc.nist.gov/publications/detail/sp/800-38d/final)NIST 800-38F (https://csrc.nist.gov/publications/detail/sp/800-38f/final)FIPS 180-4 (https://csrc.nist.gov/publications/detail/fips/180/4/final)FIPS 800-107r1. (https://csrc.nist.gov/publications/detail/sp/800-107/rev-1/final)",
+  "id": "https://www.w3.org/TR/did-rubric#criteria-64",
+  "version": "1.0.0",
+  "source": "https://didcriteria.com/criteria/30",
+  "exampleAssessments": [
+    {
+      "id": "a-139",
+      "method": "did:v1.testnet",
+      "spec": "A",
+      "net": "A",
+      "reg": "A",
+      "note": "Spec (A), Net (A), and Reg (A): did:v1 was written to be compatible with all NIST requirements, including those specified in the Relevance section (6.8.3)",
+      "evaluationCitation": "#eval-3"
+    },
+    {
+      "id": "a-140",
+      "method": "did:v1.production",
+      "spec": "A",
+      "net": "A",
+      "reg": "A",
+      "note": "Spec (A), Net (A), and Reg (A): did:v1 was written to be compatible with all NIST requirements, including those specified in the Relevance section (6.8.3)",
+      "evaluationCitation": "#eval-3"
+    },
+    {
+      "id": "a-141",
+      "method": "did:web",
+      "spec": "A",
+      "net": "A",
+      "reg": "A",
+      "note": "Spec (A), Net (A), and Reg (A): Due to the flexibility of the underlying web architecture, any layer *might* be non-compliant; However, the web is a mature platform with many years of solutions that do, in fact, meet US federal requirements.",
+      "evaluationCitation": "#eval-4"
+    },
+    {
+      "id": "a-142",
+      "method": "did:ion",
+      "spec": "B",
+      "net": "B",
+      "reg": "B",
+      "note": "Spec (B), Net (B), and Reg (B): Bitcoin is likely not NIST compliant thanks to the adoption of Schnorr signatures (with the taproot extension), which are not yet NIST approved. However, recent signals from NIST suggest that (1) bitcoin use of cryptography is not prima facie out of compliance and (2) NIST’s previous evaluations of Schnorr hinged on patent concerns; now that those patents are expired, many are optimistic that Schnoor will be given serious consideration in future evaluations. IPFS allows non-approved hash algorithms through multihash, however did:ion adds the requirement that all hashes be SHA-256, which is NIST compliant.",
+      "evaluationCitation": "#eval-5"
+    }
+  ]
+}
diff --git a/rubric/criteria/7-interoperability.json b/rubric/criteria/7-interoperability.json
new file mode 100644
index 0000000..b3a348b
--- /dev/null
+++ b/rubric/criteria/7-interoperability.json
@@ -0,0 +1,89 @@
+{
+  "name": "Interoperability",
+  "id": "https://www.w3.org/TR/did-rubric#criteria-7",
+  "source": ".",
+  "question": {
+    "question": "Does the DID Method restrict access or functionality to particular client software implementations?"
+  },
+  "response": {
+    "type": "multipleChoice",
+    "possibleResponses": [
+      {
+        "label": "A",
+        "meaning": "Any wallet can work with any resolver on any registry,"
+      },
+      {
+        "label": "B",
+        "meaning": "Any wallet can work with multiple resolvers and multiple registries,"
+      },
+      {
+        "label": "C",
+        "meaning": "Some implementations of some wallets can work with some resolvers,"
+      },
+      {
+        "label": "D",
+        "meaning": "There is a single combined suite of resolver, registry, and wallet."
+      }
+    ]
+  },
+  "relevance": "The ability to communicate with different (ideally all) resolvers and registries significantly increases the applicability of a decentralized identity layer / usability of a given wallet. Vice versa, limited capability to work with other Methods and registries restrict usage.",
+  "assessmentTemplate": {
+    "columns": [
+      {
+        "heading": "Method",
+        "type": "method",
+        "propertyRef": "method"
+      },
+      {
+        "heading": "Spec.",
+        "type": "enhancedLetter",
+        "propertyRef": "spec"
+      },
+      {
+        "heading": "Net.",
+        "type": "enhancedLetter",
+        "propertyRef": "net"
+      },
+      {
+        "heading": "Reg.",
+        "type": "enhancedLetter",
+        "propertyRef": "reg"
+      },
+      {
+        "heading": "Notes",
+        "type": "note",
+        "propertyRef": "note"
+      }
+    ]
+  },
+  "version": "2.0.0",
+  "exampleAssessments": [
+    {
+      "id": "a-78",
+      "method": "did:v1.production",
+      "spec": "A",
+      "net": "A",
+      "reg": "A",
+      "note": "Spec (A), Net (A) and Reg (A): Veres One uses 100% W3C conformant representations, without regard to which wallet implementation is used.",
+      "evaluationCitation": "#eval-3"
+    },
+    {
+      "id": "a-39",
+      "method": "did:btcr",
+      "spec": "A",
+      "net": "A",
+      "reg": "A",
+      "evaluationCitation": "#eval-1",
+      "note": "Bitcoin has no restrictions on the software used to access the network."
+    },
+    {
+      "id": "a-79",
+      "method": "did:web",
+      "spec": "A",
+      "net": "A-",
+      "reg": "A-",
+      "note": "Spec (A), Net (A-) and Reg (A-): Web-based wallets may have complications from CORS (cross-origin resource sharing), but in general any “wallet” is compatible. Although a given service (hosting or website, etc.) could add a layer of permissioned restrictions, the did:web Method does not require it. Similarly, nation-state level firewalls could restrict access at various layers, but, again, the Method does not require it.",
+      "evaluationCitation": "#eval-4"
+    }
+  ]
+}
diff --git a/rubric/criteria/8-scope-of-usage.json b/rubric/criteria/8-scope-of-usage.json
new file mode 100644
index 0000000..c015357
--- /dev/null
+++ b/rubric/criteria/8-scope-of-usage.json
@@ -0,0 +1,81 @@
+{
+  "name": "Scope of Usage",
+  "id": "https://www.w3.org/TR/did-rubric#criteria-8",
+  "source": ".",
+  "question": {
+    "question": "How widely can DIDs of this Method be used?"
+  },
+  "response": {
+    "type": "multipleChoice",
+    "possibleResponses": [
+      {
+        "label": "A",
+        "meaning": "Universal: DIDs can only be created and used universally, between any number of parties."
+      },
+      {
+        "label": "B",
+        "meaning": "Contextual: DIDs can be created and used contextually, between any set of collaborating parties."
+      },
+      {
+        "label": "C",
+        "meaning": "Paired: DID can be created and used pairwise, between any two parties."
+      },
+      {
+        "label": "D",
+        "meaning": "Central: DIDs can only be created and used with a single, centralized party."
+      }
+    ]
+  },
+  "relevance": "Different Methods enable different scopes in which a DID might be considered usable or valid. Some DIDs are only resolvable within a limited context, others are suitable for global use. Contextual DIDs are a middle ground that allow a set of parties to use DIDs, while those outside that group cannot meaningfully do so. Finally, central DIDs use the DID syntax and DID Documents to establish secure communications, but authority to use these DIDs resides with the central party, who may revoke that ability at their discretion.",
+  "assessmentTemplate": {
+    "columns": [
+      {
+        "heading": "Method",
+        "type": "method",
+        "propertyRef": "method"
+      },
+      {
+        "heading": "Net.",
+        "type": "enhancedLetter",
+        "propertyRef": "net"
+      },
+      {
+        "heading": "Reg.",
+        "type": "enhancedLetter",
+        "propertyRef": "reg"
+      },
+      {
+        "heading": "Notes",
+        "type": "note",
+        "propertyRef": "note"
+      }
+    ]
+  },
+  "version": "1.0.1",
+  "exampleAssessments": [
+    {
+      "id": "a-22",
+      "method": "did:peer",
+      "net": "A+",
+      "reg": "C",
+      "evaluationCitation": "#eval-1",
+      "note": "Did:peer is communication-layer independent, so it can be used on any network, including direct physical links. However, only those parties to the creation of the DID can actually use it. The DIDs have no use outside that direct peer-to-peer relationship."
+    },
+    {
+      "id": "a-23",
+      "method": "did:web",
+      "net": "A/B",
+      "reg": "A/B",
+      "note": "In general, did:web DIDs can be used for anything, by anyone (A). However, some implementers believe did:web should only be used to represent institutional entities (who tend to already have good systemic controls over web infrastructure). (B)",
+      "evaluationCitation": "#eval-4"
+    },
+    {
+      "id": "a-24",
+      "method": "did:ethr",
+      "net": "A",
+      "reg": "A",
+      "evaluationCitation": "#eval-1",
+      "note": "Open, permissionless, and globally resolvable."
+    }
+  ]
+}
diff --git a/rubric/criteria/9-financial-accountability.json b/rubric/criteria/9-financial-accountability.json
new file mode 100644
index 0000000..79b13fd
--- /dev/null
+++ b/rubric/criteria/9-financial-accountability.json
@@ -0,0 +1,81 @@
+{
+  "name": "Financial accountability",
+  "id": "https://www.w3.org/TR/did-rubric#criteria-9",
+  "source": ".",
+  "question": {
+    "question": "How transparent are the economics of the Method?"
+  },
+  "response": {
+    "type": "multipleChoice",
+    "possibleResponses": [
+      {
+        "label": "A",
+        "meaning": "All operational finances are transparent and accounted for."
+      },
+      {
+        "label": "B",
+        "meaning": "Compensation for primary operators is transparent."
+      },
+      {
+        "label": "C",
+        "meaning": "Some financial flows are visible."
+      },
+      {
+        "label": "D",
+        "meaning": "Operation is privatized with no visibility."
+      }
+    ]
+  },
+  "relevance": "Similar to Governance, financial accountability reflects the integrity and sustainability of the DID registry. The more open, transparent, and accountable the system, the greater the confidence a DID controller may have that it will remain stable and operational, and therefore continue to provide service.",
+  "assessmentTemplate": {
+    "columns": [
+      {
+        "heading": "Method",
+        "type": "method",
+        "propertyRef": "method"
+      },
+      {
+        "heading": "Net.",
+        "type": "enhancedLetter",
+        "propertyRef": "net"
+      },
+      {
+        "heading": "Reg.",
+        "type": "enhancedLetter",
+        "propertyRef": "reg"
+      },
+      {
+        "heading": "Notes",
+        "type": "note",
+        "propertyRef": "note"
+      }
+    ]
+  },
+  "version": "1.0.1",
+  "exampleAssessments": [
+    {
+      "id": "a-49",
+      "method": "did:peer",
+      "net": "D",
+      "reg": "D",
+      "evaluationCitation": "#eval-1",
+      "note": "The financials of both parties have no visibility."
+    },
+    {
+      "id": "a-106",
+      "method": "did:v1.production",
+      "net": "B",
+      "reg": "B",
+      "note": "Net (B) and Reg (B): Once operations are transferred to the Foundation, finances should be considerably more transparent.",
+      "evaluationCitation": "#eval-3"
+    },
+    {
+      "id": "a-51",
+      "method": "did:btcr",
+      "net": "A-",
+      "reg": "A-",
+      "evaluationCitation": "#eval-1",
+      "note": "Bitcoin is transparent, although operations are somewhat obscured by pseudonymous transaction addresses."
+    }
+  ]
+}
diff --git a/rubric/rubric-outline.json b/rubric/rubric-outline.json
new file mode 100644
index 0000000..2b9a623
--- /dev/null
+++ b/rubric/rubric-outline.json
@@ -0,0 +1,110 @@
+{
+  "categories": [
+    {
+      "name": "Rulemaking",
+      "description": "Rulemaking criteria address who makes the rules and how. Output of rulemaking are the rules.",
+      "criteria": [
+        "https://www.w3.org/TR/did-rubric#criteria-1",
+        "https://www.w3.org/TR/did-rubric#criteria-2",
+        "https://www.w3.org/TR/did-rubric#criteria-37",
+        "https://www.w3.org/TR/did-rubric#criteria-38",
+        "https://www.w3.org/TR/did-rubric#criteria-39",
+        "https://www.w3.org/TR/did-rubric#criteria-40"
+      ]
+    },
+    {
+      "name": "Design",
+      "description": "Design criteria addresses the method as designed. In other words, the output of the rulemaking: what rules apply to this DID method?",
+      "criteria": [
+        "https://www.w3.org/TR/did-rubric#criteria-6",
+        "https://www.w3.org/TR/did-rubric#criteria-7",
+        "https://www.w3.org/TR/did-rubric#criteria-8",
+        "https://www.w3.org/TR/did-rubric#criteria-41",
+        "https://www.w3.org/TR/did-rubric#criteria-42",
+        "https://www.w3.org/TR/did-rubric#criteria-43",
+        "https://www.w3.org/TR/did-rubric#criteria-44",
+        "https://www.w3.org/TR/did-rubric#criteria-45",
+        "https://www.w3.org/TR/did-rubric#criteria-46"
+      ]
+    },
+    {
+      "name": "Operation",
+      "description": "Operation criteria address how the rules are operationalized, ie., how are the rules embodied in a working system.",
+      "criteria": [
+        "https://www.w3.org/TR/did-rubric#criteria-9",
+        "https://www.w3.org/TR/did-rubric#criteria-10",
+        "https://www.w3.org/TR/did-rubric#criteria-11",
+        "https://www.w3.org/TR/did-rubric#criteria-47",
+        "https://www.w3.org/TR/did-rubric#criteria-48",
+        "https://www.w3.org/TR/did-rubric#criteria-49",
+        "https://www.w3.org/TR/did-rubric#criteria-50",
+        "https://www.w3.org/TR/did-rubric#criteria-51"
+      ]
+    },
+    {
+      "name": "Enforcement",
+      "description": "Criteria in this section deal with the design rules that enable maintaining the integrity of the verifiable data registry (VDR) and the means of applying those rules. Enforcement is the proper execution of the process of ensuring compliance with laws, regulations, rules, standards, and social norms. This includes how the rule of law is applied to entities involved in governance and operation of the method.",
+      "criteria": [
+        "https://www.w3.org/TR/did-rubric#criteria-12",
+        "https://www.w3.org/TR/did-rubric#criteria-52",
+        "https://www.w3.org/TR/did-rubric#criteria-53",
+        "https://www.w3.org/TR/did-rubric#criteria-54",
+        "https://www.w3.org/TR/did-rubric#criteria-55",
+        "https://www.w3.org/TR/did-rubric#criteria-56",
+        "https://www.w3.org/TR/did-rubric#criteria-57",
+        "https://www.w3.org/TR/did-rubric#criteria-58"
+      ]
+    },
+    {
+      "name": "Alternatives",
+      "description": "For each major software component (Wallet, Resolver, andRegistry), ask each of the following questions. In this section, because DIDs are so early in the development lifecycle, most DID methods in production have only one implementation and some have none. Therefore, we have not standardized the responses nor provided examples. Consider these open-ended essay questions for consideration. As the market matures, this subset of questions will improve.",
+      "criteria": [
+        "https://www.w3.org/TR/did-rubric#criteria-13",
+        "https://www.w3.org/TR/did-rubric#criteria-14",
+        "https://www.w3.org/TR/did-rubric#criteria-15",
+        "https://www.w3.org/TR/did-rubric#criteria-16",
+        "https://www.w3.org/TR/did-rubric#criteria-17",
+        "https://www.w3.org/TR/did-rubric#criteria-18"
+      ]
+    },
+    {
+      "name": "Adoption (and diversity)",
+      "description": "Adoption criteria address how widely the method and its implementations are used by various parties and systems.",
+      "criteria": [
+        "https://www.w3.org/TR/did-rubric#criteria-19",
+        "https://www.w3.org/TR/did-rubric#criteria-20",
+        "https://www.w3.org/TR/did-rubric#criteria-21",
+        "https://www.w3.org/TR/did-rubric#criteria-22",
+        "https://www.w3.org/TR/did-rubric#criteria-23",
+        "https://www.w3.org/TR/did-rubric#criteria-59",
+        "https://www.w3.org/TR/did-rubric#criteria-60",
+        "https://www.w3.org/TR/did-rubric#criteria-61",
+        "https://www.w3.org/TR/did-rubric#criteria-62"
+      ]
+    },
+    {
+      "name": "Security",
+      "description": "Security criteria address how the method is cryptographically secured.",
+      "criteria": [
+        "https://www.w3.org/TR/did-rubric#criteria-24",
+        "https://www.w3.org/TR/did-rubric#criteria-28",
+        "https://www.w3.org/TR/did-rubric#criteria-30",
+        "https://www.w3.org/TR/did-rubric#criteria-31",
+        "https://www.w3.org/TR/did-rubric#criteria-25",
+        "https://www.w3.org/TR/did-rubric#criteria-63",
+        "https://www.w3.org/TR/did-rubric#criteria-29",
+        "https://www.w3.org/TR/did-rubric#criteria-64"
+      ]
+    },
+    {
+      "name": "Privacy",
+      "description": "Addresses the ability of a DID method to ensure various privacy mechanisms. When DIDs are used as identifiers for people, it becomes important to consider what tools a DID method offers to operate at different levels of privacy. Use cases that focus on IoT or institutions may not feel that this dimension is especially important (though institutional privacy may sometimes be desirable).",
+      "criteria": [
+        "https://www.w3.org/TR/did-rubric#criteria-33",
+        "https://www.w3.org/TR/did-rubric#criteria-34",
+        "https://www.w3.org/TR/did-rubric#criteria-35",
+        "https://www.w3.org/TR/did-rubric#criteria-36"
+      ]
+    }
+  ]
+}
diff --git a/tooling/package-lock.json b/tooling/package-lock.json
new file mode 100644
index 0000000..44060a2
--- /dev/null
+++ b/tooling/package-lock.json
@@ -0,0 +1,88 @@
+{
+    "name": "did-rubric-tooling",
+    "version": "0.0.1",
+    "lockfileVersion": 3,
+    "requires": true,
+    "packages": {
+        "": {
+            "name": "did-rubric-tooling",
+            "version": "0.0.1",
+            "license": "W3C",
+            "dependencies": {
+                "ajv": "^8.6.3",
+                "js-yaml": "^4.1.0"
+            }
+        },
+        "node_modules/ajv": {
+            "version": "8.17.1",
+            "resolved": "https://registry.npmjs.org/ajv/-/ajv-8.17.1.tgz",
+            "integrity": "sha512-B/gBuNg5SiMTrPkC+A2+cW0RszwxYmn6VYxB/inlBStS5nx6xHIt/ehKRhIMhqusl7a8LjQoZnjCs5vhwxOQ1g==",
+            "license": "MIT",
+            "dependencies": {
+                "fast-deep-equal": "^3.1.3",
+                "fast-uri": "^3.0.1",
+                "json-schema-traverse": "^1.0.0",
+                "require-from-string": "^2.0.2"
+            },
+            "funding": {
+                "type": "github",
+                "url": "https://github.com/sponsors/epoberezkin"
+            }
+        },
+        "node_modules/argparse": {
+            "version": "2.0.1",
+            "resolved": "https://registry.npmjs.org/argparse/-/argparse-2.0.1.tgz",
+            "integrity": "sha512-8+9WqebbFzpX9OR+Wa6O29asIogeRMzcGtAINdpMHHyAg10f05aSFVBbcEqGf/PXw1EjAZ+q2/bEBg3DvurK3Q==",
+            "license": "Python-2.0"
+        },
+        "node_modules/fast-deep-equal": {
+            "version": "3.1.3",
+            "resolved": "https://registry.npmjs.org/fast-deep-equal/-/fast-deep-equal-3.1.3.tgz",
+            "integrity": "sha512-f3qQ9oQy9j2AhBe/H9VC91wLmKBCCU/gDOnKNAYG5hswO7BLKj09Hc5HYNz9cGI++xlpDCIgDaitVs03ATR84Q==",
+            "license": "MIT"
+        },
+        "node_modules/fast-uri": {
+            "version": "3.1.0",
+            "resolved": "https://registry.npmjs.org/fast-uri/-/fast-uri-3.1.0.tgz",
+            "integrity": "sha512-iPeeDKJSWf4IEOasVVrknXpaBV0IApz/gp7S2bb7Z4Lljbl2MGJRqInZiUrQwV16cpzw/D3S5j5Julj/gT52AA==",
+            "funding": [
+                {
+                    "type": "github",
+                    "url": "https://github.com/sponsors/fastify"
+                },
+                {
+                    "type": "opencollective",
+                    "url": "https://opencollective.com/fastify"
+                }
+            ],
+            "license": "BSD-3-Clause"
+        },
+        "node_modules/js-yaml": {
+            "version": "4.1.1",
+            "resolved": "https://registry.npmjs.org/js-yaml/-/js-yaml-4.1.1.tgz",
+            "integrity": "sha512-qQKT4zQxXl8lLwBtHMWwaTcGfFOZviOJet3Oy/xmGk2gZH677CJM9EvtfdSkgWcATZhj/55JZ0rmy3myCT5lsA==",
+            "license": "MIT",
+            "dependencies": {
+                "argparse": "^2.0.1"
+            },
+            "bin": {
+                "js-yaml": "bin/js-yaml.js"
+            }
+        },
+        "node_modules/json-schema-traverse": {
+            "version": "1.0.0",
+            "resolved": "https://registry.npmjs.org/json-schema-traverse/-/json-schema-traverse-1.0.0.tgz",
+            "integrity": "sha512-NM8/P9n3XjXhIZn1lLhkFaACTOURQXjWhV4BA/RnOv8xvgqtqpAX9IO4mRQxSx1Rlo4tqzeqb0sOlruaOy3dug==",
+            "license": "MIT"
+        },
+        "node_modules/require-from-string": {
+            "version": "2.0.2",
+            "resolved": "https://registry.npmjs.org/require-from-string/-/require-from-string-2.0.2.tgz",
+            "integrity": "sha512-Xf0nWe6RseziFMu+Ap9biiUbmplq6S9/p+7w7YXP/JBHhrUDDUhwa+vANyubuqfZWTveU//DYVGsDG7RKL/vEw==",
+            "license": "MIT",
+            "engines": {
+                "node": ">=0.10.0"
+            }
+        }
+    }
+}
diff --git a/tooling/package.json b/tooling/package.json
new file mode 100644
index 0000000..2b366cd
--- /dev/null
+++ b/tooling/package.json
@@ -0,0 +1,17 @@
+{
+    "name": "did-rubric-tooling",
+    "version": "0.0.1",
+    "description": "DID Rubrics",
+    "private": true,
+    "dependencies": {
+      "ajv": "^8.6.3",
+      "js-yaml": "^4.1.0"
+    },
+    "type": "module",
+    "scripts": {
+      "generate-rubric": "node ./src/generate-rubric.js",
+      "validate-rubric": "node ./src/validate-rubric.js"
+    },
+    "author": "Will Abramson <will@legreq.com>",
+    "license": "W3C"
+  }
\ No newline at end of file
diff --git a/tooling/src/did-criteria.yml b/tooling/src/did-criteria.yml
new file mode 100644
index 0000000..1680abf
--- /dev/null
+++ b/tooling/src/did-criteria.yml
@@ -0,0 +1,131 @@
+---
+title: DID Criteria Entry
+description: This schema defines the shape of criteria entries in the DID rubric
+type: object
+additionalProperties: false
+required:
+  - name
+  - id
+  - version
+  - source
+  - question
+  - response
+  - relevance
+  - assessmentTemplate
+properties:
+  name:
+    description: https://www.w3.org/TR/did-rubric/#criteria-name
+    type: string
+  id:
+    description: https://www.w3.org/TR/did-rubric/#criteria-id
+    type: string
+  version:
+    description: https://www.w3.org/TR/did-rubric/#criteria-version
+    type: string
+  source:
+    description: https://www.w3.org/TR/did-rubric/#criteria-source
+    type: string
+  question:
+    description: https://www.w3.org/TR/did-rubric/#criteria-question
+    type: object
+    additionalProperties: false
+    required:
+      - question
+    properties:
+      question:
+        description: The main question text
+        type: string
+      instruction:
+        description: Additional instructions for answering the question
+        type: string
+  response:
+    description: The response structure defining how answers are structured
+    type: object
+    additionalProperties: true
+    # required:
+      # - type
+    properties:
+      type:
+        description: The type of response, typically "multipleChoice"
+        type: string
+      possibleResponses:
+        description: An array of possible response options
+        type: array
+        items:
+          type: object
+          additionalProperties: false
+          required:
+            - label
+            - meaning
+          properties:
+            label:
+              description: The label for the response option (e.g., "A", "B", "C", "D")
+              type: string
+            meaning:
+              description: The meaning or description of what this response option represents
+              type: string
+  relevance:
+    description: https://www.w3.org/TR/did-rubric/#criteria-relevance
+    type:
+      - string
+  assessmentTemplate:
+    description: Template structure for how assessments are presented
+    type: object
+    additionalProperties: true
+    properties:
+      columns:
+        description: Array of column definitions for the assessment table
+        type:
+          - array
+        items:
+          type: object
+          additionalProperties: false
+          required:
+            - heading
+            - type
+            - propertyRef
+          properties:
+            heading:
+              description: The column heading text
+              type: string
+            type:
+              description: The type of column (e.g., "method", "enhancedLetter", "note")
+              type: string
+            propertyRef:
+              description: The property reference for this column (e.g., "method", "spec", "net", "reg", "note", "score")
+              type: string
+  exampleAssessments:
+    description: Example assessments demonstrating how different DID methods score on this criteria
+    type: array
+    items:
+      type: object
+      additionalProperties: true
+      required:
+        - id
+        - method
+        - evaluationCitation
+      properties:
+        id:
+          description: Unique identifier for this example assessment
+          type: string
+        method:
+          description: The DID method being assessed (e.g., "did:web", "did:btcr")
+          type: string
+        spec:
+          description: Assessment score for the specification aspect
+          type: string
+        net:
+          description: Assessment score for the network aspect
+          type: string
+        reg:
+          description: Assessment score for the registry aspect
+          type: string
+        score:
+          description: Overall assessment score (used when spec/net/reg breakdown is not applicable)
+          type: string
+        note:
+          description: Additional notes explaining the assessment
+          type: string
+        evaluationCitation:
+          description: Citation reference to the evaluation source
+          type: string
diff --git a/tooling/src/generate-rubric.js b/tooling/src/generate-rubric.js
new file mode 100644
index 0000000..4793159
--- /dev/null
+++ b/tooling/src/generate-rubric.js
@@ -0,0 +1,85 @@
+#!/usr/bin/env node
+import { promises as fs } from "fs";
+import path from "path";
+import { CRITERIA_ROOT, RUBRIC_OUTLINE_FILE, OUTPUT_FILE, loadAllCriteria, readJson } from "./utils.js";
+
+
+async function buildRubric(criteriaIndex) {
+  const outline = await readJson(RUBRIC_OUTLINE_FILE);
+
+  if (!outline || typeof outline !== "object" || !Array.isArray(outline.categories)) {
+    throw new Error(`Rubric outline must be an object with "categories": [] at ${RUBRIC_OUTLINE_FILE}`);
+  }
+
+  const hydratedCategories = [];
+  for (const cat of outline.categories) {
+    if (!cat || typeof cat !== "object") {
+      throw new Error(`Each category must be an object. Got: ${JSON.stringify(cat)}`);
+    }
+    if (typeof cat.name !== "string" || !cat.name.trim()) {
+      throw new Error(`Each category must have a non-empty "name" string.`);
+    }
+
+    // Expect outline to contain "criteria" as an array of criterion ids
+    const criteriaRefs = Array.isArray(cat.criteria) ? cat.criteria : Array.isArray(cat.criteriaIds) ? cat.criteriaIds : null;
+
+    if (!Array.isArray(criteriaRefs)) {
+      throw new Error(
+        `Category "${cat.name}" must have a "criteria" array of criterion ids (e.g. ["crit-1", "crit-2"]).`
+      );
+    }
+
+    const hydratedCriteria = criteriaRefs.map((critId) => {
+      if (typeof critId !== "string" || !critId.trim()) {
+        throw new Error(`Invalid criterion id in category "${cat.name}": ${String(critId)}`);
+      }
+      const item = criteriaIndex[critId];
+      if (!item) {
+        throw new Error(
+          `Category "${cat.name}" references unknown criterion id "${critId}". Ensure "${critId}" exists in ${CRITERIA_ROOT}`
+        );
+      }
+      // shallow clone to avoid accidental shared references
+      return JSON.parse(JSON.stringify(item));
+    });
+
+    hydratedCategories.push({
+      name: cat.name,
+      description: cat.description ?? "",
+      criteria: hydratedCriteria,
+    });
+
+    console.log(`Built category "${cat.name}" with ${hydratedCriteria.length} criteria.`);
+  }
+
+  const hydrated = { categories: hydratedCategories };
+
+
+  // Target file has prefix to set up rubricJson variable in valid javascript
+  const outputContent = `var rubricJson = ${JSON.stringify(hydrated, null, 2)}`
+  await fs.writeFile(OUTPUT_FILE, outputContent + "\n", "utf8");
+
+   console.log(
+    `Wrote hydrated rubric -> ${path.relative(process.cwd(), OUTPUT_FILE)}`
+  );
+}
+
+async function main() {
+  // Ensure criteria root exists
+  try {
+    const stat = await fs.stat(CRITERIA_ROOT);
+    if (!stat.isDirectory()) throw new Error("not a directory");
+  } catch {
+    throw new Error(`Criteria directory not found: ${CRITERIA_ROOT}`);
+  }
+
+  const criteriaIndex = await loadAllCriteria(CRITERIA_ROOT);
+
+  // Build rubric.json using outline + index
+  await buildRubric(criteriaIndex);
+}
+
+main().catch((err) => {
+  console.error(err.stack || err.message || err);
+  process.exit(1);
+});
diff --git a/tooling/src/render-criteria.js b/tooling/src/render-criteria.js
new file mode 100644
index 0000000..38dfbe9
--- /dev/null
+++ b/tooling/src/render-criteria.js
@@ -0,0 +1,107 @@
+
+
+async function renderCategories() {
+  const {document} = window;
+  const criteriaSection = document.getElementById('criteria');
+
+  if (!criteriaSection) {
+    console.warn('No criteria section found');
+    return;
+  }
+
+  if (!rubricJson) {
+    console.error('No rubricJSON variable found, have you run npm run generate-rubric?');
+    return;
+  }
+  const rubric = rubricJson;
+
+  let categoriesHtml = rubric.categories.map(category => {
+    return `<section class="category-section">
+                <h3>${category.name}</h3>
+                <p>${category.description}</p>
+                ${(category.criteria || []).map(criteria => renderCriteria(criteria)).join('')}
+            </section>`
+  }).join('');
+
+  criteriaSection.innerHTML = `<h2>The criteria</h2>` + categoriesHtml;
+
+}
+
+
+
+
+function renderCriteria(criteria) {
+
+    let criteriaIdFragment = criteria.id.split('#')[1];
+    // TODO: Add ID to this html element so you can link to it.
+    return `
+        <section class="criteria">
+           <h4 id="${criteriaIdFragment}">${criteria.name}</h4>
+           <a href="#${criteriaIdFragment}">${criteria.id}</a>
+           <span>v${criteria.version}</span>
+
+            ${(criteria.source && criteria.source !== ".") ? `
+            <div class="source">
+                <p>Source: <a href="${criteria.source}">${criteria.source}</a></p>
+            </div>
+            ` : ''}
+
+
+            <section>
+            <h5>Question</h5>
+            <p>${criteria.question.question}</p>
+            ${criteria.question.instruction ?
+                `<p><span>Instruction:</span>${criteria.question.instruction}</p>`
+            : ``}
+            </section>
+
+            ${criteria.response && criteria.response.possibleResponses ?
+            `<section>
+                <h5>Responses</h5>
+                <ul class="responses" style="list-style-type: none; padding: 0;">
+                ${criteria.response.possibleResponses.map(response => `
+                    <li><span class="response-label">${response.label}:</span> ${response.meaning || ''}</li>
+                `).join('')}
+                </ul>
+            </section>` : ''}
+
+            ${criteria.relevance &&
+            `<section>
+                <h5>Relevance</h5>
+                <p>${criteria.relevance}</p>
+            </section>`}
+
+            ${criteria.exampleAssessments && criteria.exampleAssessments.length > 0 ? `<section>
+            <h5>Examples</h5>
+            <table>
+            <thead>
+                <tr>
+                ${criteria.assessmentTemplate && criteria.assessmentTemplate.columns ? criteria.assessmentTemplate.columns.map(column => `<th>${column.heading}</th>`).join('') : ''}
+                </tr>
+            </thead>
+            <tbody>
+                ${criteria.exampleAssessments.map(assessment => `
+                <tr>
+                    ${criteria.assessmentTemplate && criteria.assessmentTemplate.columns ? criteria.assessmentTemplate.columns.map(column => {
+                    let contents = assessment[column.propertyRef] || '';
+                    if (column.propertyRef === 'note' && assessment.evaluationCitation) {
+                        let evalCitation = `[<a href="${assessment.evaluationCitation}">${assessment.evaluationCitation.slice(1)}</a>]`
+
+                        contents += ` ${evalCitation}`;
+                    }
+
+                    return `<td>${contents}</td>`;
+                    }).join('') : ''}
+                </tr>
+                `).join('')}
+            </tbody>
+            </table>
+
+            </section>` : ''}
+
+        </section>
+        `
+
+}
+
+window.renderCategories = renderCategories;
\ No newline at end of file
diff --git a/tooling/src/utils.js b/tooling/src/utils.js
new file mode 100644
index 0000000..151123e
--- /dev/null
+++ b/tooling/src/utils.js
@@ -0,0 +1,54 @@
+import { promises as fs } from "fs";
+import path from "path";
+
+export const RUBRIC_ROOT = path.resolve(process.cwd(), "../rubric");
+export const CRITERIA_ROOT = path.resolve(RUBRIC_ROOT, "criteria");
+export const RUBRIC_OUTLINE_FILE = path.join(RUBRIC_ROOT, "rubric-outline.json");
+export const OUTPUT_FILE = path.join(RUBRIC_ROOT, "rubric.js");
+
+export function isJsonFile(name) {
+  return name.toLowerCase().endsWith(".json");
+}
+
+export async function readJson(filePath) {
+  const raw = await fs.readFile(filePath, "utf8");
+  return JSON.parse(raw);
+}
+
+export async function loadAllCriteria(dirPath) {
+  const entries = await fs.readdir(dirPath, { withFileTypes: true });
+
+  const jsonFiles = entries
+    .filter((e) => e.isFile() && isJsonFile(e.name))
+    .map((e) => e.name);
+
+  const index = Object.create(null);
+
+  for (const filename of jsonFiles) {
+    const fullPath = path.join(dirPath, filename);
+    let parsed;
+    try {
+      parsed = await readJson(fullPath);
+    } catch (e) {
+      throw new Error(`Failed to read/parse JSON: ${fullPath}\n${e.message}`);
+    }
+
+    if (typeof parsed !== "object" || parsed === null) {
+      throw new Error(`Criteria file must contain a JSON object: ${fullPath}`);
+    }
+
+    if (typeof parsed.id !== "string" || !parsed.id.trim()) {
+      throw new Error(`Criteria file must have a non-empty "id" string: ${fullPath}`);
+    }
+
+    const id = parsed.id;
+    if (Object.prototype.hasOwnProperty.call(index, id)) {
+      throw new Error(`Duplicate criteria id "${id}" found in ${fullPath}`);
+    }
+
+    index[id] = parsed;
+  }
+
+  return index;
+}
+
diff --git a/tooling/src/validate-rubric.js b/tooling/src/validate-rubric.js
new file mode 100644
index 0000000..9c4f20a
--- /dev/null
+++ b/tooling/src/validate-rubric.js
@@ -0,0 +1,104 @@
+#!/usr/bin/env node
+import { promises as fs } from "node:fs";
+import path from "path";
+import Ajv from "ajv";
+import yaml from "js-yaml";
+import { CRITERIA_ROOT, RUBRIC_OUTLINE_FILE, loadAllCriteria, readJson } from "./utils.js";
+
+async function validateRubric() {
+  // Ensure criteria root exists
+  try {
+    const stat = await fs.stat(CRITERIA_ROOT);
+    if (!stat.isDirectory()) throw new Error("not a directory");
+  } catch {
+    throw new Error(`Criteria directory not found: ${CRITERIA_ROOT}`);
+  }
+
+  // Load schema
+  const schemaPath = path.join(process.cwd(), "src/did-criteria.yml");
+  const schemaYaml = await fs.readFile(schemaPath, "utf8");
+  const schema = yaml.load(schemaYaml);
+  const ajv = new Ajv({ strict: false });
+  const validate = ajv.compile(schema);
+
+  // Load all criteria
+  const criteriaIndex = await loadAllCriteria(CRITERIA_ROOT);
+  console.log(`Loaded ${Object.keys(criteriaIndex).length} criteria files.`);
+
+  // Validate each criteria against schema
+  const invalidCriteria = [];
+  for (const [critId, criterion] of Object.entries(criteriaIndex)) {
+    const valid = validate(criterion);
+    if (!valid) {
+      invalidCriteria.push({ id: critId, errors: validate.errors });
+    }
+  }
+
+  if (invalidCriteria.length > 0) {
+    console.error(`\n❌ Schema validation failed: ${invalidCriteria.length} criteria are invalid:`);
+    for (const { id, errors } of invalidCriteria) {
+      console.error(`  - ${id}`);
+      for (const error of errors) {
+        console.error(`    ${error.instancePath || "/"} ${error.message}`);
+      }
+    }
+    process.exit(1);
+  }
+
+  console.log(`✅ Schema validation passed: All ${Object.keys(criteriaIndex).length} criteria are valid.`);
+
+  // Load template
+  const template = await readJson(RUBRIC_OUTLINE_FILE);
+  if (!template || typeof template !== "object" || !Array.isArray(template.categories)) {
+    throw new Error(`Template must be an object with "categories": [] at ${RUBRIC_OUTLINE_FILE}`);
+  }
+
+  // Collect all referenced criteria IDs
+  const referencedIds = new Set();
+  for (const cat of template.categories) {
+    if (!cat || typeof cat !== "object") {
+      throw new Error(`Each category must be an object. Got: ${JSON.stringify(cat)}`);
+    }
+
+    const criteriaRefs = Array.isArray(cat.criteria) ? cat.criteria : Array.isArray(cat.criteriaIds) ? cat.criteriaIds : null;
+
+    if (!Array.isArray(criteriaRefs)) {
+      throw new Error(
+        `Category "${cat.name}" must have a "criteria" array of criterion ids.`
+      );
+    }
+
+    for (const critId of criteriaRefs) {
+      if (typeof critId !== "string" || !critId.trim()) {
+        throw new Error(`Invalid criteria id in category "${cat.name}": ${String(critId)}`);
+      }
+      referencedIds.add(critId);
+    }
+  }
+
+  console.log(`Found ${referencedIds.size} unique criteria referenced in template.`);
+
+  // Check that all referenced criteria exist
+  const missingIds = [];
+  for (const critId of referencedIds) {
+    if (!criteriaIndex[critId]) {
+      missingIds.push(critId);
+    }
+  }
+
+  if (missingIds.length > 0) {
+    console.error(`\n❌ Validation failed: ${missingIds.length} referenced criteria are missing:`);
+    for (const missingId of missingIds) {
+      console.error(`  - ${missingId}`);
+    }
+    process.exit(1);
+  }
+
+  console.log(`\n✅ Validation passed: All ${referencedIds.size} referenced criteria are present.`);
+}
+
+validateRubric().catch((err) => {
+  console.error(err.stack || err.message || err);
+  process.exit(1);
+});
+