Relative path resolution

[andrewwhitehead]

The DID spec does not outline a process for resolving a generic DID URL, ie. a DID with a path attachment (did:method/relative/path), leaving this up to specific DID methods. It does specify service and relativeRef DID parameters that can be used to resolve paths via service endpoints. An example from the did:web Anoncreds method:

did:method:domain?service=anoncreds&relativeRef=/v1/schema/5762v4VZxFMLB5n9X4Upr3gXaCKTa8PztDDCnroauSsR

Now we could define a simple alias as part of this DID method, and automatically map any DID URL of of the form {DID}/service/{SERVICE}{PATH}{?PARAMS} (for example). In this case the above resource might be represented as:

did:method:domain/service/anoncreds/v1/schema/5762v4VZxFMLB5n9X4Upr3gXaCKTa8PztDDCnroauSsR

On resolution it would simply be transformed into the original format before proceeding. Parameters such as hl (hashlink) should be preserved when this happens, for processing during the resolution process, but not added to the resulting URL.

For more flexibility we could enable path prefixes to be mapped by one or more methods. For example, a service entry of a recognized type:

{
    "id":"#index",
    "type": "PathResolution", 
    "serviceEndpoint": {
        "anoncreds/v1": "https://external-service/me/anoncreds/v1",
        "didcomm/v1": "did:myagent?service=didcomm",
        "*": "/" 
    }
}

or an external file defining the mappings:

{
    "id":"#index",
    "type": "PathResolution", 
    "serviceEndpoint": "/index.jsonld"
}

[swcurran]

Is the idea for this to add this such that it can be used for any DID Method? E.g. that it not be specific to a web-based DID method, but for any DID Method?

With a web-based DID method, it is dead simple and obvious to say that a DID path is just simple text transformation extending the existing DID —> HTTPS transformation. That is what is proposed for the did:webs spec — copying from the text:

1. The controller of the DID MAY place arbitrary files into the folder structure below the root did:webs folder.
2. The DID URL for the signed file MUST be of the form <did:webs DID>/path/to/file.
3. The HTTPS path to the file MUST be <HTTPS URL conversion of did:webs identifier>/path/to/file.

That has the benefit that it eliminates the need for a service endpoint — the interpretation is (as the DID Core spec says…) left to the DID Method.

[brianorwhatever]

Where did we land on this today? Do we need a service to do the relative path stuff or can we define the path behaviour in this method?

[swcurran]

The summary that I got:

• Service endpoints will not be required, but strongly encouraged.
  • I think I would be willing to require at least #whois…
• Notably:
  • The simple ”id” : “#whois” service using the linked VP will be enouraged/required.
  • We’ll use the conventions that a path with a first element service (example: did:method:domain/service/anoncreds/v1/schema/v1.0/degree.vc) will:
    • Map to the service ”id” : “#file” (this is proposing #file as the id, but open to suggestions…
    • Match the second element to an entry in the list of name / value pairs (e.g. ”anoncreds” : "https://external-service/me/anoncreds/v1".
    • Replace the everything in the DID URL up to the second element with the “value” of the matched entry.
    • Resolve that URI and return the result.

Whether to use a hashlink, or it a header is returned or not is up to the Controller.

I think it is up to the resolver implementation based on the DID URL spec to decide how far to go in resolving a passed in DID URL — should it return the DIDDoc, the resulting URI or resolve the URI? I’m not sure of that.

[brianorwhatever]

I still can't quite make heads or tails of this. Suppose I have a local file named /farms/happy-farm/sheep.json that I want to host in a similar folder structure. Where do I put it and do I need to put anything in my DID Document?

[swcurran]

Here is how I understand it:

• You decide where you want to put it. Assume https://aviary.io/farms/happy-farm/sheep.json. You start by putting it there. :-).
• Then you add to the DIDDoc in the services array:

{
    "id":”#farms",
    "type": "PathResolution", 
    "serviceEndpoint": { "https://aviary.io/farms" }
}

• The DID URL is <did>/farms/happy-farm/sheep.json
• The first component in the path is matched to a service of type PathResolution, with an id of the prefix of the DID URL Path — in this case farms.
  • AFAIUI an part of the path prefix can be used. e.g. you could have a `”id” : “#farms/happy-farms”.
• Remove / from the DID and replace with the serviceEndpoint.

Does that work?

It leaves off the obvious use case of just being able to trivially put any file “adjacent" to the DIDDoc (didlog.txt) — which I personally think should be a default. It would be nice to have a way to express that without having to:

• put ”id” : “#*” which I’m sure is illegal, and
• specify the serviceEndpoint, which can be derived identically to the DID.

[swcurran]

I think we can close this issue with what is in the draft spec. now -- https://bcgov.github.io/trustdidweb/#did-url-resolution.

[swcurran]

Mostly complete, with a need to formalize the handling of files when the DID Log File's location is .well-known. Over to @andrewwhitehead to propose the handling for that -- and how that impacts the service entry.

[swcurran]

Resolved -- description is in the specification, as is the service definition.