The spec currently has a number of helper functions that, IMO, are either misplaced (specified in resolution instead of dereferencing) or an unnecessary complication.
In particular, I think it is a bad idea for the DID resolver to return ANY content other than the DID Document and related metadata. Transformations of the document are problematic, as are are derived substitutions.
The semantic guarantee at the foundation of DID core is that executing the resolution process returns the canonical DID document for a particular version, time, or the latest (in version and time dimensions. These helper functions undermine that guarantee. In particular, this specification violates the guarantee currently made for current DID methods: the DID method defines how the DID document is generated.
Under the current specification, resolution can, under multiple circumstances, return content that is NOT the canonical DID Document. This shift undermines the fundamental security guarantee of DIDs: you know you have the canonical DID document because you have performed the DID method's specified resolution process. It's a security problem that rather than returning that DID document, the resolver returns some other transformation, based not on the DID method, but on some other specification outside the DID method's control, whether that is in this DID Resolution specification, or an extension, either to DID Resolution or to DID Document properties.
To return anything other than the DID document from resolution (ignoring meta-data) means that the caller now has to handle the case when a DID URL resolves to something else. Remember: the caller of resolution is often NOT the party that constructed the DID URL. Client software will likely be given a task of resolving a DID URL without the ability to parse, understand, or modify the URL itself. Think of clicking on a link in a web page. That meaning of the path and query parts are completely opaque to the browser. It doesn't do something different because a path part or query part is different. The same is true for resolution, IMO, only those parameters that affect the choice of canonical frame are appropriate. It's vital to be able to ask for a particular version using versionId and verstionTime, as those affect WHICH version in the document's history is appropriate, but requesting transformations or subsets breaks the DID method's expected gaurantees.
'expandRelativeURLs' creates the possibility that the response from a resolver, for the same DID with the same version and validity parameters resolves different DID Documents.
Instead, I believe the more appropriate approach is to ensure that the DID document returned from resolution is the full, unmodified result of applying the DID method's resolution process for the DID URL. This enables external verification of the DID Document's provenance to compare if the current DID Document makes sense given what we know of the DID Document history. In particular, some methods, like BTCR2 enable the end caller to request provenance data and independently apply all of the updates in the document history. The result SHOULD be the same as what comes back from resolution. Applying expandRelativeUrls would break that. I expect some will argue that this is an optional parameter and one simply would not use that, but I argue that the resolver returning anything other than the canonical DID document is a security problem.
However, this parameter, in particular, might be appropriate to retain as a feature for dereferencing, which is a separate step than resolution. Parameters that transform the final resource are outside the guarantee of the DID method and could be instead guaranteed by the dereferencing software.
Hence a dereferencing request that wants relativeURLs expanded seems perfectly legitimate, not unlike requesting a particular media type when performing a GET with an HTTP URL.
Finally, the language in the spec for this particular feature is incomplete. It should replace ALL relative URLs, in ANY property in the document. Given that properties are an extension point, only processing a limited set of properties will mean that extended properties, such as the [linkedResource property] (https://www.w3.org/TR/did-extensions-properties/#linkedresource) are ignored by this feature, leading to a resulting DID Document for which some relativeURLs are transformed and others are not this would likely be unexpected by most clients.
My recommendation: move this to dereferencing so that a caller requesting a DID URL resource can apply the algorithm subsequent to retrieving whatever resource is returned, whether a DID Document or a resource retrieved through further actions after processing the result of resolution. AND update it to apply to ALL relative references in the dereferenced resource (not just certain properties).
The spec currently has a number of helper functions that, IMO, are either misplaced (specified in resolution instead of dereferencing) or an unnecessary complication.
In particular, I think it is a bad idea for the DID resolver to return ANY content other than the DID Document and related metadata. Transformations of the document are problematic, as are are derived substitutions.
The semantic guarantee at the foundation of DID core is that executing the resolution process returns the canonical DID document for a particular version, time, or the latest (in version and time dimensions. These helper functions undermine that guarantee. In particular, this specification violates the guarantee currently made for current DID methods: the DID method defines how the DID document is generated.
Under the current specification, resolution can, under multiple circumstances, return content that is NOT the canonical DID Document. This shift undermines the fundamental security guarantee of DIDs: you know you have the canonical DID document because you have performed the DID method's specified resolution process. It's a security problem that rather than returning that DID document, the resolver returns some other transformation, based not on the DID method, but on some other specification outside the DID method's control, whether that is in this DID Resolution specification, or an extension, either to DID Resolution or to DID Document properties.
To return anything other than the DID document from resolution (ignoring meta-data) means that the caller now has to handle the case when a DID URL resolves to something else. Remember: the caller of resolution is often NOT the party that constructed the DID URL. Client software will likely be given a task of resolving a DID URL without the ability to parse, understand, or modify the URL itself. Think of clicking on a link in a web page. That meaning of the path and query parts are completely opaque to the browser. It doesn't do something different because a path part or query part is different. The same is true for resolution, IMO, only those parameters that affect the choice of canonical frame are appropriate. It's vital to be able to ask for a particular version using versionId and verstionTime, as those affect WHICH version in the document's history is appropriate, but requesting transformations or subsets breaks the DID method's expected gaurantees.
'expandRelativeURLs' creates the possibility that the response from a resolver, for the same DID with the same version and validity parameters resolves different DID Documents.
Instead, I believe the more appropriate approach is to ensure that the DID document returned from resolution is the full, unmodified result of applying the DID method's resolution process for the DID URL. This enables external verification of the DID Document's provenance to compare if the current DID Document makes sense given what we know of the DID Document history. In particular, some methods, like BTCR2 enable the end caller to request provenance data and independently apply all of the updates in the document history. The result SHOULD be the same as what comes back from resolution. Applying expandRelativeUrls would break that. I expect some will argue that this is an optional parameter and one simply would not use that, but I argue that the resolver returning anything other than the canonical DID document is a security problem.
However, this parameter, in particular, might be appropriate to retain as a feature for dereferencing, which is a separate step than resolution. Parameters that transform the final resource are outside the guarantee of the DID method and could be instead guaranteed by the dereferencing software.
Hence a dereferencing request that wants relativeURLs expanded seems perfectly legitimate, not unlike requesting a particular media type when performing a GET with an HTTP URL.
Finally, the language in the spec for this particular feature is incomplete. It should replace ALL relative URLs, in ANY property in the document. Given that properties are an extension point, only processing a limited set of properties will mean that extended properties, such as the [linkedResource property] (https://www.w3.org/TR/did-extensions-properties/#linkedresource) are ignored by this feature, leading to a resulting DID Document for which some relativeURLs are transformed and others are not this would likely be unexpected by most clients.
My recommendation: move this to dereferencing so that a caller requesting a DID URL resource can apply the algorithm subsequent to retrieving whatever resource is returned, whether a DID Document or a resource retrieved through further actions after processing the result of resolution. AND update it to apply to ALL relative references in the dereferenced resource (not just certain properties).