Introduction

This page describes resolution architecture for the did:scid DID method. This architecture differs slightly from standard DID resolution architecture because did:scid is a metamethod that works with other self-certifying identifier (SCID) based DID methods as described in the DID SCID Method Specification.

DID SCID resolution options

Per the DID SCID Method Specification, there are three options for resolution:

1. Peer-to-peer. There is no src parameter; verification metadata is exchanged directly between the peers.

2. Web-based. A DID resolver uses the src parameter to retrieve the verification metadata from a web server.

3. Blockchain-based. A DID resolver uses the src parameter to retrieve the verification metadata from a blockchain, DHT, or other DID-addressable data store.

Option #1: Peer-to-peer resolution

This option does not involve an external DID resolver as resolution is implicit in the peer-to-peer protocol between the two DID controllers (e.g., DIDComm, TSP, etc.) Both the initial exchange of verification metadata and subsequent updates to the verification metadata are exchanged via a trust task over that protocol.

When verification metadata is received by a peer, the process of verifying it against the SCID is identical to the verification process specified by the source DID method specification. Therefore this process should be able to reuse the verification code from a DID resolver module for the source DID method.

Option #2: Web-based resolution

If the value of the src parameter is a URL (either relative or absolute), then a DID resolver invokes its did:scid resolution module to take the following steps:

1. Parse the did:scid DID URL to extract:

   1. The did:scid format type (to determine the source DID method).

   2. The SCID.

   3. The value of the src parameter (a URL).

2. Follow the source DID method specification to compose the source DID from the SCID and the src parameter value. Note: this is a fully deterministic algorithmic transformation.

3. Call the source DID method resolution module to resolve the source DID.

4. The source DID resolution module:

   1. Resolves the source DID to retrieve the verification metadata.

   2. Verifies the verification metadata exactly as specified in the source DID method specification. No changes to the code of the source DID method resolution module are needed.

5. The source DID method resolution module hands the result back to the did:scid resolution module.

6. The did:scid resolution module returns the result.

In summary, the did:scid resolution module only performs one simple algorithmic transformation and then hands off the source DID to the source DID resolution module to resolve exactly as it normally would, with no code changes.

Examples

did:webvh format

Example did:scid DID:

did:scid:vh:1:QmfGEUAcMpzo25kF2Rhn8L5FAXysfGnkzjwdKoNPi615XQ?src=my.name.me

Applying the algorithmic transformation, the resulting did:webvh DID would be:

did:webvh:QmfGEUAcMpzo25kF2Rhn8L5FAXysfGnkzjwdKoNPi615XQ:my.name.me

The did:webvh DID is resolved to retrieve the verification metadata and verified exactly as defined by the did:webvh DID Method Specification.

did:webs format

Example did:scid DID:

did:scid:ke:1:12124313423525?src=w3c-ccg.github.io

Applying the algorithmic transformation, the resulting did:webs DID would be:

did:webs:w3c-ccg.github.io:12124313423525

The did:webs DID is resolved to retrieve the verification metadata and verified exactly as defined by the DID Method did:webs Specification .

did:jlinc format

TODO

Option #3: Blockchain-based resolution

With blockchain-based storage of the verification metadata, there are two sub-options.

Suboption #1: Full DID URL

If the value of the src parameter is a full DID URL, then a the did:scid resolution module takes the following steps:

1. It parses the did:scid DID URL to extract:

   1. The SCID.

   2. The DID from the DID URL.

   3. The remainder of the DID URL. 

2. It calls the appropriate DID resolution module to resolve the DID.

3. It follows the appropriate blockchain specification to dereference the remainder of the DID URL to retrieve the verification metadata.

4. It returns the verification metadata to the did:scid resolution module.

5. The did:scid resolution module calls the source DID method resolution module with the SCID and the verification metadata as parameters (NOTE: this requires support for this option in the source DID method resolution module).

6. The source DID method resolution module verifies the SCID against the verification metadata.

7. The source DID method resolution module returns the result to the did:scid resolution module.

8. The did:scid resolution module returns the result.

Examples

TODO

Suboption #2: Algorithmic DID URL

This suboption supports shorter, simpler did:scid DIDs than suboption #1. With this suboption:

1. The value of the src parameter MUST be a DID.

2. The relevant DID method specification MUST define an algorithmic transformation from a did:scid DID URL to the full DID URL required in suboption #1.

The processing steps are identical to suboption #1 except for the first step. Instead of that first step, the did:scid resolution module would do the following :

1. Parse the did:scid DID URL to extract:

   1. The SCID.

   2. The DID value of the src parameter

2. Call the appropriate DID method resolution module with the SCID and the DID as parameters to request the algorithmic transformation into a DID URL.

3. The DID method resolution module performs the algorithmic transformation as defined in its DID method specification.

4. The DID resolution module returns the DID URL to the did:scid resolution module.

5. The did:scid resolution module proceeds from step #2 in suboption #1 above.

Examples

TODO

Experiment using did:scid:vh

@Markus Sabadello created this working “source DID” did:webvh example:

did:webvh:QmPEQVM1JPTyrvEgBcDXwjK4TeyLGSX1PxjgyeAisdWM1p:gist.githubusercontent.com:brianorwhatever:9c4633d18eb644f7a47f93a802691626:raw

(Click here to resolve via Universal Resolver)

The corresponding did:scid form of this would be:

did:scid:vh:1:QmPEQVM1JPTyrvEgBcDXwjK4TeyLGSX1PxjgyeAisdWM1p?src=gist.githubusercontent.com%2Fbrianorwhatever%2F9c4633d18eb644f7a47f93a802691626%2Fraw

The location of the verifiable history is (try opening it in the browser):

https://gist.githubusercontent.com/brianorwhatever/9c4633d18eb644f7a47f93a802691626/raw/did.jsonl

Now let’s move the same verifiable history to a new location (try to open it in the browser):

https://gist.githubusercontent.com/peacekeeper/2a0e3e9b87819a38555273a3f2c5bd2c/raw/did.jsonl

Then the did:scid form changes as follows (same DID, different src parameter):

did:scid:vh:1:QmPEQVM1JPTyrvEgBcDXwjK4TeyLGSX1PxjgyeAisdWM1p?src=gist.githubusercontent.com%2Fpeacekeeper%2F2a0e3e9b87819a38555273a3f2c5bd2c%2Fraw

Then the corresponding “source DID” did:webvh would be as follows:

did:webvh:QmPEQVM1JPTyrvEgBcDXwjK4TeyLGSX1PxjgyeAisdWM1p:gist.githubusercontent.com:peacekeeper:2a0e3e9b87819a38555273a3f2c5bd2c:raw

(Click here to resolve via Universal Resolver)

Note however one problem in this experiment: In the did:webvh method, the domain name is included in the verifiable history, which is used to construct the resolved DID document. This means that if we resolve the second “source DID” in this experiment, the resulting DID document still contains the first (original) “source DID”. This behavior is not conformant with the W3C DID spec, which requires that the id property of the resolved DID document must match the DID that is being resolved. See discussion in did:webvh spec repo:

Spec doesn't specify that a Resolver MUST return an error when DID being resolved not in DIDDoc · Issue #191 · decentralized-identity/didwebvh