Aller au contenu principal

The did:svdx Method v0.2

A DID Method for SoVereign Data Exchange (SVDX)​

Unofficial Draft October 2024​

Editors:

  • Georg Greve (Vereign AG)
  • Boyan Tsolov (Vereign AG)
  • Lyuben Penkovski (Vereign AG)
  • Zdravko Iliev (Vereign AG)

Abstract​

The SVDX DID Method is a purpose built DID Method for SoVereign Data Exchange (SVDX). It builds upon did:ipid, however did:svdx utilizes IPFS objects instead of IPNS entries.

1. Introduction​

The SVDX DID Method is a purpose built DID Method for SoVereign Data Exchange (SVDX) for a more secure, robust and decentralized exchange of authentic data of any kind. The method has been inspired by both the Interplanetary Identifiers DID method (did:ipid), the KERI Identifiers specification (did:keri) and the did:webs specification building on top of did:web.

We evaluated did:web as a possible solution, and used it in early POCs, but ultimately its architectural security issues are too severe for the intended use case. While did:webs addresses most of these concerns, it depends on a functioning implementation of did:keri at scale, including an existing network of watchers and witnesses, to achieve the security gains.

Implementation of did:keri in early 2024 is yet to be completed, and available only in Python, which we find amazing for many things, but also consider a poor choice for communication protocols that are supposed to scale in production while being maintained and updated for decades to come. Work on implementations in Rust or Golang, our two preferred options, was not a priority, and not very far advanced. This unfortunately ruled out both did:keri and did:webs for our concrete use case.

Since distributed ledgers are not well received by everyone in healthcare, we were looking for an existing system that could serve as trust anchor, was readily available in scalable, maintainable implementations, and had the relative minimum maturity we were looking for. The Interplanetary File System (IPFS) fits this bill, and is a system we've successfully maintained in production for some years now.

Unfortunately, the only existing method on IPFS, did:ipid, builds on top of the Interplanetary Naming System (IPNS), which is the only part of IPFS we've consistently experienced issues with in our usage of the technology. It is too slow for our purposes and suffers from a lack of persistent production security. Specifically there is no way to persist IPNS entries in quite the same way as IPFS objects. For reference, see this discussion thread.

But IPFS itself is perfect for publishing DID documents and already does so in production as part of the Sidetree specification. Simplifying the approach taken by did:keri, this specification uses IPFS in place of witnesses and watchers, and lets IPFS handle the task of distributing and persisting DID documents.

This simplification comes at a cost. did:svdx does not have inbuilt protection against what KERI describes as duplicity, but duplicity detection could be added at application level once there is sufficient scale as it is impossible to hide IPFS entries from only some of the participants. So a simplified watcher system could be retrofitted to the did:svdx network, if required. Native support for weighted multi signatures, which is an intrinsic part of KERI, is also not part of this specification in order to reduce complexity and because it is not (yet?) required for the intended use cases.

Somewhat robust multi-party restoration of did:svdx could however be achieved by did:svdx clients using Shamir's secret sharing for the next key. Currently, this would need to be handled at agent level, which is not ideal, so may result in an update of addendum to this spec. Contributions welcome.

All these downsides are acceptable within our problem space, and come with substantial benefits. The resulting did:svdx combines proven technologies at scale with some of the extremely powerful concepts of KERI, providing persistent autonomous identifiers based on key rotation, agent restoration, and trust provenance.

Our goal for did:svdx was to come up with a solution that follows the principle of "as complex as necessary, but no more." It had to be something simple and robust enough that we could implement within a given time frame, as well as something we felt comfortable maintaining for a long time to come.

2. Terminology​

Content Identifier (CID): A Content Identifer (CID) is a cyptographic identifer that self describes the content-hash itself. The CID includes, a Multibase prefix, the CID version and the multicodec identifer which indicates the format of the target content.

DID: A decentralized identitfier.

DIDComm: A DID to DID communication protocol developed by the Decentralized Identity Foundation (DIF). DIDComm is a generic data transport layer enabling a multitude of  data level protocols which are being made available via didcomm.org. It has inspired design of the the Trust Spanning Protocol developed within the Trust Over IP Foundation as part of a generic internet trust layer. Once complete and implemented, this specification will most likely be updated to utilize the Trust Spanning Protocol instead of DIDComm.

Decentralized System: A system in which lower level components operate on local information to accomplish global goals. For example, an ant colony is a decentralized system as there is no central control determining when food must be collected or how new tunnels should be excavated.

3. Concepts​

3.1. Linked Data (LD)​

JSON-LD is a syntax to serialize Linked Data in JSON and provide semantics without the overhead of a large rdf model.

When using JSON-LD a @context field is specified in the DID document, that is a representation-specific entry*.* The JSON-LD Context is either a string or a list containing any combination of string and/or ordered maps.

Example:

https://w3id.org/security/suites/ed25519-2018/v1
https://www.w3.org/ns/did/v1
https://schema.org

One of the known big issues of @context is that the document it points to may change over time, completely changing the interpretation of the data.

In order to avoid this, when building on top of did:svdx, JSON-LD documents SHOULD always use a @context conforming to the following additional requirements:

3.1.1 Linked Data (LD) @context Content Based Adressing​

All references for @context links to schemata MUST always refer to schemata that comply to Content Based Addressing principles, e.g. file names based upon the hash of the specific schema.

Wherever possible, schemata themselves SHOULD be stored in IPFS, and compose the @context attribute using an IPFS gateway pointing to the specific version of the schema being referenced, as it is stored in IPFS.

These requirements MUST be observed recursively, i.e. schemata stored in IPFS conforming to the above convention MUST NOT include @context attributes NOT adhering to Content Based Addressing principles.

3.2. SVDX Specific Concepts​

Design goals for this specification include the ability to establish persistent identifiers. The specification should enable re-connection in the event of email server or address changes, as well as key rotation to address potential key compromise, device update, and requirements to upgrade the cryptographic primitives in case of new discoveries and/or quantum computing breakthroughs.

3.2.1. IPFS for secure Key Event Chain​

did:svdx maintains a hash-chained data structure from which the Key State of an Identifier can be derived.

Each did:svdx DID Document is stored in IPFS and represents an entry into the Key Event Chain containing the currently used public key along with additional information such as end points. In addition it contains the CID for the previous version of this identifier, if applicable, along with with the key signature for the next key in case of key rotation - see below.

This way did:svdx leverages the multihash based CID mechanism of IPFS for secure hash-chaining of each entry in this Key Event Chain, which can be traversed backward to the original creation of the identifier.

3.2.2. Linking to the next key in rotation​

did:svdx has a nextKey property to allow for cryptographic flexibility, key rotation, and secure recovery.

The nextKey attribute MUST contain the secure cryptographic identifier for the key that will be used for the next entry of the Key Event Chain. It MUST NOT contain the public or private key for the nextKey itself, but provide only the key identifier.

Upon writing the next entry in the Key Event Chain, that entry MUST contain the public key material and SHALL be used exclusively from the moment of publication. Such an entry SHALL also contain the cryptographic identifier for a freshly generated key in its nextKey attribute.

Agents MUST only ever actively use key n published in the latest DID document. nextKey is always key n+1, and keys n-... remain available in the older, linked entries in the Key Event Chain, allowing to verify older signatures and Verifiable Credentials against the key in rotation at the time.

The public key of nextKey MUST never be disclosed anywhere. If it is disclosed deliberately or by accident, it SHOULD > be considered compromised, and a key rotation should be executed as soon as possible to create a fresh nextKey without > public key disclosure.

While this specification may be extended to support multiple nextKey properties, the authors at this time do not see > the need for the associated complexity, and the questions it may rise with regards to split chains and potentially > duplicitous agents. If you require multiple nextKey properties for your use case, please get in touch with the authors.

5. The did:svdx Method Specification​

The format for the did:svdx method conforms to the [DID-CORE] specification. It consists of the did:svdx: prefix, followed by a fingerprint of the initial (inception) public key (as a base58 string) with a 'z' prefix, a single colon as delimiter, and the CID of the immutable DID document stored in IPFS.

The ABNF for the key format is described below:

did-svdx-format := did:svdx:<mb-value>:<ipfs-cid>
mb-value        := z[a-km-zA-HJ-NP-Z1-9]+
ipfs-cid        := [a-km-zA-HJ-NP-Z1-9]+

Example 1: A simple Ed25519 did:svdx value

did:svdx:z6MkwMouGUPuvZ6jZWxtjbhihKfwJ4KXyJEL44TzvEaNhTYh:Qmc5gCcjYypU7y28oCALwfSvxCBskLuPKWpK4qpterKC7z

Where:

  • z6MkwMouGUPuvZ6jZWxtjbhihKfwJ4KXyJEL44TzvEaNhTYh is base58 encode of the initial key with multicodec prefix. In front of the base58 encode is added z Table of multicodec https://github.com/multiformats/multicodec/blob/master/table.csv
  • Qmc5gCcjYypU7y28oCALwfSvxCBskLuPKWpK4qpterKC7z is the IPFS CID of the DID document. This is not stored in the did document itself. As it is a qualifier to where the DID document is stored.

This makes the DID identifier a type of self-certifying identifier, which is cryptographically bound to the inception keys used to create it. The Content Identifier (CID) that results from the IPFS hashing is proof for the immutability and authenticity of the DID Document. Both of those method-specific identifiers ensure uniqueness within the proposed did method as well as global uniqueness.

For the purposes of did:svdx as autonomous identifier, identity and controller are identical. Since controller is optional in the DID specification, the DID document will use id only. The id is cryptographically derived from the inception keys, but since the IPFS CID cannot be known at the time the DID document is being composed, it is not part of identity field.

5.1. Sensitivity and normalization of the method-specific-identifier​

[Section 8.1 of DID-CORE] point 3 reads: ´The DID method specification MUST define sensitivity and normalization of the value of the method-specific-id.´, which seems to be ignored by most DID method specifications. In case of did:svdx, both the identifier itself, and the CID, are hash values derived from key material or documents, and therefore appear random to an outside observer. As a result the did:svdx method is robust against leaking Personally Identifiable Information (PII) in its identifier, and does not in itself allow correlation with a particular entity, person, or device.

did:svdx being designed as a persistent identifier, usage of the same identifier in multiple places will allow correlation of the acting party, but if used correctly, the identity of the acting party will remain protected.

Normalization is provided by the hash functions and CID formats that compose the identifier. All other characters MUST be lower-case.

6. Operations​

6.1. Create​

A did:svdx identifier and document are created by cryptographically and locally deriving the first part of the method specific identifier, which is the id attribute inside the DID Document, then signing the resulting document and adding it to IPFS, which as a result gives the second method specific identifier in the form of a CID.

The fully qualified DID identifier must be represented as three parts: prefix, first method specific identifier (P1) and second method specific identifier (P2)

As the P2 is only generated after writing into ipfs, it's not part of the DID Document, rather it's a qualifier to where the DID Document is.

Examle 2: An example of a did:svdx DID Document

{
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://w3id.org/security/suites/ed25519-2018/v1",
    "https://schema.org"
  ],
  "id": "did:svdx:z6MknHKiY477mH97qryHv3zjuHaTLvBbbp6tHS5SvZv67uR4",
  "verificationMethod": [
    {
      "id": "did:svdx:z6MknHKiY477mH97qryHv3zjuHaTLvBbbp6tHS5SvZv67uR4#z6MknHKiY477mH97qryHv3zjuHaTLvBbbp6tHS5SvZv67uR4",
      "controller": "did:svdx:z6MknHKiY477mH97qryHv3zjuHaTLvBbbp6tHS5SvZv67uR4",
      "type": "Ed25519VerificationKey2018",
      "publicKeyBase58": "8q4fworgRjeejN8bEV2u4C2TXLukBvrXbRAX6Hx5Cgdg"
    }
  ],
  "authentication": [
    "did:svdx:z6MknHKiY477mH97qryHv3zjuHaTLvBbbp6tHS5SvZv67uR4#z6MknHKiY477mH97qryHv3zjuHaTLvBbbp6tHS5SvZv67uR4"
  ],
  "assertionMethod": [
    "did:svdx:z6MknHKiY477mH97qryHv3zjuHaTLvBbbp6tHS5SvZv67uR4#z6MknHKiY477mH97qryHv3zjuHaTLvBbbp6tHS5SvZv67uR4"
  ],
  "keyAgreement": [
    "did:svdx:z6MknHKiY477mH97qryHv3zjuHaTLvBbbp6tHS5SvZv67uR4#z6MknHKiY477mH97qryHv3zjuHaTLvBbbp6tHS5SvZv67uR4"
  ],
  "version": 1,
  "created": "2024-10-24T09:37:02Z",
  "updated": "2024-10-24T09:37:02Z",
  "nextKey": "z6MknHKiY477mH97qryHv3zjuHaTLvBbbp6tHS5SvZv67uR4",
  "proof": [
    {
      "created": "2024-10-24T09:37:02Z",
      "verificationMethod": "did:svdx:z6MknHKiY477mH97qryHv3zjuHaTLvBbbp6tHS5SvZv67uR4#z6MknHKiY477mH97qryHv3zjuHaTLvBbbp6tHS5SvZv67uR4",
      "jws": "eyJhbGciOiJFZERTQSIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..C42gIKLSOJfFKQVKCGTZoRZJY0P0fNlHVIafzkoVRA2Qau0uLxTRjordWRLmriiUSuMqQ3vA1MumWoBgiSJ-CQ"
    }
  ]
}

6.1.1 Document Creation Algorithm​

  1. Generate two sets of public and private key pair, that will be used for inception and next key.
  2. Create identifier P1 as z{base58(multicodec(inception public key))}
  3. Set document.id to P1 identifier. If document.id is not a valid DID, an invalidDid error MUST be raised.
  4. Initialize the verificationMethod property in document to an array where the first value is the signatureVerificationMethod.
  5. Initialize the authentication, assertionMethod, capabilityInvocation properties in document to an array where the first item is the value of the id property in signatureVerificationMethod.
  6. Initialize the @context property in document to the result of passing document and options to Context Creation Algorithm. (this will work with ipfs cids)
  7. Set nextKey field to the z{base58(multicodec(next public key))}
  8. Initialize version, created and updated properties
  9. prevDocument can be set to null or skipped entirely
  10. Sign the document with the current private key
  11. Set the proof property in the document to array and set an object in it with jws from p.11, verificationMethod with the id of the verification method and created which is the current date.
  12. publish the document to ipfs, the resulted CID is P2 identifier
  13. Construct the fully qualified DID identifier as Method Specification
  14. Return document

6.2. Read​

Resolving the did:svdx is accomplished by getting the content from IPFS by providing the CID suffix of the did:svdx method, which is the second method-specific identifier in order (P2).

Example 3: Get svdx Did Document from ipfs gateway

https://ipfs01.blckchn.app/ipfs/QmecqVGBxvW7gjffxmYTGFZNPmJcWmYPdD8azB1cZYaY6F

6.2.1. Document Read Algorithm​

  1. Parse the did URI and extract the CID component from it (the second method-specific identifier, which is the IPFS CID)
  2. Fetch the DID document from IPFS using the extracted CID
  3. Verify the signature on the document in order to prove authenticity. If a verificationMethod for such a purpose is provided, attempt to verify the document proof using the provided method with public keys
  4. Resolve the prevDocument attribute by utilizing steps 1. and 2. for the did:svdx of the said prevDocument document and compare the nextKey attribute of the previous document with the provided public keys for this purpose inside the verificationMethod attribute of the current document. Compare the version number and make sure the prevDocument document is exactly 1 version below the current document.
  5. Should the checks from steps 3. and 4. pass successfully - the document is considered to be authentic and valid within the capabilities of did:svdx, excluding additional cross-checking and specific security requirements for implementations building upon did:svdx.

6.3. Update​

While technically impossible to update a document with the same IPFS CID without the use of IPNS, the update of a did:svdx document is achieved through versioning and creating a new document, based on the previous one. More specifically it is linked through the previous one both by referencing it in prevDocument and using the nextKey that the previous version contains.

Examle 4: An example of updated did:svdx DID Document

{
  "context": [
    "https://www.w3.org/ns/did/v1",
    "https://w3id.org/security/suites/ed25519-2018/v1",
    "https://schema.org"
  ],
  "id": "did:svdx:z6MkvFJLu2huhwGexvuCFMzJ5BYavTLf5vy56Dm5xVxpyaEo",
  "verificationMethod": [
    {
      "id": "did:svdx:z6MkvFJLu2huhwGexvuCFMzJ5BYavTLf5vy56Dm5xVxpyaEo#z6MkjidamoGD6QJtKNLnsE3EuGh4vbDZfVoQg8Amxrp3Y1UH",
      "controller": "did:svdx:z6MkjidamoGD6QJtKNLnsE3EuGh4vbDZfVoQg8Amxrp3Y1UH",
      "type": "Ed25519VerificationKey2018",
      "publicKeyBase58": "6GNYBZ1mkrpRCsW6Bf5Q4B9571wiFcZ3z7Fr8ar2cngu"
    }
  ],
  "authentication": [
    "did:svdx:z6MkvFJLu2huhwGexvuCFMzJ5BYavTLf5vy56Dm5xVxpyaEo#z6MkjidamoGD6QJtKNLnsE3EuGh4vbDZfVoQg8Amxrp3Y1UH"
  ],
  "assertionMethod": [
    "did:svdx:z6MkvFJLu2huhwGexvuCFMzJ5BYavTLf5vy56Dm5xVxpyaEo#z6MkjidamoGD6QJtKNLnsE3EuGh4vbDZfVoQg8Amxrp3Y1UH"
  ],
  "keyAgreement": [
    "did:svdx:z6MkvFJLu2huhwGexvuCFMzJ5BYavTLf5vy56Dm5xVxpyaEo#z6MkjidamoGD6QJtKNLnsE3EuGh4vbDZfVoQg8Amxrp3Y1UH"
  ],
  "version": 2,
  "created": "2024-10-25T14:16:50Z",
  "updated": "2024-10-25T14:16:50Z",
  "prevDocument": "QmPK2s3pNYLi9ERiq3BDxKa4XosgWwFRQUydHUtz4YgpqB",
  "nextKey": "z6Mkva531JAp5s5VsEYqGpVP5SXPqMZ3eGs4hNGhbVFU3Cva",
  "proof": [
    {
      "created": "2024-10-25T14:16:50Z",
      "verificationMethod": "did:svdx:z6MkjidamoGD6QJtKNLnsE3EuGh4vbDZfVoQg8Amxrp3Y1UH#z6MkjidamoGD6QJtKNLnsE3EuGh4vbDZfVoQg8Amxrp3Y1UH",
      "jws": "eyJhbGciOiJFZERTQSIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..5BjE4ZlmQslcBcMfzyEKl7T48GWMMnaO5sSJkzD5_b4eF0oT9qBI9WW7VHWgFLp3EWo15_3eTEpDaXq1Lo-tBg"
    }
  ]
}

6.3.1. Document Update Algorithm​

  1. Parse the current did URI and extract the CID component from it (the second method-specific identifier, which is the IPFS CID)

  2. Fetch the corresponding current did document, from which the nextKey attribute will be used.

  3. Verify the proof attribute to make sure that the current did document originates from the controller being used.

  4. Compare the nextKey attribute from the current document with the key in rotation for the updated version of the document. This is done for consistency and to avoid mismatch between the previously written nextKey and the key in rotation that is about to be used. Misconfigurations and key inconsistency can be mitigated and caught before writing the updated document in IPFS by utilizing this check.

  5. Create the new DID document with new verificationMethod attribute with the new key being used (in other words what nextKey from the previous version represents).

  6. Increment the version number in the document

  7. Referencing the previous DID document in the prevDocument attribute, updating the updated attributed with the new timestamp

  8. Create new nextKey that will be published in the new document for key rotation

  9. Sign the newly created document

  10. Store the resulting updated and signed document in IPFS and retrieve the CID for this document

  11. Construct the new did:svdx by leaving the first method specific identifier (or in other words the id attribute) unchanged and appending the CID from step 9.

The updated did document's id attribute remains unchanged. Here's why:

  • The id attribute serves as a unique identifier for the did:svdx and is related to the inception of the did itself.
  • Changing the id attribute would essentially create a new DID, describing a new entity, breaking continuity and potentially causing confusion or issues with established connections and interactions associated with the original DID.

Instead of modifying the id, the update operation focuses on incrementing the version attribute to track document history, setting prevDocument to the last document and preserving a chain of versions, and updating other attributes based on the provided changes.

By following this approach, the updated document reflects the modifications while maintaining the original DID identity and allowing users to track changes through versioning and the prevDocument attribute.

6.4. Delete​

It's important to note that true deletion is inherently not possible within IPFS: documents uploaded to IPFS remain accessible as long as nodes within the network continue to store them.

By setting nextKey to empty, an updating process will be impossible. Setting the deactivated attribute to true will mark the Did Document as not available for communication, unless keys from older documents are still valid.

Example 5: An example of deleted did:svdx DID Document

{
  "context": [
    "https://www.w3.org/ns/did/v1",
    "https://w3id.org/security/suites/ed25519-2018/v1",
    "https://schema.org"
  ],
  "id": "did:svdx:z6MkvFJLu2huhwGexvuCFMzJ5BYavTLf5vy56Dm5xVxpyaEo",
  "verificationMethod": [
    {
      "id": "did:svdx:z6MkvFJLu2huhwGexvuCFMzJ5BYavTLf5vy56Dm5xVxpyaEo#z6MkjidamoGD6QJtKNLnsE3EuGh4vbDZfVoQg8Amxrp3Y1UH",
      "controller": "did:svdx:z6MkjidamoGD6QJtKNLnsE3EuGh4vbDZfVoQg8Amxrp3Y1UH",
      "type": "Ed25519VerificationKey2018",
      "publicKeyBase58": "6GNYBZ1mkrpRCsW6Bf5Q4B9571wiFcZ3z7Fr8ar2cngu"
    }
  ],
  "authentication": [
    "did:svdx:z6MkvFJLu2huhwGexvuCFMzJ5BYavTLf5vy56Dm5xVxpyaEo#z6MkjidamoGD6QJtKNLnsE3EuGh4vbDZfVoQg8Amxrp3Y1UH"
  ],
  "assertionMethod": [
    "did:svdx:z6MkvFJLu2huhwGexvuCFMzJ5BYavTLf5vy56Dm5xVxpyaEo#z6MkjidamoGD6QJtKNLnsE3EuGh4vbDZfVoQg8Amxrp3Y1UH"
  ],
  "keyAgreement": [
    "did:svdx:z6MkvFJLu2huhwGexvuCFMzJ5BYavTLf5vy56Dm5xVxpyaEo#z6MkjidamoGD6QJtKNLnsE3EuGh4vbDZfVoQg8Amxrp3Y1UH"
  ],
  "version": 3,
  "created": "2024-10-25T14:16:50Z",
  "updated": "2024-10-27T14:16:50Z",
  "prevDocument": "QmPK2s3pNYLi9ERiq3BDxKa4XosgWwFRQUydHUtz4YgpqB",
  "nextKey": null,
  "deactivated": true,
  "proof": [
    {
      "created": "2024-10-25T14:16:50Z",
      "verificationMethod": "did:svdx:z6MkjidamoGD6QJtKNLnsE3EuGh4vbDZfVoQg8Amxrp3Y1UH#z6MkjidamoGD6QJtKNLnsE3EuGh4vbDZfVoQg8Amxrp3Y1UH",
      "jws": "eyJhbGciOiJFZERTQSIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..5BjE4ZlmQslcBcMfzyEKl7T48GWMMnaO5sSJkzD5_b4eF0oT9qBI9WW7VHWgFLp3EWo15_3eTEpDaXq1Lo-tBg"
    }
  ]
}

6.4.1 Document Delete Algorithm​

  1. Perform an Update operation according 6.3 on the Did Document
  2. Set nextKey attribute to null
  3. Set deactivated attribute to true

7. Versioning​

::: info REVIEW:

Question: Is documenting the versioning procedure, rules, or information for this specification document needed? (not the did document)

:::

8. Restore and Recovery​

Restoring and recovering a lost did:svdx SHOULD be handled on application level.

9. Security Considerations​

::: info TODO:

Review consideration - remove or add more:

1. Binding of Identity

2. Authentication Service Endpoints

3. Non-Repudiation

4. Notification of DID document changes

5. Key and Signature Expiration

6. Key Revocation and Recovery

:::

  • DID document signing and verification methods should be compatible with the chosen DID method and secure (e.g., using JSON Web Signature - JWS with appropriate algorithms).
  • Regularly rotate signing keys and update the DID Document accordingly.
  • Strongly consider using IPFS pinning services to ensure document availability and version preservation.
  • Applications MUST take precautions when using versioned DID URIs. If a key is compromised and revoked then it can still be used to issue signatures on behalf of the "older" DID URI. The use of versioned DID URIs is only recommended in some limited situations where the timestamp of signatures can also be verified, where malicious signatures can be easily revoked, and where applications can afford to check for these explicit revocations of either keys or signatures. Wherever versioned DIDs are in use, it SHOULD be made obvious to users that they are dealing with potentially revoked data.

10. Privacy Considerations​

::: info TODO:

Provide privacy considerations:

1. Personal Data Considerations

2. DID Correlation Risks

3. DID Document Correlation Risks

4. DID Subject Classification

5. Herd Privacy

6. Service Privacy

:::