...

The normal pattern for processing a 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 the DID document in order to determine how to dereference the remainder of the the DID URL (path, query, fragment, etc.)

...

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  the identified resource based on the portion of the DID URL that follows the DID. An example is processing a DID fragment to return a specific public key from the DID document. How dereferencing operates depends on the DID URL and the DID method).

However an exception to this normal 2-step resolution/dereferencing process is when the DID itself identifies a digital resource that can be returned directly from the VDR of the associated DID method. There are numerous examples of when this This behavior may be desirable:

• When the the DID serves as a persistent identifier of a machine-readable digital resource that the client wishes to consume directly, such as a data schema, interface definition, or policy definition.
• When the the DID serves as a persistent identifier of a human-readable document that needs a long-lived, cryptographically verifiable identifier such as a legal document (e.g., title, deed, will, regulatory filing), a governance framework, or another or a non-fungible token (NFT) or any other type of digital asset.

In this case, the client MAY wish to use a DID URL to request that a DID resolver 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 stepNote that in this case the

Two important notes about this process:

1. The DID document is not

...

1. retrieved by the resolver as part of the

...

1. dereferencing process. Rather

...

1. the resolver

...

1. makes a

...

1. call to the VDR with the DID URL including a resource parameter conformant with this specification

...

1. . The VDR then follows the specification of the associated DID method to retrieve the identified digital resource and return that resource to the resolver directly.
2. The resource parameter serves a different purpose than the alsoKnownAs parameter. The purpose of the alsoKnownAs parameter is to map a DID to an alternative identifier for the same DID subject. This alternative identifier can be any other URI, e.g., a URL, or a URN, or another DID. When the DID is resolved, the value of the alsoKnownAs parameter is returned as a property of the DID document. It is then up to the client to decide what action to take with this alternative identifier. For example, if the value is a URL, the client may choose to dereferencing this URL to retrieve the identified Web resource. In this case, the the alsoKnownAs parameter essentially serves as a redirection mechanism managed by the DID controller. By contrast, the resource parameter:
   1. Does not involve an alternative identifier for the DID subject. The DID is the only identifier needed.
   2. Does not involve any redirection. The DID directly identifies the target digital resource.
   3. Does not require a separate dereferencing step. The DID URL is effectively resolved and dereferenced in one step.

The Resource Parameter

To enable this single-step behavior, this specification defines a DID URL parameter named resource. If a DID method specification supports this parameter, and if a DID URL using that method includes the parameter value resource=true, then when a resolver calls the associated VDR using that DID URL, the VDR returns the identified digital resource, not the DID document.

IMPORTANT: The fact that a digital resource can be returned directly using a A DID URL that includes the resource=true parameter does not mean the DID does not have an associated DID still has an associated DID document like any other DID. It simply means However this DID document is not involved directly in the combined resolution/dereferencing step. If the DID alone is resolved (without the resource=true parameter), it should will still return the associated DID document. There is nothing special about this DID document. It still describes and controls interactions with the identified digital resource just like any other DID document. For example:

...

If the DID document contains one or more alsoKnownAs property values, then it identifies those values still identify other instances of the identified digital resource available via other URIs, URLs, or DIDs or URLs.

Syntax

The parameter name is MUST be resource. The parameter type is MUST be a Boolean , so for which the valid values are true and false. The parameter value of true is MUST be case-sensitive and must MUST be spelled out exactly. No other renderings of true, i.e.  T, TRUE, 1, -1, and so forth — are equivalent.

...

Following is an example DID URL based on the fictional did:example: DID  DID method that includes the resource parameter:

did:example:21tDAKCERh95uGgKbJNHYp?resource=true

...

DID Resolver and Verifiable Data Registry (VDR) Requirements

1. If a DID URL includes the resource parameter with a value of true, a conforming DID resolver MUST return the digital resource identified by the DID from the VDR specified by the associated DID method provided such resource is available. 
2. If the DID resolver is unable to return the identified resource. the resolver MUST return the error "Resource not found".
3. If a DID URL includes the resource parameter with any value other than true (for example, false), a conforming DID resolver SHOULD ignore the parameter.
4. If the DID alone is resolved without the resource parameter, it MUST return the authoritative DID document as defined in W3C Decentralized Identifiers (DIDs) 1.0. This specification adds no additional requirements to a conforming DID document.

...