diff --git a/spec/abstract.md b/spec/abstract.md index 843d94a..f7d0e76 100644 --- a/spec/abstract.md +++ b/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 diff --git a/spec/specification.md b/spec/specification.md index e3b839a..a42c389 100644 --- a/spec/specification.md +++ b/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: