You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

Document Status

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

Introduction

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

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.

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

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.

The Resource Parameter

TODO

Normative Requirements

TODO

DID Method Requirements

TODO

DID Specification Registries Entry

TODO

Contributors

To comply with the intellectual property rights protections in the charter of the ToIP Foundation (as required by all Joint Development Foundation projects hosted the Linux Foundation), all contributors to this Pre-Draft Deliverable MUST be current members of the ToIP Foundation. The following contributors each certify that they meet this requirement:

Other contributors MUST also add their name and membership affiliation.

Acknowledgements

TODO










  • No labels