/
DID SCID Method Specification

DID SCID Method Specification

Owned by Drummond Reed
Last updated: yesterday at 3:04 pm
14 min read

Version: Working Draft 03

Authors: Drummond Reed, Markus Sabadello, Jonathan Rayback, Alex Tweeddale

Table of Contents

Introduction

did:scid is a new DID method designed to maximize the security, privacy, and portability benefits of self-certifying identifiers (SCIDs). Here is the definition of a SCID in the ToIP Glossary:

A subclass of verifiable identifier (VID) that is cryptographically verifiable without the need to rely on any third party for verification because the identifier is cryptographically bound to the cryptographic keys from which it was generated.

By this definition, a SCID does not necessarily need to be a decentralized identifier (DID) as defined by the W3C Decentralized Identifiers (DIDs) 1.0 specification. However, there are many advantages to defining a DID method devoted exclusively to SCIDs, independent of the specific type of SCID. 

That is the purpose of the did:scid method which is a deliverable of the ToIP DID SCID Task Force.

NOTE: did:scid is technically a DID method specification because it defines a DID method namespace. However it is a metamethod because it defines a standard set of capabilities for other SCID-based DID methods called source DID methods. Each source DID method defines a did:scid format. Resolution and verification of a did:scid DID is designed to use the resolution and verification code of the source DID method as described in the DID SCID Resolution Overview.

Why another DID method?

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. The only requirement to verify the 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, with a web server, with a blockchain, or any other storage target. The verification metadata can even be written to multiple locations to increase resilience—a technique called multi-anchoring. 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. This enables 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 cryptographic event log, also known as a hashchain or microledger.

  • Storing the verification metadata in multiple locations—multi-anchoring—can make it harder to attack, particularly if SCIDs are used in conjunction with the ToIP High Assurance VIDs Specification.

Why support multiple formats?

The advantages of SCIDs have led to the development of multiple SCID-based DID methods. The first one, did:peer, is still the default DID method used in DIDComm. However, did:peer assumes peer-to-peer usage, and thus does not include a mechanism for discovery of the location of verification metadata—a requirement for most publicly-verifiable DIDs. did:peer also does not support key rotation.

Several newer SCID-based DID methods now support a full range of DID features including key rotation, pre-rotation, and multi-sig. These include:

did:webs and did:webvh are web-based DID methods where the DID is bound to the location of a specific web server. While some degree of portability is still possible by using the DID document alsoKnownAs property to establish synonyms with other DIDs, this design does not support the requirement for the DID alone be able to serve as a permanent immutable account identifier (for more about this requirement, see Appendix B).

did:jlinc is now being adapted for use with a federated network of servers to increase portability. However it is not currently designed for peer-to-peer usage.

did:scid can address all of these limitations without requiring new formats for SCIDs or SCID verification metadata. It can reuse the formats listed above. While in theory did:scid could choose to support only one of these formats, picking one would discriminate against the others. Since all three have their adherents—and existing code bases that support them—did:scid is designed to support all three, and be extensible to support other SCID-based formats if necessary. This enables adopters to choose the SCID format that works best for them, and for these formats to evolve over time.

Examples

NOTE: The first two sets of examples in this section are based on the SCIDs and verification metadata formats defined by the did:webvh and did:webs methods, both of which are web-based DID methods. 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.

The first example is a “pure” did:scid DID because it does not include any location parameter. This is the format 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 showing 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:

  1. How the DID controller can store did:scid verification metadata on the blockchain.

  2. How a DID resolver can use the did:scid DID to look up and retrieve the verification metadata from the blockchain using DID Linked Resources. See the DID SCID Resolution Overview for more.

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 unique-id 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:testnet

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 location of the verification metadata 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:testnet

did:scid Peer Example

NOTE: This example is intended to show how a peer-to-peer DID method such as did:peer could be used as a did:scid method format. However, creation of a did:scid:pr method is NOT proposed because both of the previous examples (did:scid:vh and did:scid:ke) can also be used peer-to-peer and both support key rotation and other security features not currently included in did:peer.

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

Requirements

  1. A did:scid DID MUST be a self-certifying identifier (SCID) that is fully cryptographically verifiable using only the verification metadata (which may be any combination of DID documents and other verification files).

  2. A did:scid DID MUST be able to serve as a permanent immutable account identifier, i.e., it must not need to change if the DID controller changes the location of the verification metadata.

  3. A did:scid DID MUST be fully portable, i.e., the DID controller must be able to:

    1. Choose the location(s) for the verifiable history (subject to policy constraints that may be imposed by a relying party).

    2. Continue using the did:scid DID even if the location of the verification metadata changes.

  4. A did:scid DID MUST be able to support storing the verification metadata in multiple locations (“multi-anchoring”).

  5. A did:scid DID MUST meet all the other requirements of a DID as specified in W3C Decentralized Identifiers (DIDs) 1.0.

Syntax

This section is normative.

The design of did:scid separates the SCID from the verification metadata location. The DID is a “pure SCID” that will never need to change. The verification metadata location is conveyed in a standard query parameter of a did:scid URL.

did:scid

A did:scid consists of five colon-delimited segments as summarized in table 1:

#

Segment

Purpose

1

did

URI scheme as required by W3C DID 1.0

2

scid

DID method name

3

format-name

Short name identifying the format

4

ver

Format version

5

method-specific-id

SCID value

A did:scid  MUST conform to the following ABNF (most of which is identical to section 3.1 of W3C Decentralized Identifiers 1.0):

did-scid           = "did:scid:" format-name ":" ver ":" method-specific-id

format-name = 1*format-char

format-char    = %x61-7A / DIGIT

ver                = 1*DIGIT

method-specific-id = *( *idchar ":" ) 1*idchar

idchar = ALPHA / DIGIT / "." / "-" / "_" / pct-encoded

pct-encoded = "%" HEXDIG HEXDIG

The value of the method-specific-id component MUST be a self-certifying identifier whose binding to the verification metadata is cryptographically verifiable using only the verification metadata.

did:scid URL

A did:scid URL MUST conform to the following ABNF:

did-scid-URL = did-scid path-abempty [ "?" [ "src=" source ] query ]
[ "#" fragment ]
source = 1*( pchar / "/" / "?" )

Any ABNF rules that are not defined above are defined in RFC 3986.

With this ABNF, the only difference between a did:scid URL and a standard DID URL is that a did:scid URL takes an optional query parameter called src (for “source”).

The src (“source”) parameter

This section is normative.

The purpose of the src parameter is to supply the location information a DID resolver needs to locate the verification metadata. There are two options for the value of this parameter.

Absolute or relative URL

The first option is a URL, which may be either absolute or relative.

  1. If a URL is used, a relative URL is RECOMMENDED.

  2. If a relative URL is used:

    1. The base URL MUST be assumed to be https://

    2. It is NOT RECOMMENDED for the relative URL to include its own query or fragment component.

Examples:

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

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

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

DID method

The second option is to use a DID method. If this option is used, the specification for the target DID method MUST support storage and lookup/retrieval of the verification metadata for a did:scid.

This example assumes a hypothetical modified version of the cheqd DID method (discussed here on the DID SCID Resolution Overview page) that specifies: 1) using the did:scid DID as the unique-id component of a did:cheqd DID as specified in the Syntax section of the did:cheqd method, and 2) how to retrieve the did:scid DID verification metadata from the cheqd blockchain:

did:scid:vh:1:f3ad7beb1abc4a26b892466df4379a51?src=did:cheqd:testnet

alsoKnownAs property

This section is normative.

IMPORTANT: The requirements in this section apply only to values of the alsoKnownAs property in a DID document that contain the same did:scid DID as the DID document itself. These requirements DO NOT apply to any other values of the alsoKnownAs property.

For a did:scid method, the alsoKnownAs property of a DID document as specified in W3C Decentralized Identifiers 1.0 is a means for discovering other locations of the verification metadata.

  1. The alsoKnownAs property of a DID document for a did:scid DID SHOULD include one entry for each did:scid DID URL that identifies a different location for the verification metadata.

  2. For each such did:scid URL, the verification metadata at the location identified by the src parameter value of that did:scid URL has the following requirements:

    1. The values of all versions of the verification metadata that are present in all locations MUST be equivalent.

    2. One or more of the locations MAY have a newer version of the verification metadata than the other locations.

The latter requirement avoids a race condition for the DID controller when synchronizing updates to the verification metadata for a did:scid DID.

did:scid formats

This section is normative.

Like the did: scheme defined in W3C Decentralized Identifiers (DIDs) 1.0, did:scid is a scheme for did:scid formats.  As with DID methods, there is no limit to the number of did:scid formats. However, authors SHOULD NOT create a new did:scid format if:

  1. A current did:scid format provides all required functionality, OR

  2. A revision to a current did:scid format could add the required new functionality.

did:scid format specifications

  1. A did:scid format MUST have a written specification, either published independently or as an Appendix to this specification.

  2. The did:scid format specification MUST meet all the requirements in:

    1. This specification.

    2. W3C Decentralized Identifiers (DIDs) 1.0.

  3. The did:scid format specification SHOULD be available via a canonical URL.

did:scid format names

NOTE: The recommendations in this section are based on the rationale that there is no good reason to have a large number of did:scid formats. All SCID-based DID methods work basically the same way. Since cryptographic agility can be supported by versioning an existing did:scid format, it is in the best interests of everyone to have a small number of very widely supported did:scid formats.

did:scid method type names have the same ABNF as DID method names.

  1. It is RECOMMENDED to keep did:scid format names as short as possible.

  2. By convention, did:scid format names SHOULD consist of exactly two characters.

  3. This specification SHALL maintain a registry of did:scid format names in Appendix A.

did:scid format version identifiers

Although W3C Decentralized Identifiers (DIDs) 1.0 does not require DID methods to have version identifiers, practical usage has shown they can be quite valuable, especially to support cryptographic agility as newer and better cryptographic algorithms are developed, especially for post-quantum cryptography (PQC). In any case, for a did:scid format, a single digit version identifier plus the colon delimiter adds only two characters to the DID.

  1. A did:scid format MUST have a version number.

  2. The version number MUST be one or more digits.

  3. Version numbers MUST increment.

Appendix A: did:scid Method Type Registry

TODO: Add did:scid method types (which of course need their own specs). Proposed entries:

  1. did:scid:ke — uses the ​did:webs verification metadata format.

  2. did:scid:vh — uses the ​did:webvh verification metadata format.

  3. did:scid:jl — uses ​did:jlinc verification metadata format.

NOTE: did:peer is not included in this list for the reasons explained above—all of these did:scid method types can be used peer-to-peer and all offer more features and security than did:peer.

Appendix B: Bluesky DID Requirements

In December 2024, Bryan Newbold of Bluesky sent the following list of requirements to the DIF DID Method Standardization WG with this list of requirements of DIDs for Bluesky account holders:

  1. Low and predictable marginal cost at scale (millions of accounts): as an example, SMS verification of user accounts can be prohibitively expensive for service providers, even when costing well under a US dollar per account

  2. Ability to create and update identifiers rapidly (within seconds, ideally under a second)

  3. Key rotation is a must

  4. Reliable and predictable-latency operation, both for updating identifiers and resolving them (the "tail latency" of resolution is important)

  5. Identifiers are long-lived and continue to function after periods of inactivity

  6. Resolution should not require additional state or context, and "new" resolvers can independently resolve all "old" identifiers

  7. DIDs are permanent and immutable account identifiers

Bryan’s email concluded:

The last two requirements make most forms of "DID migration" very difficult to implement with AT Protocol. It is not feasible to re-write DIDs, because they are included in URIs which get included in content-addressed data records. Keeping track of aliases or DID history out of band would mean that a newly-instantiated client or service would be missing history, and would not be able to successfully resolve the same DIDs as an established service. We took it as an invariant that account identity is one-to-one with a permanent DID string.

Appendix C: DID Hosts

Because it is designed to be fully portable, a did:scid DID can have its verification metadata written to any number of target locations (“multi-anchoring”).

IMPORTANT: When the verifiable metadata of a did:scid DID is written to multiple locations, this may raise data synchronization challenges. Responsibility for those challenges lies with each did:scid method type specification and/or implementation.

Because location independence is a key feature of the did:scid method, we need a location-independent term for the different types of data repositories that could store verification metadata and respond to did:scid DID resolution requests, i.e., web servers, blockchains, DHTs, trust registries, etc. We propose to call this a DID host. 

With did:scid, Bluesky’s requirements could be met if Bluesky implemented this policy:

Any did:scid DID used by Bluesky MUST have its verification metadata published to at least one designated Bluesky DID host (for example “did.bsky.social”).

In other words, a did:scid DID can still be 100% portable—the owner can move it anywhere they want any time they want and keep their full verification metadata—BUT if they want to use it with Bluesky, the owner must agree to let Bluesky host at least one copy of their verification metadata on Bluesky’s DID host.

That way Bluesky can have its cake and eat it too. A did:scid DID can meet all both of these requirements:

  1. DIDs are permanent and immutable account identifiers.

  2. Resolution should not require additional state or context, and "new" resolvers can independently resolve all "old" identifiers”.

For Bluesky, there would always a known context—the verification metadata for the did:scid DID on their own DID host. Even better, Bluesky can completely control the performance, redundancy, scalability, etc. of that resolution option. At the same time, the did:scid DID controller still has a fully portable DID they can take to any other DID host anywhere anytime.

This policy also works for any service provider who shares Bluesky’s requirements. In other words, if a service provider wants to be able to “always resolve” a did:scid DID regardless of what other DID hosts the DID controller currently uses, the site can make it part of their terms-of-service that the DID controller must publish their verification metadata to that service provider’s designated DID host.

NOTE: This policy also enables service providers to avoid duplicity issues. The service provider's own DID host will always be authoritative for the ​​verification metadata for the did:scid DID upon which they are relying. If the DID controller writes conflicting update records to that DID host, the service provider can immediately trigger revocation of that did:scid DID.

Appendix D: Blockchain support using did:cheqd

One of the benefits of did:scid is that the verification metadata may be stored on multiple different types of technical infrastructure, including blockchains. A blockchain is an excellent tool for storing the verification metadata due to its immutable nature, tamper-resistance and high availability. 

As such, this section shows how to use the cheqd blockchain as a DID host, based on the description in Appendix B. 

Through the use of cheqd’s DID-Linked Resource functionality, cheqd is able to store sequentially ordered, indexable and historically queryable JSON files that are both cryptographically verifiable and tamper-resistant. 

Using this approach, a did:scid DID can point to the initial verifiable history log on cheqd.

  1. The SCID and verification metadata are generated using the same process as defined in the did:webvh or KERI AID specifications

  2. Once generated, the initial verifiable history JSON file is published as a DID-Linked Resource on cheqd. For example:

    1. did:cheqd:testnet:9cdea85b-7524-4962-ad11-c943b8303692?resourceName=didScidExample&resourceType=didScidLogEntry&resourceVersionTime=2025-01-23T07:17:26Z

    2. (Using cheqd DID Resolver) https://resolver.cheqd.net/1.0/identifiers/did:cheqd:testnet:9cdea85b-7524-4962-ad11-c943b8303692?resourceName=didScidExample&resourceType=didScidLogEntry&resourceVersionTime=2025-01-23T07:17:26Z

    3. (using DIF Universal Resolver) https://dev.uniresolver.io/1.0/identifiers/did:cheqd:testnet:9cdea85b-7524-4962-ad11-c943b8303692?resourceName=didScidExample&resourceType=didScidLogEntry&resourceVersionTime=2025-01-23T07:17:26Z

  3. When publishing the verification metadata JSON file on cheqd, the controller MUST also publish the following metadata to enable the file to be queried:

    1. resourceName: Any arbitrary string, naming the file

    2. resourceType: MUST be didScidLogEntry

  4. The controller MAY also publish the following optional metadata:

    1. alternativeUri: A string or array specifying alternative locations where the initial verification metadata log is also published

    2. resourceVersion: To enable more granular querying by a specific version name or number

  5. The DID-Linked Resource SHOULD be signed using the same keys specified in the “authentication” section of the DID Document, ensuring cryptographic verifiability back to the controller of the DID Document.

  6. Using this persistent identifier for the initial verification metadata, a did:scid DID can be derived. For example:

    1. did:scid:ke:3:EKYGGh-FtAphGmSZbsuBs_t4qpsjYJ2ZqvMKluq9OxmP?src=did:cheqd:testnet:9cdea85b-7524-4962-ad11-c943b8303692

    2. Including a portable did:scid DID which can be migrated to different infrastructure:

      1. did:scid:ke:3:EKYGGh-FtAphGmSZbsuBs_t4qpsjYJ2ZqvMKluq9OxmP

While the verification metadata in this particular DID example is stored on cheqd, owing to the nature of did:scid, the DID Documents and associated verification metadata can be stored and updated elsewhere, such as on a web server. This is because the SCID can always be decoded by a relying party to dereference back to the initial verification metadata on cheqd. 

Additionally, a relying party will be able to check any updates to the verification metadata as cheqd provides the functionality of a “microledger” for resource versions. See below for how cheqd would work as a ledger of verification metadata updates:

https://resolver.cheqd.net/1.0/identifiers/did:cheqd:testnet:9cdea85b-7524-4962-ad11-c943b8303692?resourceName=didScidExample&resourceType=didScidLogEntry&resourceMetadata=true

 

Related content