Add guidance for recommending fully qualified URIs for all properties, not just keys

[decentralgabe]

          the guidance is currently only present around keys, but I'd like to update this to recommend fully qualified identifiers for all properties https://did-dht.com/#representing-keys, I'll open an issue for this.

generally I think we should avoid fragments with # since - at least to me - they only make sense in the context of a full identifier

Originally posted by @decentralgabe in decentralized-identity/web5-js#413 (comment)

[frankhinek]

@decentralgabe I agree that when expanding a DID identifier to a DID document, DID DHT implementations should use full DID URLs (i.e., that begin with did:dht:<method-specific-id>).

However, in the case of custom properties added to a service entry, my current conclusion is that there's nothing wrong with reducing the DID Document size by using relative DID URLs. In other words, we should leave that up to people building applications using DID DHT rather than mandating that it is not permitted in the DHT method specification.

The DID Core spec allows for DID Relative URLs and contains guidance on how to resolve a relative DID URL reference.

A relative DID URL is any URL value in a DID document that does not start with did::. More specifically, it is any URL value that does not start with the ABNF defined in 3.1 DID Syntax. The URL is expected to reference a resource in the same DID document. Relative DID URLs MAY contain relative path components, query parameters, and fragment identifiers.

When resolving a relative DID URL reference, the algorithm specified in RFC3986 Section 5: Reference Resolution MUST be used. The base URI value is the DID that is associated with the DID subject, see 5.1.1 DID Subject. The scheme is did. The authority is a combination of :, and the path, query, and fragment values are those defined in Path, Query, and Fragment, respectively.

It appears the authors of the DID spec included relative DID URLs for precisely the purpose in which we're using them: to optimize storage size

Relative DID URLs are often used to reference verification methods and services in a DID Document without having to use absolute URLs. DID methods where storage size is a consideration might use relative URLs to reduce the storage size of DID documents.

[decentralgabe]

Agree with your reasoning, but not sure I agree with your conclusion. Yes, it is allowed by the DID Core spec. @andresuribe87 made a suggestion to always include fully qualified URLs to make implementations consistent and unambiguous, which I implemented.

We could reverse course here and do the opposite: always use fragments. I am less concerned with the size of documents once expanded, and more concerned with interoperability. The code to reconstruct verification methods based on variation in DID Documents can be really complex which is part of my motivation here.

So, while I agree there isn't anything wrong per say, I do think implementations benefit from consistency = simplicity. And this is a bubble where we can force that consistency.

[frankhinek]

Aligned and 👍 to adding language to the spec stating that service ID values will always be expanded to a fully qualified DID URLs. Custom properties that appear in a service object will not have the same rules applied since there is no assumption of what the values will be nor any special handling provided when converting between DID Document and DNS packet.