Support DID URL dereferencing according to DID specifications

[gerardsn]

The DID specification distinguishes between resolving a DID document and dereferencing to a specific item on that document. The specifications also describes how conforming resolvers should be implemented. https://w3c-ccg.github.io/did-resolution/ (draft) provides some more details and useful examples on did resolution

RFC006 service dereferencing approach

More specifically, in RFC006 we have defined a service as

{
    "id": "<did>#<id-string>"                 # id-string = BASE58(SHA256(json-bytes-without-id))
    "type": "<unique-type-name>"
    "serviceEndpoint": ... (string or map)
}

According to RFC006 we need to (de-)reference this service as

<did>/serviceEndpoint?type=<service-type>

DID v1.0 service dereferencing approach

Lets say that the service has "id": "<did>#service1" then according to the DID standard, a conforming resolver can (de-)reference this service using the id fragment

<did>?service=service1

Differences

The official (de)referencing method does not seem to conflict with ours and can just be implemented.

The main difference is that we dereference based on the service.type (and therefore require the type to be unique), while the standard does this based on the fragment in the service.id (which is also specced to be unique).

My understanding is that we use service.type as a unique parameter to prevent issues when a service is replaced. For example, if did-1 references a service on did-2, and did-2 wants to change this serviceEndpoint from A.example.com to B.example.com, we still want the reference in did-1 to dereference properly. However, this issue only exists because we have defined the id fragment as id-string that is derived from the rest of the service (that is not being used for anything as far as I can see, but could be related to #242).

Dropping the id-string requirement means that the id field can be used as an identifier that is consistent even after changing the serviceEndpoint. This would also allow us to use service.type as a type that we can impose more constraints on to make validation easier. We currently have the following types: node-contact-info, NutsComm, NutsService, NutsCompoundService that each have a clearly defined format. (node-contact-info and NutsComm can be considered services or compound services with additional requirements)

If we are to apply (some) of these changes, we need to come up with a migration strategy. Since both methods do not conflict they can probably exists at the same time. Bolts specified types also need more thinking

[woutslakhorst]

So the title should be about service dereferencing, not DID resolvement/resolution?

[gerardsn]

Changed it back. I thought resolution referred to both dereferencing and resolving. I did not look at resolving, but did not want to exclude it either.

[pascaldekloe]

https://pkg.go.dev/github.com/pascaldekloe/[email protected]#example-Document.VerificationMethodRefs-RelativeURL