Versions Compared

Key

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

...

That is the purpose of the did:scid method.

Why

...

Another DID Method?

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

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

  • self-certifying:

  • versioning:

  • location-independent: The did:scid is not tied to any particular location. It works on its own, without location

  • location-binding: A did:scid can be bound to a location (e.g. website, blockchain/ledger, file, etc.) but does not require a location-binding

...

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.

...

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 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 Webvh did:webvh DID documents and verifiable history file is portable.

...

#

Segment

Purpose

1

did

URI scheme as required by W3C DID 1.0

2

scid

DID method name

3

scidmethod-type-name

SCID method type name

4

ver

SCID method type version

5

method-specific-id

SCID value

...

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

scidmethod-type-name   = 1*method-type-char

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

ver                = 1*DIGITtype-char        = %x61-7A / DIGIT

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

...

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 method types.  As with DID methods, there is no limit to the number of did:scid 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 rationale: there is no good reason to have a large number of did:scid 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 type is self-certifying. 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 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 DID 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 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 type specification and/or implementation.

...

  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

...