...

1. The DID document is not retrieved by the resolver as part of the dereferencing process. Rather the resolver makes a call to the VDR with the DID URL including a resource parameter conformant with this specification. 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 dereference 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.

...

1. A Boolean value of true. The parameter value of true MUST be case-sensitive and MUST be spelled out exactly. No other renderings of true, i.e.  T, TRUE, 1, -1, and so forth — are equivalent.
2. A valid media type name. If the VDR supports the storage of the resource in multiple media types, this option enables the client to request return of a specific media type.

...

Examples

Following are examples of DID URLs based on the fictional did:example: DID method that include the resource parameter:

...