0067-didcomm-diddoc-conventions DID inline representation using DID Query about aries-rfcs

[SmithSamuelM]

One of the advantages of having a default definition for the path even when the path component is missing is that fragment and query also have default definitions without any extra work. This also closes a semantic hole.

[TelegramSam]

Using query param syntax is I think most useful when adding type and format details to an inline key. It feels like an odd way to add a suffix, but it is a common format that doesn't seem to conflict with key encodings.

Example: ?keytype=xxx&keyformat=xxx

[peacekeeper]

@SmithSamuelM

the receipientKeys and routing keys array values all could benefit in some cases from an inline representation of the key material (crypto suite type) to allow participants to verify signatures made with the private keys underlying the associated DIDs without having to lookup the associated DID Documents.

The idea has recently come up that if certain fields of the DID Document reference a key, a DID Resolver could have a function to expand those referenced keys into inline keys: w3c-ccg/did-resolution#39

My reading of the algorithm is that it is either ambiguous or incomplete and leaves undefined some edge cases.

Yes, the algorithm is at a very early stage and needs more work. For now, it only captures the three most common use cases that seem to have broadest support in the community (see your A, B, C below). There are some known ambiguities and edge cases in the algorithm which we'll try to fix asap.

Note that for the DID path, query only should is applied for usage in a DID URL with a service endpoint. Other usages are allowed. The DID fragment uses MUST but the use case is not sufficiently well defined and should allow other use when not the defined use case.

I agree we probably want to change this MUST. DID URLs with a "service" matrix parameter can also contain a fragment, in which case it is not a reference into the DID Document.

I assume that the rules are processed in order. Because the resultant actions specifies a return then I am assuming that the rule processing is aborted once a valid antecedent is reached.

This is correct. We should probably explicitly state this in the spec if it is not clear enough.

A) IF the input DID URL is equal to the input DID itself: THEN Return the resolved DID Document.

Not sure how to interpret this. If the DID URL is just a valid expression for a DID then this rule will always be true even with a query, path, or fragment component.

This is supposed to mean if the DID URL has an empty path, no query, and no fragment. "input DID" means only the did ABNF rule. In that case the "input DID URL" (did-url ABNF rule) is the same as the "input DID" (did ABNF rule).

Actually that's not entirely correct. For example, this rule should still trigger if certain matrix parameters are included as part of the DID URL, even though then the "input DID URL" is not the same as the "input DID".

B) IF the input DID URL contains the matrix parameter service and optionally a DID Path, DID Query, and/or DID Fragment: THEN Return the output service endpoint URL.

Correct.

C) IF the input DID URL contains a DID Fragment::THEN Return the output resource. (JSON-LD object whose id property matches the input DID URL)

This seems to be too greedy as it does not allow for JasonP or resolution into the DID document. Not all fragments correspond to an id property. This seems to be problematic no matter the definition.

I agree this can probably be improved, although I do consider this particular use of fragment (corresponding to an id field) the "main" use. This is a core feature of RDF and Linked Data web architecture.

Note that section 5.3 lists additional features that haven't been incorporated yet into the algorithm, among them JSON Pointers, see section 5.3.3.

There is at least one more use of fragments in the community; in did:ipid, the fragment of a DID URL contains a secret key used for decrypting (parts of) the DID Document.

When the path is empty there is some default resource that is ALWAYS provided. This is not the case for a DID URL that is when a path component is missing there is no defined default resource unless the DID URL includes a service matrix parameter. Then the default resource is provided by the service endpoint.

I suggest that there is a valid default resource that could be defined for a DID URL for all other cases except when the DID URL includes a service matrix parameter. That default would be the did document itself.

+1. The default is the DID Document itself. This is exactly what rule A) (see above) is trying to say. Sorry if the language isn't clear enough, I'd be happy to reword this.

This is consistent with the precedent set by the DID Fragment specification where the fragment resolves to an object within the DID document.

+1

The resolution of a non-empty path ie no default would be method dependent

I think I agree with this too. In the algorithm, I was thinking that anything that isn't captured by one of the specified rules would essentially be method-specific. Using a non-empty path is also one option (among others) that have been explored for referencing non-DID-Document resources in the Decentralized Identifier Registry (e.g. schemas, credential definitions in the case of Sovrin).

Likewise the semantics of DID query could also be defined:

We have talked very little so far about the use of DID query, and I'd like to explore this further. I supposed it could be used for a kind of query language as you mention (e.g. selecting service blocks by type). But wouldn't this already be covered by JSON Pointer? Matrix parameters service-type and key-type have also been proposed for this.

@dmitrizagidulin has commented that query parameters are scoped to the URLs authority, i.e. we are not supposed to define universal query parameters that have the same semantics across all DIDs.

@talltree has argued in his Algorithmic Construction doc that the DID Spec should not restrict the semantics of path, query, fragment at all, to leave freedom for developers to use them any way they want, and that the use of matrix parameters is preferable.

[SmithSamuelM]

@peacekeeper

The idea has recently come up that if certain fields of the DID Document reference a key, a DID Resolver could have a function to expand those referenced keys into inline keys: w3c-ccg/did-resolution#39

That suggestion is not the same thing. expanding keys within the context of a DID Document is orthogonal to having an inline DID that does not need to reference or lookup a DID Document or the DID document is not essential to some uses of the DID.

This may be the core of the issue/misunderstanding. DIDs have use cases where an "ephemeral" DID is used. In these use cases the authentication information aka the crypto suite type may be provided by a query string on the DID.

[SmithSamuelM]

Note that for the DID path, query only should is applied for usage in a DID URL with a service endpoint. Other usages are allowed. The DID fragment uses MUST but the use case is not sufficiently well defined and should allow other use when not the defined use case.

I agree we probably want to change this MUST. DID URLs with a "service" matrix parameter can also contain a fragment, in which case it is not a reference into the DID Document.

@peacekeeper What is the process for following up on getting this changed. Or resolving any issues that would keep if from being fixed?

[SmithSamuelM]

@peacekeeper
Based on your answers to ABC Above there is a serious problem with the DID resolver logic. It will discard(not resolve) any DIDs that have query strings that are also not service endpoint specific DID URLs. This is wrong =) The logic should not discard DIDs in these cases. The DID URL service endpoint is a special case not the other way around.

[SmithSamuelM]

We have talked very little so far about the use of DID query, and I'd like to explore this further. I supposed it could be used for a kind of query language as you mention (e.g. selecting service blocks by type). But wouldn't this already be covered by JSON Pointer? Matrix parameters service-type and key-type have also been proposed for this.

The JSON pointer references into a DID Document so it is not useful for an ephemeral DID that does not lookup a DID Document. The Query makes the DID self-contained. This is an important use case. It seems that the focus of DID resolvers has narrowed so much that it assumes too much. A DID resolver should still resolve a DID and return it even if the DID has a query string but is not part of a DID URL that resolves to a service endpoint. This should be obvious otherwise the DID spec would have to limit the use of DID query to only the service endpoint case.

@dmitrizagidulin has commented that query parameters are scoped to the URLs authority, i.e. we are not supposed to define universal query parameters that have the same semantics across all DIDs.

I am not suggesting universal query parameters. I am stating that any DID with query parameters that is not part of a service endpoint matrix parameter DID URL is not resolvable with the current DID resolver logic. This prevents any use of the query except as part of a service endpoint.

@talltree has argued in his Algorithmic Construction doc that the DID Spec should not restrict the semantics of path, query, fragment at all, to leave freedom for developers to use them any way they want, and that the use of matrix parameters is preferable.

I agree except that the default semantics should be defined as the default path resolves to the DID document. A service endpoint is a different use case in that case the path query and fragment should be left up to the service endpoint to decide. But when no service endpoint is provided then it makes perfect sense and follows the current precedent of the fragment for the path to resolve to the DID Document. How the query is interpreted in that case is method dependent. But the current resolver logic discards any DID with a Query that is not a service endpoint. That is the point of my comment and questions. It seemed that that was the case but I could not be sure. Based on your answers (as I understand them) that indeed is the case and IMHO needs to be fixed.

[SmithSamuelM]

The majority of this discussion may be more appropriately considered an issue for the DID resolver specification.

I have created an issue
w3c-ccg/did-resolution#42

To continue the discussion.

[TelegramSam]

Discussed on the Aries WG Call 2019-12-11, and decided that it was complete.