Versions Compared

Version Old Version 8 New Version 9
Changes made by

Drummond Reed

Drummond Reed

Saved on

Key

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

...

#

Segment

Purpose

1

did

URI scheme as required by W3C DID 1.0

2

scid

DID method name

3

scid-methodtype-name

SCID method type name

4

ver

SCID method type version

5

method-specific-id

SCID value

...

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

scid-methodtype-name   = 1*methodtype-char

ver                = 1*DIGIT

methodtype-char        = %x61-7A / DIGIT

...

  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

...

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 types.  As with DID methods, there is no limit to the number of did:scid methods 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

...

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

...

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

...

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 type, a single digit version identifier plus the colon delimiter adds only two characters to the DID.

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

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

  3. Version numbers MUST increment.

Appendix A: did:scid

...

Type Registry

TODO: Add did:scid methods 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.

...

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

...

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:

...