Versions Compared

Version Old Version 6 New Version 7
Changes made by

Alex Tweeddale

Drummond Reed

Saved on

Key

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

...

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

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 Examples in this section are based on the current specification for the did:webvh method.

did:scid:vh:1:QmfGEUAcMpzo25kF2Rhn8L5FAXysfGnkzjwdKoNPi615XQ

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

...

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

did:scid WebS Example

...

  1. 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:kevh:3:EKYGGh-FtAphGmSZbsuBs_t4qpsjYJ2ZqvMKluq9OxmPdid:scid:ke:3:EKYGGh-FtAphGmSZbsuBs_t4qpsjYJ2ZqvMKluq9OxmP1:QmfGEUAcMpzo25kF2Rhn8L5FAXysfGnkzjwdKoNPi615XQ?src=example.com/allan

did:scid:kevh:3:EKYGGh-FtAphGmSZbsuBs_t4qpsjYJ2ZqvMKluq9OxmP1:QmfGEUAcMpzo25kF2Rhn8L5FAXysfGnkzjwdKoNPi615XQ?src=my.name.me

did:scid:kevh:3:EKYGGh-FtAphGmSZbsuBs_t4qpsjYJ2ZqvMKluq9OxmP1:QmfGEUAcMpzo25kF2Rhn8L5FAXysfGnkzjwdKoNPi615XQ?src=did.company.info/
employee/abc

The final example is a 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:

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:

...

#

...

Segment

...

Purpose

...

1

...

did

...

URI scheme as required by W3C DID 1.0

...

2

...

scid

...

DID method name

...

3

...

scid-method-name

...

SCID method name

...

4

...

ver

...

SCID method 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:" 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 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 would specify: 1) using the did:scid DID 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:

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.

  • SCIDs can 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.

Existing SCIDs

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

Why did:scid?

While all the DID methods listed 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—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).

Requirements

  1. A did:scid DID MUST be 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.

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

#

Segment

Purpose

1

did

URI scheme as required by W3C DID 1.0

2

scid

DID method name

3

scid-method-name

SCID method name

4

ver

SCID method 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:" 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 verification metadata.

did:scid URL

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

...

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.

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 lookup/retrieval of the verification metadata for a did:scid.

This example assumes a hypothetical modified version of the cheqd DID method that specifies: 1) using the did:scid DID as the namespace 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=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:testnet:9cdea85b-7524-4962-ad11-c943b8303692?resourceName=didScidExample&resourceType=didScidLogEntry&resourceVersionTime=2025-01-23T07:17:26Z

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 did:cheqd

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 value 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. If the 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 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:

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

  2. A revision to a current did:scid method could add the required new 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

...

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

    1. .

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

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

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

NOTE: The recommendations in this section are based on a simple rationale: there is no good reason to have a large number of did:scid methods. In essence, all a did:scid method 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-certifying. Since cryptographic agility can be supported by versioning an existing did:scid method, it is in the best interests of everyone to have a small number of very widely supported did:scid methods.

did:scid method names

...

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

...

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 quite valuable, especially to support 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.

...

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

...