Question about query parameter ordering

[SaulMoonves]

I am looking for guidance on query parameter ordering, specifically where a DID URL with a query parameter might be used as an ID

In many systems such as ActivityPub, an ID is basically an opaque string but in practice it is a URL whose structure gives a hint on how to resolve it, like using an HTTPS URL that resolves to the object.

I am in the process of trying to implement did:web for activitystreams object IDs inside of an ActivityPub project, but this would I think equally apply to service IDs in the DID document: How do I deal with query parameters being seemingly unordered if some things rely on IDs equally matching? Is anyone dealing with this in their projects?

[Peeja]

(Someone with more knowledge should correct me if I'm wrong, but…)

A DID can't contain query parameters. A DID URL can. Only the DID is the identifier. The DID URL refers to a resource. The DID is the authority of the DID URL. (That statement may not be exactly technically correct, but should be close to correct.)

So: for authentication purposes, you shouldn't be using identifiers which include query params. And if you really need to know if two DID _URL_s point to the same resource, then you've got the same problem you have with the equivalent HTTP URLs, and you'll have to decide how you want to solve that.

But it sounds like you're just talking about identifiers, in which case I believe you're going to have to rethink how your DIDs are produced to include whatever you're currently using query params for.

[msporny]

Yes, effectively what @Peeja said. :)

If you are looking for id equivalence matching, using DID URLs with multiple query parameters is probably not the right thing to do. If you need to do that, your application/specification will have to contain some query parameter canonicalization rules to ensure equivalence holds in your application area.

If you could give us a more concrete use case, @SaulMoonves, we might be able to provide more guidance.

[peacekeeper]

Also agree with @Peeja .

This should be handled in the same way as you would handle query parameters in HTTPS URLs. Would you order parameters in HTTPS URLs? Would you do exact string matching on HTTPS URLs with parameters?

[trwnh]

your application/specification will have to contain some query parameter canonicalization rules to ensure equivalence holds in your application area

If I'm reading this correctly, then you're saying that something like:

{
  "@id": "did:example:abc123?service=foo&relativeRef=/"
}

is going to require some additional equivalence-checking? Which I guess means that it's no longer opaque. So basically this should be part of the protocol considerations of whatever protocol is producing and consuming such identifiers. So basically this should be an ActivityPub concern (for example).

Although I think that at least for the purposes of DID specs, a quick note about query parameter ordering wouldn't be amiss. For example in https://w3c.github.io/did-core/#did-parameters or something.