Versions Compared

Version Old Version 7 New Version Current
Changes made by

Drummond Reed

Drummond Reed

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Version: Working Draft 0102

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

...

That is the purpose of the did:scid method.

Examples

NOTE: The first two examples are based on the verification metadata formats defined by the did:webvh and did:webs methods, both of which have the constraint of being valid did:web DID. By contrast, a did:scid is not a valid did:web DID because it does not include any location information in the DID itself (the location information is only in a did:scid URL parameter).

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 Webvh method is adapted to become a did:scid:vh method. At a minimum it would cover:

  1. How the did:scid:vh method-specific-id is generated;

  2. How the 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:

  1. How the DID controller can store the 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.

...

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. 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:

  1. How the did:scid:vh method-specific-id is generated;

  2. 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=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:

did:scid:ke:3:EKYGGh-FtAphGmSZbsuBs_t4qpsjYJ2ZqvMKluq9OxmPexample.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 the 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.

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:prke: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.

...

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

Existing SCIDs

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

Why did:scid?

While all the DID methods listed above are based on Although these all share the benefits of using 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—a requirement for 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 alone be able to serve as a permanent immutable account identifier (for more about this requirement, see Appendix B).

...

#

Segment

Purpose

1

did

URI scheme as required by W3C DID 1.0

2

scid

DID method name

3

scidmethod-methodtype-name

SCID method type name

4

ver

SCID method type version

5

method-specific-id

SCID value

...

did-scid           = "did:scid:" scidmethod-methodtype-name ":" ver ":" method-specific-id

scid-method-name   = 1*method-charmethod-type-name   = 1*method-type-char

method-type-char   = %x61-7A / DIGIT

ver                = 1*DIGIT

method-char        = %x61-7A / DIGITmethod-specific-id = *( *idchar ":" ) 1*idchar

...

The value of the method-specific-id component MUST be a self-certifying identifier that is fully whose binding to the verification metadata is cryptographically verifiable using only 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. If the For each such did:scid 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

...

method types

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 method types.  As with DID methods, there is no limit to the number of did:scid methods method types. However, authors SHOULD NOT create a new did:scid method type if:

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

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

did:scid method type specifications

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

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

    1. This specification.

    2. W3C Decentralized Identifiers (DIDs) 1.0.

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

  4. The did:scid method type 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 type names

NOTE: The recommendations in this section are based on a simple this rationale: there is no good reason to have a large number of did:scid methods method types. In essence, all a did:scid method type needs to define is: a) how the method-specific-ID is generated, b) how the verification metadata, including the verifiable history, is formatted, and c) how the method is self-certifyingcertification is performed. Since cryptographic agility can be supported by versioning an existing did:scid method type, it is in the best interests of everyone to have a small number of very widely supported did:scid methods method types.

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

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

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

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

did:scid method type 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. In any case, for a did:scid method type, a single digit version identifier plus the colon delimiter adds only two characters to the DID.

  1. A did:scid method type 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 methods 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.

  4. did:scid:pr:2 — uses ​did:peer, variant 2.

  5. did:scid:pr:3 — uses ​did:peer, variant 3.

  6. did:scid:pr:4 — uses ​did:peer, variant 4.

...

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

IMPORTANT: When the verifiable history 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.

...

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

Any did:scid DID 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 DID 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 DID can meet all both of these requirements:

...

For Bluesky, there is always a known context—the verifiable history for the did:scid DID 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 DID 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 who shares Bluesky requirements. In other words, if a service provider wants to be able to “always resolve” a did:scid DID 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 providers to avoid duplicity issues. The service providers provider's 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 can immediately trigger revocation of that did:scid DID.

Appendix D: Blockchain support using did:cheqd

...

Using this approach, a did:scid DID 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 DID 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 DID which can be migrated to different infrastructure:

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

...

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 . See below how cheqd would work as a ledger of verifiable history updates below:

...