Update the abstract, cleanup the summary

Signed-off-by: Stephen Curran <[email protected]>

spec/abstract.md

@@ -1,21 +1,10 @@
 ## Abstract
 
-`did:web` a useful, simple DID Method that makes deployment easy, and can be
-used to build beautifully on a domain's existing reputation -- or even be
-published content publishing platforms such as GitHub. But `did:web` also
-inherits some of the security flaws of the Web and lacks a specified way to access the
-history of the DID--features that created the initial excitement around
-ledger-based DIDs. For something as important as cryptographic key publishing,
-those missing features can be a problem.
+The evolution of Decentralized Identifiers (DIDs) continues to be a dynamic area of development in the quest for secure and private digital identity management. The `did:web` method, praised for its simplicity and ease of deployment, allows for DIDs to be associated with a domain's reputation or published on platforms like GitHub. However, it is not without its challenges, particularly concerning security vulnerabilities inherited from the web and the absence of a verifiable history for the DID. Addressing these concerns, the proposed `did:tdw` (Trust DID Web) method aims to enhance the `did:web` by introducing a verifiable history feature, akin to what is available with ledger-based DIDs, but crucially, without relying on a ledger. This approach not only maintains backward compatibility but also offers an additional layer of assurance for those requiring more robust verification processes. By publishing the resulting DID as both `did:web` and `did:tdw`, it caters to a broader range of trust requirements, from those who are comfortable with the existing `did:web` infrastructure to those seeking greater security assurances provided by `did:tdw`. This innovative step represents a significant stride towards a more trusted and secure web, where the integrity of cryptographic key publishing is paramount.
 
-We propose a new DID Method that compliments `did:web` that, with a relatively
-simple set of dependencies and processing steps, adds a fully verifiable history
-to a web-based DID such as one might get from a ledger-based DID, but without
-the ledger. For backwards compatibility, and for verifiers that just "trust"
-`did:web`, the resulting DID can be published in parallel as a `did:web` DID. For
-resolvers that want more assurance, `did:tdw` (Trust DID Web) provides a way to
-"trust did:web" (or to enable a "trusted web" if you say it fast), by supporting
-these features:
+The key differences between `did:web` and `did:tdw` revolve around the core issues of decentralization and security. `did:web` is recognized for its simplicity and cost-effectiveness, allowing for easy establishment of a credential ecosystem. However, it is not inherently decentralized as it relies on DNS domain names, which require centralized registries, and it lacks a cryptographically verifiable, tamper-resistant, and persistently stored DID document. In contrast, `did:tdw` (Trust DID Web) is proposed as an enhancement to `did:web`, aiming to address these limitations by adding a verifiable history to the DID without the need for a ledger. This method seeks to provide a more decentralized approach by ensuring that the security of the embedded self-certifying identifier does not depend on DNS. Additionally, `did:tdw` offers a cryptographically verifiable trust registry and status lists, using DID-Linked Resources, which `did:web` lacks. These features are designed to build a trusted web, offering a higher level of assurance for cryptographic key publishing and management.
+
+For backwards compatibility, and for verifiers that just "trust" `did:web`, a `did:tdw` can be trivially modified and published in parallel as a `did:web` DID. For resolvers that want more assurance, `did:tdw` provides a way to "trust did:web" (or to enable a "trusted web" if you say it fast), by supporting these features:
 
 - Ongoing publishing of all DID Document (DIDDoc) versions for a DID instead of, or beside, a `did:web` DID.
 - Uses the same DID-to-HTTPS transformations as `did:web`.
@@ -41,19 +30,18 @@ The following is a `tl;dr` summary of the specification summarizing how `did:tdw
 - The `didlog.txt` is a list of JSON [[ref: DID log entries]], one per line,
   whitespace removed, each of which contains the information needed to derive a
   version of the DIDDoc from its preceding version.
-- Each entry includes JSON entries containing:
-  - A hash of the entry.
-  - The `versionId` of the DIDDoc, starting from 1 and incrementing.
-  - The `versionTime` (as stated by the DID Controller) of the entry.
-  - A set of `parameters` that impact the processing of the current and
+- Each entry includes six JSON entries:
+  1. A hash of the entry.
+  2. The `versionId` of the DIDDoc, starting from 1 and incrementing.
+  3. The `versionTime` (as stated by the DID Controller) of the entry.
+  4. A set of `parameters` that impact the processing of the current and
     future log entries.
-    - Examples parameters are the version of the `did:tdw` specification
-      and the hash algorithm being used by the controller. All available parameters are
-      defined in this specification.
-  - The new version of the DIDDoc as either a `value` (the full document) or a
+       - Example parameters are the version of the `did:tdw` specification
+      and hash algorithm being used.
+  5. The new version of the DIDDoc as either a `value` (the full document) or a
     `patch` derived using [[ref: JSON Patch]] to update the new version from the
     previous entry.
-  - A [[ref: Data Integrity]] (DI) proof across the entry, signed by a DID
+  6. A [[ref: Data Integrity]] (DI) proof across the entry, signed by a DID
     Controller authorized to update the DIDDoc.
 - In generating the first version of the DIDDoc, the DID Controller calculates
   the [[ref: SCID]] for the DID, includes it as a `parameter` in the first log entry, and

spec/specification.md

@@ -118,13 +118,13 @@ To process the retrieved [[ref: DID Log]] file, the resolver **MUST** carry out
    2. `versionId`
    3. `versionTime`
    4. `parameters`
-   5. DIDDoc content -- either the full `value` or a [[ref: JSON Patch]] `patch`
+   5. DIDDoc content -- either the full `value` or a [[ref: JSON Patch]] `patch` to be applied to the prior version of the DIDDoc.
    6. A Data Integrity proof over the entry.
 2. For each entry:
    1. Update the currently active [[ref: parameters]] with the parameters from the entry (if any). Continue processing using the now active set of [[ref: parameters]].
    2. Verify that the Data Integrity proof in the entry is valid, and is signed by an authorized key as defined in the [Authorization Keys](#authorization-keys) section of this specification.
-   3. Verify that the `entryHash` for the entry according to the process defined in the [Entry Hash Generation and Verification] section of this specification.
-   4. For the initial version of the DIDDoc (`1`) verify that the [[ref: SCID]] (defined in the [[ref: parameters]]) is being used for the DID as defined in the [SCID Generation and Verification] section of this specification.
+   3. Verify that the `entryHash` for the entry using to the process defined in the [Entry Hash Generation and Verification] section of this specification.
+   4. For the initial version of the DIDDoc (`1`) verify that the [[ref: SCID]] (defined in the [[ref: parameters]]) is being used in the DID, and verifies according to the [SCID Generation and Verification] section of this specification.
    5. Generate the version of the DIDDoc for the entry by using the JSON value of the `value` item, or by using [[ref: JSON Patch]] to apply the JSON value of the `patch` entry item to the previous version of the DIDDoc.
    6. If [[ref: Key Pre-Rotation]] is being used, verify that any added keys in the DIDDoc have a valid pre-rotation entry as defined in the [Key Pre-Rotation Hash Generation and Verification] section of this specification.
    7. Once each version entry has been processed, collect about each version (at least) the following information: