That is the purpose of the did:scid method.

Why Another DID Method?

TODO — this new section of the spec was proposed on the Technology Stack WG call on 2025-02-04. The goal is to draft it by 2025-02-06.

We needed several capabilities that have been provided by many other DID Methods, but all known implementations did not separate these architectural concerns:

self-certifying: …
versioning: …
location-independent: The did:scid is not tied to any particular location. It works on its own, without location
location-binding: A did:scid can be bound to a location (e.g. website, blockchain/ledger, file, etc.) but does not require a location-binding

Examples

NOTE: The first two sets of examples in this section are based on the verification metadata formats defined by the did:webvh and did:webs methods, both of which are web-based DID methods that use SCIDs. While did:scid supports storing verification metadata on a web server, it is not strictly a web-based DID method because: a) it does not include any web location information in the DID itself (only in a did:scid URL parameter), and b) did:scid supports storing verification metadata in other locations, including blockchains, DHTs, and local storage in peer-to-peer usages.

did:scid Webvh Example

Examples in this section are based on the current specification for the did:webvh method.

IMPORTANT: Although the Webvh method is the underlying basis, these examples are based on a (currently hypothetical) did:scid:vh method specification. This would be a separate specification (or perhaps an appendix to the did:webvh method specification) that specifies how the did:webvh method is adapted to become a did:scid:vh method. At a minimum this did:scid:vh method specification would cover:

How the did:scid:vh method-specific-id is generated;
How the did:webvh DID documents and verifiable history file is portable.

The first example is a “pure” did:scid DID because it does not include any location parameter. This is the format of a did:scid DID when used in peer-to-peer exchange where the location information is implicit for both peers.

did:scid:vh:1:QmfGEUAcMpzo25kF2Rhn8L5FAXysfGnkzjwdKoNPi615XQ

The next three examples are did:scid URLs that show three different web servers where the verifiable history may be retrieved as specified by the did:webvh method.

did:scid:vh:1:QmfGEUAcMpzo25kF2Rhn8L5FAXysfGnkzjwdKoNPi615XQ?src=example.com/allan

did:scid:vh:1:QmfGEUAcMpzo25kF2Rhn8L5FAXysfGnkzjwdKoNPi615XQ?src=my.name.me

did:scid:vh:1:QmfGEUAcMpzo25kF2Rhn8L5FAXysfGnkzjwdKoNPi615XQ?src=did.company.info/employee/abc

The final example is a did:scid URL that shows how the verification metadata could also be retrieved via another DID method that uses a blockchain.

IMPORTANT: This example illustrates that a blockchain-based DID method could be modified to support did:scid DIDs by specifying:

How the DID controller can store the did:scid verification metadata on the blockchain.
How a DID resolver can use the did:scid DID to look up and retrieve the verification metadata from the blockchain.

This example uses a hypothetical modified version of the cheqd DID method that specifies: 1) how the did:scid DID could be used as the namespace component of a did:cheqd DID, and 2) how to retrieve the did:scid DID verification metadata from the cheqd blockchain.

did:scid:vh:1:QmfGEUAcMpzo25kF2Rhn8L5FAXysfGnkzjwdKoNPi615XQ?src=did:cheqd

did:scid WebS Example

These are the same five examples as above except they use the (hypothetical) version 3 of the KERI AID specification. The first example shows how a did:scid:ke DID would be used in peer-to-peer mode where the verification metadata location is implicit.

did:scid:ke:3:EKYGGh-FtAphGmSZbsuBs_t4qpsjYJ2ZqvMKluq9OxmP

The next three did:scid:ke URLs show where the DID document and the KERI event stream may be found on a web server as defined by the did:webs specification.

did:scid:ke:3:EKYGGh-FtAphGmSZbsuBs_t4qpsjYJ2ZqvMKluq9OxmP?src=example.com/allan

did:scid:ke:3:EKYGGh-FtAphGmSZbsuBs_t4qpsjYJ2ZqvMKluq9OxmP?src=my.name.me

did:scid:ke:3:EKYGGh-FtAphGmSZbsuBs_t4qpsjYJ2ZqvMKluq9OxmP?src=did.company.info/
employee/abc

The final example shows how a did:scid:ke DID could store its verification metadata on the cheqd blockchain (again, assuming a modified version of the cheqd DID method that supports did:scid DIDs as described above):

did:scid:ke:3:EKYGGh-FtAphGmSZbsuBs_t4qpsjYJ2ZqvMKluq9OxmP?src=did:cheqd

did:scid Peer Example

This example uses variant #2 of the did:peer method. As with the first two examples above, did:peer assumes local storage, so there is no need for the src parameter.

did:scid:pr:2:2.Vz6Mkj3PUd1WjvaDhNZhhhXQdz5UnZXmS7ehtx8bsPpD47kKc.Ez6LSg8zQom395jKLrGiBNruB9MM6V8PWuf2FpEy4uRFiqQBR.SeyJ0IjoiZG0iLCJzIjp7InVyaSI6Imh0dHA6Ly9leGFtcGxlLmNvbS9kaWRjb21tIiwiYSI6WyJkaWRjb21tL3YyIl0sInIiOlsiZGlkOmV4YW1wbGU6MTIzNDU2Nzg5YWJjZGVmZ2hpI2tleS0xIl19fQ.SeyJ0IjoiZG0iLCJzIjp7InVyaSI6Imh0dHA6Ly9leGFtcGxlLmNvbS9hbm90aGVyIiwiYSI6WyJkaWRjb21tL3YyIl0sInIiOlsiZGlkOmV4YW1wbGU6MTIzNDU2Nzg5YWJjZGVmZ2hpI2tleS0yIl19fQ

Motivations & Design Considerations

Benefits of SCIDs

...

A SCID does require reliance on a third party for verification because the SCID is cryptographically bound to the cryptographic keys from which it was generated. However, verification does require access to the verification metadata, i.e., the DID document and the key event history. (Note: In peer-to-peer usage of SCIDs, that verifiable history can be stored locally by each peer.)

...

A SCID is fully portable, meaning it is not bound to any particular location for the verification metadata.

...

The verification metadata for a SCID can be written to multiple locations to increase resilience. For example, a did:scid method can be used peer-to-peer, on a web server, on a blockchain, or any other storage target.

...

SCIDs can work with any type of repository for the verification metadata: web servers, blockchains, trust registries, databases, file systems, etc.

...

SCIDs can work equally well for private DIDs and public DIDs.

...

SCIDs improve security because:

The binding between the public/private key pair and the SCID happens entirely within a digital wallet or cryptographic key store.
Each version of the verification metadata (e.g., DID document and key event history) can include a hash of the previous version and be digitally signed to form a cryptographically verifiable event log, also known as a “hashchain” or “microledger”.
Storing the verification metadata in multiple locations makes it harder to attack, particularly if SCIDs are used in conjunction with the ToIP High Assurance VIDs Specification.

...

Given that nearly 200 different DID methods have been registered with the W3C DID Methods Registry, it begs the question, “Why another DID method”. There are three main reasons.

#1: Self-Certifying Identifiers (SCIDs)

Because a SCID is is cryptographically bound to the cryptographic keys from which it was generated, it does not require reliance on a third party for verification. All that is required to verify this binding is access to the verification metadata (the DID document and the key event history). Note that, if a SCID is used in peer-to-peer relationship, the verification metadata can be stored locally by each peer.

#2: Portability and Location Independence

Because a SCID is bound directly to its verification metadata, the SCID is fully portable, meaning it is not bound to any particular location for the verification metadata. For example, a did:scid DID can be used peer-to-peer, on a web server, on a blockchain, or any other storage target. The verification metadata can even be written to multiple locations to increase resilience. Any type of repository can be used to store the verification metadata: web servers, blockchains, trust registries, databases, file systems, etc.

#3: Privacy and Security

Because the cryptographic binding between the SCID and the verification metadata can be generated entirely within a digital wallet, secure element, or HSM, the generation phase can be both very secure and very private. This means SCIDs can work equally well for public DIDs and private DIDs.

SCIDs can further improve privacy for individuals because they are lightweight enough to support pairwise private DID connections, enabling DID applications used by individuals to automatically use pairwise pseudonyms and encrypted private channels for communications.

SCIDs can further improve security because:

Each new version of the verification metadata (e.g., DID document and key event history) can include a hash of the previous version. By digitally signing the new version, this forms a cryptographically verifiable event log, also known as a “hashchain” or “microledger”.
Storing the verification metadata in multiple locations can make it harder to attack, particularly if SCIDs are used in conjunction with the ToIP High Assurance VIDs Specification.

Examples

NOTE: The first two sets of examples in this section are based on the verification metadata formats defined by the did:webvh and did:webs methods, both of which are web-based DID methods that use SCIDs. While did:scid supports storing verification metadata on a web server, it is not strictly a web-based DID method because: a) it does not include any web location information in the DID itself (only in a did:scid URL parameter), and b) did:scid supports storing verification metadata in other locations, including blockchains, DHTs, and local storage in peer-to-peer usages.

did:scid Webvh Example

Examples in this section are based on the current specification for the did:webvh method.

IMPORTANT: Although the Webvh method is the underlying basis, these examples are based on a (currently hypothetical) did:scid:vh method specification. This would be a separate specification (or perhaps an appendix to the did:webvh method specification) that specifies how the did:webvh method is adapted to become a did:scid:vh method. At a minimum this did:scid:vh method specification would cover:

How the did:scid:vh method-specific-id is generated;
How the did:webvh DID documents and verifiable history file is portable.