Versions Compared

Key

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

...

This document is a Pre-Draft Deliverable of the ToIP Foundation Technical Stack Working Group

Introduction

TODOThis is a specification for an extension to the W3C Decentralized Identifiers (DIDs) 1.0 specification to support the addition of the resource parameter to the W3C DID Specification Registries 1.0. It specifies the syntax and normative behavior for usage of the parameter and the requirements for DID methods that support the parameter.

Terminology

In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL", when appearing in ALL CAPITALS, are to be interpreted as described in RFC 2119.

All other terms in bold will be defined in one or more terms wikis as part of completing this specification.

Purpose & Motivations

The purpose of this specification is to specify how a DID URL may include a parameter that instructs a DID resolver to request the associated verifiable data registry to  (VDR) to directly return a digital resource identified by a decentralized identifier (DID).

Resolution of a DID and dereferencing of a DID URL (meaning a DID that includes an additional path, query, and/or fragment component as defined by the ABNF in section 3.2 of the DID 1.0 specification) is shown in figure 1 from section 7.2 of the spec:

Image Added

Figure 1: The relationship of DIDs, DID URLs, DID documents, and Resources

The normal pattern for processing a DID URL consists of two steps:

  1. Resolution: Resolving the plain DID (defined by the ABNF from section 3.1 of the DID spec) to a DID document.
  2. Dereferencing: Processing the DID document in order to determine how to dereference the remainder of the DID URL (path, query, fragment, etc.)

The first of these two steps—the DID resolution step—is shown in figure 2.

Image Added

Figure 2: The normal DID resolution process

For a DID URL, the return of the DID document to the resolver commences the second step of dereferencing (the processing of which depends on the DID ).

Motivations

URL and the DID method).

However there is an exception to this normal 2-step process when the DID itself identifies a digital resource that can be returned directly from the VDR of the associated DID method

In this case, the client MAY wish to use a DID URL to return the identified digital resource in a single step as shown in Figure 3:

Image Added

Figure 3: Using a DID URL to request a digital resource in a single step

Note that in this case the DID document is not involved in retrieval of the resource. Rather if a resolver calls a VDR using a DID URL that includes a resource parameter conformant with this specification, the VDR will retrieve the identified digital resource and return that resource to the resolver directly.TODO

The Resource Parameter

TODO

...