Version: Working Draft 01

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.

Examples

did:scid Webvh Example

The first example is a DID that uses version 1 of the Webvh did:scid method. The other four are example did:scid URLs that show three different web servers and one blockchain (cheqd) where the verifiable history may be found as defined by the did:webvh method.

did:scid:vh:1:QmfGEUAcMpzo25kF2Rhn8L5FAXysfGnkzjwdKoNPi615XQ

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

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

did:scid WebS Example

These are the same five examples except they use the (hypothetical) version 3 of the KERI AID specification. The did:scid URLs show where the DID document and the KERI event stream may be found as defined by the did:webs specification.

did:scid:ke:3:EKYGGh-FtAphGmSZbsuBs_t4qpsjYJ2ZqvMKluq9OxmP

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

did:scid:ke:3:EKYGGh-FtAphGmSZbsuBs_t4qpsjYJ2ZqvMKluq9OxmP?src=did:cheqd:testnet:4eb6bfaf-fb88-4396-aa78-b54809df01cd

did:scid Peer Example

This example uses one of the variants of the did:peer method (indicated with different did:scid method version numbers in these examples, though they could also be different did:scid method names). Because did:peer assumes local storage, the value of the src parameter is a single dot (for “current directory”).

did:scid:pr:2:2.Vz6Mkj3PUd1WjvaDhNZhhhXQdz5UnZXmS7ehtx8bsPpD47kKc.Ez6LSg8zQom395jKLrGiBNruB9MM6V8PWuf2FpEy4uRFiqQBR.SeyJ0IjoiZG0iLCJzIjp7InVyaSI6Imh0dHA6Ly9leGFtcGxlLmNvbS9kaWRjb21tIiwiYSI6WyJkaWRjb21tL3YyIl0sInIiOlsiZGlkOmV4YW1wbGU6MTIzNDU2Nzg5YWJjZGVmZ2hpI2tleS0xIl19fQ.SeyJ0IjoiZG0iLCJzIjp7InVyaSI6Imh0dHA6Ly9leGFtcGxlLmNvbS9hbm90aGVyIiwiYSI6WyJkaWRjb21tL3YyIl0sInIiOlsiZGlkOmV4YW1wbGU6MTIzNDU2Nzg5YWJjZGVmZ2hpI2tleS0yIl19fQ?src=.

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 some source for the verification metadata, i.e., the DID document and the key event history. 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, aka 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.

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

Existing SCIDs

This is a non-exhaustive list of cryptographically verifiable identifiers based on SCIDs:

• did:peer

• KERI AIDs (autonomic identifiers)

• did:webs

• did:webvh

• did:jlinc

Why did:scid?

While all the identifiers above are based on SCIDs, they have the following limitations:

1. did:peer assumes peer-to-peer usage, and thus does not include a mechanism for discovery of the location of verification metadata, which is a requirement of most publicly verifiable DIDs.

2. KERI AIDs require an out-of-band introduction (OOBI) to establish initial exchange of the verification metadata.

3. 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 be able to serve as a permanent immutable account identifier (for more about this requirement, see Appendix B).

Requirements

1. A did:scid MUST be fully cryptographically verifiable using only the verifiable history metadata.

2. A did:scid 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 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 even if the location of the verification metadata changes.

4. A did:scid MUST be able to support storing the verification metadata in multiple locations.

5. A did:scid 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 carried 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:

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:" scid-method-name ":" ver ":" method-specific-id

scid-method-name   = 1*method-char

ver                = 1*DIGIT

method-char        = %x61-7A / 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 that is fully cryptographically verifiable using only the verifiable history 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 name

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

Example:

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

alsoKnownAs property

This section is normative.

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 SHOULD include one entry for each did:scid URL that identifies a different location for the verification metadata.

2. If the DID in a did:scid URL listed in the The alsoKnownAs property matches the DID document id property value, then 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 is 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 methods

This section is normative.

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

did:scid method specifications

1. A did:scid method MUST have a written specification.

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

   1. This specification.

   2. W3C Decentralized Identifiers (DIDs) 1.0.

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

4. The did:scid method specification SHOULD be assigned its own did:scid DID using that method (“identifier dogfooding”).

5. As described in Appendix B.8 of W3C Decentralized Identifiers 1.0, the DID document resolved by the did:scid DID whose DID subject is the did:scid method specification SHOULD have an alsoKnownAs property containing at least one value that is the canonical URL for the did:scid method specification.

did:scid method names

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

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

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

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

did:scid method 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 valuable. This practice also supports cryptographic agility as newer and better cryptographic algorithms are developed. In any case, a single digit version identifier plus the colon delimiter adds only two characters to the DID.

1. A did:scid 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 Registry

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 Servers

Because it is designed to be fully portable, a did:scid can have its verifiable history written to any number of target locations.

When these locations are web servers designed explicitly to accept verifiable history updates securely (e.g., by verifying the signature of each update), we can call this a DID server. 

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

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

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

That way Bluesky can have its cake and eat it too. A did:scid 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 is always a known context—the verifiable history for the did:scid on their own DID server. Even better, Bluesky gets to completely control the performance, redundancy, scalability, etc. of that resolution option. At the same time, the did:scid controller still has a fully portable DID they can take to any other DID server anywhere anytime.

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

Note: this policy also enables that service provider to avoid duplicity issues. The service providers own DID server will always be authoritative for the ​​verifiable history for the did:scid on which they are relying. If the DID controller writes conflicting update records to that DID server, the service provider could immediately trigger revocation of that did:scid.

Appendix D: Blockchain support using did:cheqd

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

As such, this section shows how to use the cheqd blockchain as a DID Server, 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 can point to the initial verifiable history log on cheqd.

1. The SCID and verifiable history log 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. When publishing the verifiable history 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 verifiable history 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 verifiable history log, a did:scid can be derived. For example:

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

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

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

While the verifiable history in this particular DID example is stored on cheqd, owing to the nature of did:scid, the DID Documents and associated verifiable history 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 verifiable history log on cheqd. 

Additionally, a relying party will be able to check any updates to the verifiable history log, as cheqd provides the functionality of a “microledger” for resource versions, see below how cheqd would work as a ledger of verifiable history updates below:

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