When should did parameters be dropped?

[OR13]

Consider:

did:example:123?q1=1&q2=2#fragment => did document.

should didDocument.id === did:example:123?q1=1&q2=2 or did:example:123 ?

this is particularly concerning for interactions with the initial-state parameter used by sidetree and didcomm... if its dropped the URI becomes unresolvable, so that client would need to store that somewhere...

[tplooker]

To add further detail to this issue, calling to an ion based sidetree node with the following request

curl http://localhost:3000/identifiers/did:ion:test:EiC0wVS3K9VLv-XZVL55i8Y4d1Hk1kJpeckfDXIu0nM17A?-ion-initial-state=eyJkZWx0YV9oYXNoIjoiRWlDUlRKZ2Q0U0V2YUZDLW9fNUZjQnZJUkRtWF94Z3RLX3gwV0gtZXVhNGhrZyIsInJlY292ZXJ5X2NvbW1pdG1lbnQiOiJFaURmR2k0NzRpajQ5VnFfeWlLRzFxOG9DMWpIX0JGTGZIMjdCSVFLVW5UQlR3In0.eyJ1cGRhdGVfY29tbWl0bWVudCI6eyIwIjoxOCwiMSI6MzIsIjIiOjIyMywiMyI6MjYsIjQiOjQ2LCI1Ijo1OSwiNiI6MjI2LCI3Ijo0MCwiOCI6MjQ4LCI5IjoyNDUsIjEwIjo5MCwiMTEiOjE5MSwiMTIiOjIwMiwiMTMiOjM0LCIxNCI6MTM0LCIxNSI6MjE0LCIxNiI6MTc1LCIxNyI6NDAsIjE4IjoxMSwiMTkiOjg4LCIyMCI6MTk5LCIyMSI6MjUyLCIyMiI6MTcsIjIzIjo3NSwiMjQiOjEyNCwiMjUiOjEyNSwiMjYiOjE4NywiMjciOjQsIjI4IjoxMzIsIjI5IjoxMCwiMzAiOjgyLCIzMSI6MTE2LCIzMiI6MTkzLCIzMyI6Nzl9LCJwYXRjaGVzIjpbeyJhY3Rpb24iOiJyZXBsYWNlIiwiZG9jdW1lbnQiOnsicHVibGljX2tleXMiOlt7ImlkIjoielEzc2hta2VNZmh1RHdOOGExS3YiLCJ0eXBlIjoiU2VjcDI1NmsxVmVyaWZpY2F0aW9uS2V5MjAxOCIsImp3ayI6eyJrdHkiOiJFQyIsImNydiI6InNlY3AyNTZrMSIsIngiOiJhYTZhNDVhM1lnRW1sYks2cjVwYmlCcDhkV2RVZTZ2bUJsWWhIS2dhWGRRIiwieSI6InZPR1A2cVVZMUt3cFk3VFpENzI5c2p3S2d0b0hPZ1NyY1pHMmFUSExQYWsifSwicHVycG9zZSI6WyJnZW5lcmFsIl19XX19XX0 -i

Results in

{
   "@context":"https://www.w3.org/ns/did-resolution/v1",
   "didDocument":{
      "id":"did:ion:test:EiC0wVS3K9VLv-XZVL55i8Y4d1Hk1kJpeckfDXIu0nM17A?-ion-initial-state=eyJkZWx0YV9oYXNoIjoiRWlDUlRKZ2Q0U0V2YUZDLW9fNUZjQnZJUkRtWF94Z3RLX3gwV0gtZXVhNGhrZyIsInJlY292ZXJ5X2NvbW1pdG1lbnQiOiJFaURmR2k0NzRpajQ5VnFfeWlLRzFxOG9DMWpIX0JGTGZIMjdCSVFLVW5UQlR3In0.eyJ1cGRhdGVfY29tbWl0bWVudCI6eyIwIjoxOCwiMSI6MzIsIjIiOjIyMywiMyI6MjYsIjQiOjQ2LCI1Ijo1OSwiNiI6MjI2LCI3Ijo0MCwiOCI6MjQ4LCI5IjoyNDUsIjEwIjo5MCwiMTEiOjE5MSwiMTIiOjIwMiwiMTMiOjM0LCIxNCI6MTM0LCIxNSI6MjE0LCIxNiI6MTc1LCIxNyI6NDAsIjE4IjoxMSwiMTkiOjg4LCIyMCI6MTk5LCIyMSI6MjUyLCIyMiI6MTcsIjIzIjo3NSwiMjQiOjEyNCwiMjUiOjEyNSwiMjYiOjE4NywiMjciOjQsIjI4IjoxMzIsIjI5IjoxMCwiMzAiOjgyLCIzMSI6MTE2LCIzMiI6MTkzLCIzMyI6Nzl9LCJwYXRjaGVzIjpbeyJhY3Rpb24iOiJyZXBsYWNlIiwiZG9jdW1lbnQiOnsicHVibGljX2tleXMiOlt7ImlkIjoielEzc2hta2VNZmh1RHdOOGExS3YiLCJ0eXBlIjoiU2VjcDI1NmsxVmVyaWZpY2F0aW9uS2V5MjAxOCIsImp3ayI6eyJrdHkiOiJFQyIsImNydiI6InNlY3AyNTZrMSIsIngiOiJhYTZhNDVhM1lnRW1sYks2cjVwYmlCcDhkV2RVZTZ2bUJsWWhIS2dhWGRRIiwieSI6InZPR1A2cVVZMUt3cFk3VFpENzI5c2p3S2d0b0hPZ1NyY1pHMmFUSExQYWsifSwicHVycG9zZSI6WyJnZW5lcmFsIl19XX19XX0",
      "@context":[
         "https://www.w3.org/ns/did/v1",
         {
            "@base":"did:ion:test:EiC0wVS3K9VLv-XZVL55i8Y4d1Hk1kJpeckfDXIu0nM17A?-ion-initial-state=eyJkZWx0YV9oYXNoIjoiRWlDUlRKZ2Q0U0V2YUZDLW9fNUZjQnZJUkRtWF94Z3RLX3gwV0gtZXVhNGhrZyIsInJlY292ZXJ5X2NvbW1pdG1lbnQiOiJFaURmR2k0NzRpajQ5VnFfeWlLRzFxOG9DMWpIX0JGTGZIMjdCSVFLVW5UQlR3In0.eyJ1cGRhdGVfY29tbWl0bWVudCI6eyIwIjoxOCwiMSI6MzIsIjIiOjIyMywiMyI6MjYsIjQiOjQ2LCI1Ijo1OSwiNiI6MjI2LCI3Ijo0MCwiOCI6MjQ4LCI5IjoyNDUsIjEwIjo5MCwiMTEiOjE5MSwiMTIiOjIwMiwiMTMiOjM0LCIxNCI6MTM0LCIxNSI6MjE0LCIxNiI6MTc1LCIxNyI6NDAsIjE4IjoxMSwiMTkiOjg4LCIyMCI6MTk5LCIyMSI6MjUyLCIyMiI6MTcsIjIzIjo3NSwiMjQiOjEyNCwiMjUiOjEyNSwiMjYiOjE4NywiMjciOjQsIjI4IjoxMzIsIjI5IjoxMCwiMzAiOjgyLCIzMSI6MTE2LCIzMiI6MTkzLCIzMyI6Nzl9LCJwYXRjaGVzIjpbeyJhY3Rpb24iOiJyZXBsYWNlIiwiZG9jdW1lbnQiOnsicHVibGljX2tleXMiOlt7ImlkIjoielEzc2hta2VNZmh1RHdOOGExS3YiLCJ0eXBlIjoiU2VjcDI1NmsxVmVyaWZpY2F0aW9uS2V5MjAxOCIsImp3ayI6eyJrdHkiOiJFQyIsImNydiI6InNlY3AyNTZrMSIsIngiOiJhYTZhNDVhM1lnRW1sYks2cjVwYmlCcDhkV2RVZTZ2bUJsWWhIS2dhWGRRIiwieSI6InZPR1A2cVVZMUt3cFk3VFpENzI5c2p3S2d0b0hPZ1NyY1pHMmFUSExQYWsifSwicHVycG9zZSI6WyJnZW5lcmFsIl19XX19XX0"
         }
      ]
   },
   "methodMetadata":{
      "recoveryCommitment":"EiDfGi474ij49Vq_yiKG1q8oC1jH_BFLfH27BIQKUnTBTw"
   }
}

When I would have assumed the following result being sufficient

{
   "@context":"https://www.w3.org/ns/did-resolution/v1",
   "didDocument":{
      "id":"did:ion:test:EiC0wVS3K9VLv-XZVL55i8Y4d1Hk1kJpeckfDXIu0nM17A",
      "@context":[
         "https://www.w3.org/ns/did/v1",
         {
            "@base":"did:ion:test:EiC0wVS3K9VLv-XZVL55i8Y4d1Hk1kJpeckfDXIu0nM17A"
         }
      ]
   },
   "methodMetadata":{
      "recoveryCommitment":"EiDfGi474ij49Vq_yiKG1q8oC1jH_BFLfH27BIQKUnTBTw"
   }
}

[brentzundel]

The group feels that better language around this topic should be added to the spec.

[wyc]

We could say that DID URLs MAY resolve to DID Documents for resolver-parsed parameters and fragments, but DID Documents MUST contain a DID in the id property. Does that sound right @OR13 @tplooker ?

[peacekeeper]

Per the current spec, the above did:ion Sidetree example is not a valid DID document, since the value of id MUST be a DID, not a DID URL (see section DID Subject in the spec). Personally, I don't think anything should be changed about this, except perhaps explain it a bit better.

[OR13]

I agree, we should provide an example (not ION, but similar structure) and a note.

[OR13]

Needs PR to add explicit warning about how DID params are dropped from the did document and may be present in resolver meta data.... needs PR.

[csuwildcat]

Assign me.

[csuwildcat]

Still need to generate PR for this, sorry for the delay :/

[msporny]

If we don't get a PR for this before we enter CR, this issue will be deferred to the next version of the specification. @csuwildcat, you have 30 days to generate a PR for this issue.

[OR13]

I worry that folks don't realize how this impacts Verifiable Credentials....

this means that when you resolve:

"did:example:123?version-id=1#key-0"

and you get back a did document with verificationMethod:

"did:example:123#key-0"

You will need to do the following:

for JWS, you can just "find the public key bytes and check the signature.... "

for linked data proofs, you will need to apply post resolver middleware that "inserts the version" IF the original signature was over the version, OR you will have to be careful about checking the credential...

cc @dlongley

I worry that if we are not explicit here, one of the key features of the did spec will be implemented very differently by DID Methods, leading to broken verifiable credentials.

[msporny]

should didDocument.id === did:example:123?q1=1&q2=2 or did:example:123 ?

The second value... that is did:example:123 -- what am I missing?

The signed VC can have a verificationMethod of did:example:123?q1=1&q2=2 ... and that's what's signed over via the LD Signature... so when you dereference did:example:123?q1=1&q2=2 you get a DID Document that contains something with that ID in there... or a fragment identifier.

Perhaps there is some algorithm somewhere in some spec that is causing an issue here?

[OR13]

@msporny its rather that there is no algorithm in ANY spec, that handles this properly... including the VC Data Model (does not elaborate on query parameters) and JWT/JWS (which does not understand dereferencing).

Best thing for developers would be a set of "Good" and "Bad" example using query params in the verification method and the vc data model.

[msporny]

Best thing for developers would be a set of "Good" and "Bad" example using query params in the verification method and the vc data model.

I'd be supportive of this.

The right place to do that might be the Linked Data Security specs (which is really unfortunate, because they are not normative in any way). We could put an appendix in the DID Core spec on the topic, it would be a bit weird and out of place, but at least it would be there. We could put it in the implementation guide, but I expect that thing won't be done by REC.

I think I'd rather document this in the Linked Data Proofs spec in the processing of the verificationMethod algorithm... but then went to look at the latest spec text: https://w3c-ccg.github.io/ld-proofs/#proof-verification-algorithm ... which is just awful, everything is terrible.

[OR13]

I think this belongs in did core, since did core is defining dereferencing... we either define how parameters are or are not present in the resulting documents... or we stop trying to define dereferencing... the work needs to be done in did core, or its like saying we support HTTP GET, but don't define the response format.

[peacekeeper]

I think this belongs in did core, since did core is defining dereferencing

The idea was that DID Core would define abstract functions with the inputs and outputs of resolving and dereferencing, and that DID Resolution would define algorithms that implement those abstract functions, answering questions such as:

• How are DID URL parameters processed (e.g. version-id), how do they influence the outputs.
• How are input metadata properties processed (e.g. accept), see How should resolvers handle the accept header? #417.

There is such an early algorithm in DID Resolution (see here), but admittedly this is not in sync with DID Core and needs to be updated.

[OR13]

@peacekeeper regarding query parameters.... they are NOT allowed in the id field of a did document.

Are they allowed in the id field of a verificationMethod?

[peacekeeper]

Are they allowed in the id field of a verificationMethod?

@OR13 yes the id of a verification method could be a DID URL such as did:example:123?version-id=1#key-0.

The spec currently says:

The value of the id property for a verification method MUST be a URI.

Perhaps we should add the following?

The value of the id property for a verification method MUST be a URI and MAY be a DID URL.

Or even SHOULD be a DID URL?

[OR13]

@dlongley @peacekeeper @msporny @dhh1128 @kdenhartog This is one of the most important parts of the whole specification.

It's the link between did core and all assertion formats that use identifiers, including JWT, VCs, ZKPs....

Its relevant too HTTP Signatures, DIDComm and many other areas....

Whatever rules we have here will shape how useful DIDs are in those other areas.

If we are saying that a verificationMethod.id MAY be a DID URL that contains query parameters, it raises questions about how they are related the DID URL that is input to dereferencing.

I think there are a number of assumptions developers will have, which I am not sure this WG as fully considered:

Dereferencing from aJWT.kid=did:example:123?version=52#primary-signing-key, I expect a VM with id=did:example:123?version=52#primary-signing-key to be present in the did document. (query params are reflected in verificationMethod id).

However, this is NOT ALLOWED per the spec today when combined with relative refs:

https://w3c.github.io/did-core/#relative-did-urls

didDocument.id cannot include the query params, so relative refs cannot be combined with query params of any format.

This kind of ambiguity is likely to cause serious security / interop issues for anyone using query params.

I would go so far as to say, its very dangerous for us to not have some concrete examples of VCs / JWTs issued from DID URLs in the spec, or language in the spec that clearly explains that they are not allowed.

[dhh1128]

I'm not feeling confident that I grasp all the implications here. I think the sentence that I most need to understand is this one from Orie:

"didDocument.id cannot include the query params, so relative refs cannot be combined with query params of any format."

I THINK I'm totally comfortable with that, but I may be missing something.

My own plans have always been that the id property of anything in a DID document is either a pure DID (as in the case of didDocument.id), or is a relative reference like #key1. I have never intended for id properties to include parameters anywhere. But perhaps what Orie is pointing out is that the possibility for that has not been carefully eliminated by spec language, and because it exists, there is ambiguity? I admit that I would scratch my head a bit about what it would mean to try to combine parameters from DID URLs with fragments.

Or is there some use case for DIDComm where it is important to have DID URLs as the value of an id property somewhere?

[OR13]

If you are using JSON-LD, the identifiers from the credential are expected to match the document returned by the resolver... JSON-LD has a whole section of the spec dedicated to handling "documentLoaders" of which DID resolvers are related... for JWTs or other ZKP formats, there is not always an assumption of "documentLoaders" and getting to "public key bytes / verification method details" may not be formally defined anywhere.... for example, OIDC defines this process for JWT id_token, but the same logic (using well known URLs) does not work for arbitrary JWTs.... its undefined behavior.

Essentially the DID Spec needs to comment on the following:

{
  "id": "did:key:zXwpDqA...",
  "verificationMethod": [
    {
      "id": "#zXwpDq...",
      "type": "JsonWebKey2020",
      "controller": "did:key:zXwpDqAV1ME...",
      "publicKeyJwk": {
        "kty": "EC",
        "crv": "P-256",
        "x": "5ZfvRFT4SXjCW2xbsQj6Yt3aYl9P3MnRLUaRSoWV5nA",
        "y": "adpC6bexW8SqYTQe_80dKT87mDIC3irPtT7smKR7btA"
      }
    }
  ],
...

vs

{
  "@context": [
    "https://www.w3.org/ns/did/v1",
  ],
  "id": "did:key:zXwpDqA...", // query not allowed here....
  "verificationMethod": [
    {
      "id": "did:example:123?version=52#zXwpDq...",
      "type": "JsonWebKey2020",
      "controller": "did:key:zXwpDqAV1ME...",
      "publicKeyJwk": {
        "kty": "EC",
        "crv": "P-256",
        "x": "5ZfvRFT4SXjCW2xbsQj6Yt3aYl9P3MnRLUaRSoWV5nA",
        "y": "adpC6bexW8SqYTQe_80dKT87mDIC3irPtT7smKR7btA"
      }
    }
  ],
...

vs

{
  "@context": [
    "https://www.w3.org/ns/did/v1",
   {
      "@base": "did:key:zXwpDqAV...?version=52"
    }
  ],
  "id": "did:key:zXwpDqA...", // query not allowed here....
  "verificationMethod": [
    {
      "id": "did:example:123?version=52#zXwpDq...",
      "type": "JsonWebKey2020",
      "controller": "did:key:zXwpDqAV1ME...",
      "publicKeyJwk": {
        "kty": "EC",
        "crv": "P-256",
        "x": "5ZfvRFT4SXjCW2xbsQj6Yt3aYl9P3MnRLUaRSoWV5nA",
        "y": "adpC6bexW8SqYTQe_80dKT87mDIC3irPtT7smKR7btA"
      }
    }
  ],
...

The reason being that the following URIs are all different, and signing over them / derefrencing them in different ways could lead to interop failures:

1. did:example:123
2. did:example:123#key-456
3. did:example:123?version=0#key-456
4. #key-456

If your did document uses relative refs, verificationMethod.id can only be of the form: did:example:123?version=0#key-456 or #key-456

If you don't use relative refs, you can have the following:

{
  "id": "did:key:zXwpDqA...",
  "verificationMethod": [
    {
      "id": "did:key:zXwpDqA...#zXwpDq...",
      "type": "JsonWebKey2020",
      "controller": "did:key:zXwpDqAV1ME...",
      "publicKeyJwk": { ...}
      
    },
   {
      "id": "did:key:zXwpDqA...?version=52#zXwpDq...",
      "type": "JsonWebKey2020",
      "controller": "did:key:zXwpDqAV1ME...",
      "publicKeyJwk": { ...}
      
    },
   {
      "id": "did:key:zXwpDqA...?version=51#zXwpDq...",
      "type": "JsonWebKey2020",
      "controller": "did:key:zXwpDqAV1ME...",
      "publicKeyJwk": { ...}
      
    },
  ],
...

Since did:key:zXwpDqA...?version=51#zXwpDq... != did:key:zXwpDqA...?version=52#zXwpDq... != did:key:zXwpDqA...#zXwpDq...

The are technically unique...

The DID core spec already recommends using verificationMethod.id as the kid field in JOSE... in Linked Data Proof, the value in the proof is expected to be present in the resolved did document... for example:

"proof": {
    "type": "EcdsaSecp256k1Signature2019",
    "created": "2020-11-16T17:42:52Z",
    "verificationMethod": "did:example:123#key-0",
    "proofPurpose": "assertionMethod",
    "jws": "eyJhbGciOiJFUzI1NksiLCJiNjQiOmZhbHNlLCJjcml0IjpbImI2NCJdfQ..WBkq33Zs0dwzbqo-F66RUlVfMYWc-g8B3NANI5FULwR10fnYElJNI6K1wbqAuClVMGsEZAbwJX5jmeUPGbdvNA"
  }

"verificationMethod": "did:example:123#key-0",

and

"verificationMethod": "did:example:123?version=0#key-0",

Are different URIs....

if did:example:123?version=0#key-0 is not an id of a verificationMethod in the result of resolving did:example:123?version=0#key-0... the proof will not verify with without the verifier mutating the result of the resolution (tampering with the resolution response).

Similarly for JOSE, if the kid is did:example:123?version=0#key-0, but the DID Document only contains:

did:example:123#key-0

Or vice versa, how does the verifier know which public key bytes to use?

[OR13]

cc @selfissued @csuwildcat this is also related to "DID / JOSE interoperability"... and the very poor usability of the "VC-JWT" format... since VC-JWT does not have "documentLoader" but also does not define a dereferencing algorithm for kid -> publicKeyBytes.

Sidetree JWS does not require kid to be present in the JWS header nor would requiring it along be sufficient, and subsequently, we have a whole section of the spec dedicated to explaining how to verify a JWS.... without clarity on this in DID Core, we will be inviting everyone to do the same everywhere else.

[peacekeeper]

Is this maybe the same problem as the long form / short form thing in Sidetree?

Could you do this:

{
  "id": "did:example:123",
  "sameAs": "did:example:123?version=0",
  "verificationMethod": [ {
      "id": "#key-0",
      "type": "JsonWebKey2020",
      "controller": "did:example:123",
      "publicKeyJwk": {
        "kty": "EC",
        "crv": "P-256",
        "x": "5ZfvRFT4SXjCW2xbsQj6Yt3aYl9P3MnRLUaRSoWV5nA",
        "y": "adpC6bexW8SqYTQe_80dKT87mDIC3irPtT7smKR7btA"
  } ]
}

Then dereferencing did:example:123?version=0#key-0 and did:example:123#key-0 would both "work"?

Or could you have a sameAs property on the verificationMethod level instead of the top level?

[TallTed]

@peacekeeper --

Sure, we can avoid using "client" and "server", but something must be used to label the entities serving similar roles, even if these labels are not generic enough. (They're not HTTP-specific, even if that's often the easiest frame to use as an example.)

You didn't provide any alternative terms; do you have suggestions? "DID Resolver" would seem to be the agent that delivers the DID URL, but maybe it's the agent that is resolving the DID to get to the DID URL? "DID Document Requester" would seem to be clearly enough the agent that is dereferencing the DID URL to get the DID Document, but what is the agent that provides the DID Document?

(These labels are important, and not easy to settle on. It took months if not years to settle on Issuer, Verifier, Subject, and Holder for Verifiable Credentials -- if those can even be considered to be fully settled, now.)

---

Strictly speaking, HTTP doesn't require DNS, either; http://127.0.0.1:1111/, for instance, is perfectly valid, as is http://[::1]:443/.

[peacekeeper]

@TallTed

In my mind it's like this:

• "DID resolver" = The (set of) component(s) that perform the DID resolution function
• "DID URL dereferencer" = The (set of) component(s) that perform the DID URL dereferencing function

Both could be quite simple or quite complex. Both could consist of multiple hard- and software components (even in a classic client/server architecture), but they don't have to.

I'd be fine with continuing to use the term "client" to designate the thing that invokes the DID resolution and/or DID URL dereferencing functions. But we agreed at some point that we don't consider the "client" to participate in performing those processes. In other words, in the case of DID URLs the "client" does NOT do dereferencing, that is done entirely by a "DID URL dereferencer" (which can itself be a local process). If we want to discuss this further, we should probabaly raise a separate issue.

Two references that could be relevant here:

• We replaced the term "client" in several places in the spec with more appropriate terms in Replace "client" with more appropriate terms #393
• I just created Clarify that DID URL dereferencing returns the final resource. #544, which says that DID URL dereferencing returns the final resource even if the process consists of multiple steps. This was motivated by DID Fragment semantics cleanup needed #399.

[TallTed]

My #544 (comment) may be more relevant here than there...

[OR13]

I wrote some tests trying to make sense of didDocument.id and verificationMethod.id as they relate to path and query params in verifiable credentials...

I am very concerned by the results, most of the working examples are illegal according to did core spec today, and I could not produce a single "working legal example" of path and query params in a did document that worked with verifiable credentials and that was legal wrt normative requirements in did core today.... and also worked off the shelf with JSON-LD.

The cause of this is assumptions in linked data apis, (like frame) about the relationship between didDocument.id, verificationMethod.id and controller.... we are walking into a really nasty set of interoperability failures based on the current language in did core.

take a look at these examples:

https://github.com/OR13/did-params-and-you/tree/master/examples

In particular, I believe that @dhh1128 @oed wished to use version-id with credentials... I have included tests that work, but are illegal wrt did core.... https://github.com/OR13/did-params-and-you/blob/master/examples/case-2-illegal-working.json

The reason this is illegal is that didDocument.id MUST be a DID, NOT a DID URL... this normative requirement essentially prevents VCs from relying on query params in the verification method currently.... in a way that works for both JSON-LD and JSON....

Based on these tests, I am not sure how exactly to resolve this issue, but I am leaning towards recommending normative changes to did core, to make the working examples legal.

@dlongley @msporny I am concerned that the JSON-LD and non JSON-LD community are not working together wrt normative requirements in did core that impact verifiable credentials....

The did core spec should not be making valid linked data stuff illegal... especially if the non linked data community is going to just ignore the linked data side of the spec anyway... the normative requirements of did core need to work for both sides, and we should not be encouraging many slightly different ways of handling things like query and path.

PROPOSED CHANGES:

• The value of didDocument.id MUST match the DID URL supplied for resolution (path and query are never dropped).
• The value of absolute did URL of verificationMethod.controller MUST match didDocument.id (currently not seeing any example of this passing for the opposite case, which did core allows today).

For the best example of something that "works" but is "not legal", see this:

{
  "http://example.gov/credentials/3732": {
    "@context": [
      "https://www.w3.org/2018/credentials/v1"
    ],
    "id": "http://example.gov/credentials/3732",
    "type": [
      "VerifiableCredential",
      "UniversityDegreeCredential"
    ],
    "issuer": {
      "id": "did:example:123?version-id=77d66171-b290-489c-abf1-95ae10725201"
    },
    "issuanceDate": "2020-03-10T04:24:12.164Z",
    "credentialSubject": {
      "id": "did:example:456"
    },
    "proof": {
      "type": "Ed25519Signature2018",
      "created": "2021-01-16T20:37:54.785Z",
      "jws": "eyJhbGciOiJFZERTQSIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..bDCoLFkyGIrcLLtiUZ-1tW30T6A2uV0j3R0FEtGK-qT3QEuWuvafd8cGfgp1rd7wAFARSrR50hCPS-W0ko1jBw",
      "proofPurpose": "assertionMethod",
      "verificationMethod": "did:example:123?version-id=77d66171-b290-489c-abf1-95ae10725201#credential-issuance-key"
    }
  },
  "did:example:123?version-id=77d66171-b290-489c-abf1-95ae10725201": {
    "@context": [
      "https://www.w3.org/ns/did/v1"
    ],
    "id": "did:example:123?version-id=77d66171-b290-489c-abf1-95ae10725201",
    "assertionMethod": [
      {
        "id": "#credential-issuance-key",
        "type": "Ed25519VerificationKey2018",
        "controller": "",
        "publicKeyBase58": "g9X6bPg6ZKWvc24zgqMhrXerMXoY878KqPxfBiEVLsJ"
      }
    ]
  }
}

Without the proposed changes, existing credential libraries will be incapable of supporting normatively legal did documents that use query parameters...

BTW, while it might seem like this is "only a problem for JSON-LD"... its actually a problem for anyone trying to use did core with verifiable credentials.

for VC-JWT there is no defined algorithm for verification method dereferencing (they don't have documentLoaders or frame)... which means that there is even more optionality in terms of how those folks might handle this issue.... if they read the spec today, they will 100% create solutions that work for JWT that are not legal JSON-LD... and then later encounter sever pain as they try and get their did method to "support both camps"....

[msporny]

I am very concerned by the results, most of the working examples are illegal according to did core spec today, and I could not produce a single "working legal example" of path and query params in a did document that worked with verifiable credentials and that was legal wrt normative requirements in did core today.... and also worked off the shelf with JSON-LD.

Oof, yeah... this is a problem. It's further exacerbated by the fact that a DID Resolver may not be able to change the DID Document that's returned (because it would break a signature over the document, for instance).

So, the linked data proof libs might need to be changed so they take an argument for a DID Document id mutator that can be aware of the query param mechanism. If we do that, DID Core wouldn't have to change, the VC libraries would only require one more optional parameter (id mutator), and the rest of the ecosystem can stay the same. That said -- I haven't put in the amount of thought that would be required to feel comfortable with this option -- just throwing it out there as one potential path forward. I expect @dlongley @dmitrizagidulin or @davidlehn will have a better idea of what to do here wrt. software implementations.

[dlongley]

I have more thoughts here but too little time at the moment. My main concern is that people may be trying to do things that they think are secure, but are not; that the trust they are putting in certain proofs just isn't there. We need to more fully explore a clear use case to determine if there's even a solution that makes sense here. By definition, a system where the verifier will blindly accept any past version of a verification method declared by the prover does not support revocation. I said more about this sort of thing in the thread about revocation here:

#386 (comment)

So, I am not a supporter of "just" referencing version-locked verification methods in LD proofs and making it such that verifiers that already accept proofs with non-version-locked verification methods would start accepting these without changes to their software. That introduces a security hole. I would rather have VC proof verification code fail closed in these circumstances and require something "extra" to accept a proof with a version-locked verification method. For example, if you want to enable proofs from the past to be accepted, include an additional "proof of existence" proof on the document and have it reference the version of the verification method that is acceptable. Then, make your resolver return that version when asking for the verification method:

{
   "id": "urn:mycred",
   "...",
   "proof": [{
      // details TBD, but proves the VC existed at the same time
      // as a particular DID Doc version
      "type": "MyProofOfExistenceBlockChainAnchorProofThing",
      "blink": "blink:btc:23498u2342/f234f23u23f/whatever",
      "anchoredResource": {
        "id": "urn:mycred",
        "didVersion": "did:example?version-id=123124",
        "contentHash": "z4917y912374y9743234"
      }
   }, {
      "type": "Ed25519Signature2018",
      "...",
      "verificationMethod": "did:example#key123"
   }]
}

In the above, a verifier configured with default software would reject the second proof because the verification method had been revoked. However, it could configure its software to first check the proof existence proof, and if they are happy with it (based on business rules), they could then configure their DID resolver to return the DID Document at the older version when checking the second proof. Then the second proof would verify and all would be well -- and it could be trusted because, presumably, the proof of existence had an acceptable root of trust that was not the same as the prover.

@OR13,

Without the proposed changes, existing credential libraries will be incapable of supporting normatively legal did documents that use query parameters...

I may be misunderstanding you, but your example and this text contradict the spec. Currently the id of a DID Document MUST be a DID not a DID URL. You cannot use query parameters in the id field of a DID Document, see: https://www.w3.org/TR/did-core/#identifier-0 and https://www.w3.org/TR/did-core/#did-syntax

So examples that use query parameters in the id field of a DID Document are, in fact, NOT "normatively legal" at present.

[OR13]

So examples that use query parameters in the id field of a DID Document are, in fact, NOT "normatively legal" at present.

thats correct, and but just so everyone is clear... there are currently no normatively legal examples of VCs (or really ANY resources, including the kind that @talltree and @brentzundel wanted supported with ?resource=true) that support path or query.... we should be putting that in big bold red letters right next to the id property in core properties...

my examples say "illegal but working"... meaning a developer will have to violate the spec to do what they want to do... I don't think we can stop them at this point.

in other words... most of the use cases for version-id may in fact not be normatively legal...

The safest thing to do would be to remove path and query from the spec, until they are both allowed in the id field.

We can't make path and query based VCs "fail closed"... developers will just ignore JSON-LD like they are already doing, and since did core now supports 3+ representations assuming folks will care about anything JSON-LD specific in this spec is a really, really bad idea.

We need normative language that treats DID URLs as IRIs and lets developers rely on what an IRI is regardless of their chosen representation... we currently have JSON-LD making a distinction between DIDs and DID URLs... where other representations are treating both DIDs and DID URLs as IRIs.... I would be shocked to not see the normatively illegal, but working JSON-LD examples reflected in CBOR and JSON... I don't think the proponents for 3+ representations considered the cost of the ambiguity they created... this is chickens coming home to roost.... ambiguity at this layer of the spec is akin to a terminal illness.

[dhh1128]

If we can't reference ?version-id=X as a normatively legal feature of the DID spec, I will formally object to the standard. It is a glaring omission that subverts entire families of use cases.

Orie's statement emphasizes that he's worried about VCs not supporting this feature. I don't care about that, since the credentials I work with don't bind to credential holders with DIDs and therefore don't care about the value of id property in a VC, either for the credential itself or for any of its subjects. However, I do need it to be the case that when a DID method supports this feature, it is not doing something illegal or outside the boundaries of the standard.

[dhh1128]

I left some suggested alternate wording as a comment on Orie's PR: #548 (comment)

[dlongley]

@dhh1128,

If we can't reference ?version-id=X as a normatively legal feature of the DID spec, I will formally object to the standard. It is a glaring omission that subverts entire families of use cases.

I don't think this issue is about whether or not ?version-id=X is supported (I think we all support it). Rather, it's about what you get when you dereference a DID URL that contains it. I think you should get something that looks the same as what you would have gotten if you had performed resolution when the referenced version was "current". That's what I believe is being referenced by such a DID URL -- and I think it's easier for developers to understand and work with, would allow for better code reuse, and is generally better for the use cases. You should not get something that's been rewritten to include ?version-id=X in various places.

[TallTed]

You should not get something that's been rewritten to include ?version-id=X in various places.

I have come to think this is generally correct about the DID Document; whatever you would have gotten within that DID Document today, when ?version-id={CURRENT} was omitted, is what you should get within that DID Document when you request ?version-id=X in the future, when X != {CURRENT}.

But I think there must be some difference in the surrounding metadata or other encapsulation — which on that future date should indicate that at that time you dereferenced/resolved a URL that included the ?version-id=X parameter with an X which was no longer current.

In other words, I'm thinking that when you dereference/resolve a DID URL that includes ?version-id=X, you should get a (DID?) Document/envelope/wrapper (which knows about and references ?version-id=X) that contains the requested version of the DID Document (which neither appears to know about nor references ?version-id=X), IFF that now-historic DID Document itself didn't know about nor reference it.

That said, I wonder how you or I or anyone (as the dereferencer/resolver) is to know that they should be requesting ?version-id=X if it's never mentioned anywhere? It seems that ?version-id=X is the wrong parameter to use; perhaps it should be ?as-of=DATETIME?

I hope that's clearer than I fear...

[dhh1128]

I am aligned with @dlongley 's comment.

I also agree with @TallTed . Regarding the final question, "how to know to request version-id=X if it's never mentioned anywhere" -- the peer DID method that I wrote would use the hash of the DID doc as the value of X, and the Indy DID method would use the ledger transaction identifier, I think.

[TallTed]

@dhh1128 -- You provide what might be used as values for X in two DID methods, but it seems to me they are just as opaque and undiscoverable (if not more so) as simple version numbers... e.g., how would I know the hash of a DID doc I haven't yet retrieved/requested (but someone else has used or relied on), in order to use that hash sometime in the future? At least with an as-of datetime, I can use a datetime associated with the thing I'm trying to validate.

[dhh1128]

I am not opposed to as-of dates. Those are also useful. The did:indy method will support both. The did:peer method will only support version-id, because there is no authority in its ecosystem, recording the dates.

Regarding the question, "How would I know...", I would say that if another party is using a DID doc, they provide the hash to you so you can reference it.

[peacekeeper]

The relative-ref DID Parameter, which was previously known as relativeRef

Just a quick update to my own earlier comment: relative-ref, which was previously known as relativeRef, is now proposed to change back again to relativeRef (see #553). Sorry for the confusion.

[OR13]

I think I have managed to cut this issue free from the other PR on "rotation/recovery", in changes to that PR, I opted to reimplement the PR because it was faster than slogging through rebase.... #569

But I believe I have addressed the spirit of all proposed changed in that PR ^

Regarding this issue I want to make a couple of points.

Orie's statement emphasizes that he's worried about VCs not supporting this feature. I don't care about that, since the credentials I work with don't bind to credential holders with DIDs and therefore don't care about the value of id property in a VC, either for the credential itself or for any of its subjects.

I know Indy Credentials don't follow the VC Spec regarding verificationMethod.... we've argued about this a lot before :) .... However, this issue also applies to Indy Credential Schemas, which are either valid LD or not....

If Indy Credential Schemas are just plain old json, this is not an issue.... and I would suggest requesting them with accept: did+json... then as long as what comes back has an id that is a DID and NOT and DID_URL you will be fine..... whatever else is in that document is allowed, because DID Core allows arbitrary JSON, thats the point of did+json.

However, if you want Indy Credential Schemas to be both did+json and did+ld+json which is possible, and IMO ideal for folks who prefer stronger security properties AND compatibility with existing systems... you will have the same problem that VCs have.... and that I have provided examples of here: https://github.com/OR13/did-params-and-you/tree/master/examples

I believe that all the "illegal but working" stuff would apply to HyperLedger Indy Credentials and their Schemas.

I have never seen an Indy Credential Schema as JSON DID Document, despite @brentzundel @talltree @jandrieu arguing over type and resource?=true for a few WG calls :)

Perhaps it is time to provide an example of Indy Credential Schema that is represented in JSON and stored on a ledger, and then we can answer the question of wether did core supports what you are wanting to do more concretely.

To be clear.... I want Indy Credential Schemas stored on ledgers to be valid JSON and JSON-LD and be compliant with DID Core.... In absence of evidence that they are, I am assuming they are not... How HyperLedger Indy Credentials ended up being handled in the VC spec is one of its biggest failures, we should try and hold ourselves to a higher standard.

I would like to prove that what Indy Credentials are doing is legal wrt did core, and I would like to include Indy Credential examples in did core, like we have for JWT and LD Proofs already:

https://w3c.github.io/did-core/#proving

I don't have the indy credential skills to actually do this... we should find someone who does, and get them to add a PR before DID Core closes the book on Indy's failure to define stuff properly, the same way the VC Data Model did.

What we need:

1. example of an indy credential schema that is identified with a DID URL
2. example of an indy credential that uses that schema with DIDs

Ideally these examples would use did:example to show they are meant to be relevant to systems other than HyperLedger Indy, and they would include query, version, ?resource=true... to remove an ambiguity about the ecosystems intentions wrt these things.

[dhh1128]

I know Indy Credentials don't follow the VC Spec regarding verificationMethod.... we've argued about this a lot before :)

I consider this an incorrect characterization. Please read section 4.8 of the VC spec carefully (where the proof section is formally and normatively defined) and section 7.4, where it is discussed again. I believe you will see that verificationMethod is NOT normatively required, and that the spec includes this explicit note: "As discussed in Section § 1.4 Conformance, there are multiple viable proof mechanisms, and this specification does not standardize nor recommend any single proof mechanism for use with verifiable credentials." That sounds a bit different than the steady drumbeat of "must use LD Proofs or at least verificationMethod to comply with the spec", doesn't it? Section 7.4 actually recommends that ZKP-oriented credentials do something different: "If strong anti-correlation properties are required, it is advised that signature values and metadata are regenerated each time using technologies like third-party pairwise signatures, zero-knowledge proofs, or group signatures." So, Indy follows the recommendation of the spec and then gets repeatedly skewered for not following the VC spec. Every time this "Indy Credentials don't follow the VC spec regarding verificationMethod" misunderstanding gets repeated, it further isolates Indy and lessens the chances of bridge-building.

What is really happening in this case is that Indy doesn't follow the assumptions/tribal knowledge of JSON-LD advocates (or it doesn't follow the JSON-LD spec), NOT that it doesn't follow the VC data model. (It is true that Indy credentials don't follow the VC spec completely, but verificationMethod is not a true example of their non-compliance. Nor are most of the other examples cited by JSON-LD advocates.)

If Indy Credential Schemas are just plain old json, this is not an issue.... and I would suggest requesting them with accept: did+json... then as long as what comes back has an id that is a DID and NOT and DID_URL you will be fine..... whatever else is in that document is allowed, because DID Core allows arbitrary JSON, thats the point of did+json.

Yes, today they are just plain old JSON.

Indy schemas are not retrieved from a ledger using HTTP content negotiation, so their MIME type is irrelevant right now. But this is a good suggestion to keep in mind for the future.

Perhaps it is time to provide an example of Indy Credential Schema that is represented in JSON and stored on a ledger, and then we can answer the question of wether did core supports what you are wanting to do more concretely.

An Indy Credential Schema looks like this (as documented in https://github.com/hyperledger/indy-sdk/tree/master/docs/how-tos/save-schema-and-cred-def, published 2 years ago):

{
  "id": "1",
  "name": "gvt",
  "version": "1.0",
  "attrNames": ["age", "sex", "height", "name"]
}

The attrNames array is really what matters (it's the essence of the schema); the rest is just metadata used in the ledger transaction. I don't think there is a question about whether such a data structure can be stored inside another JSON document. The array has little intersection with JSON-LD, since it introduces no new JSON-LD terms -- just some string literals.

Indy schemas tomorrow may be far more elaborate; Brent has published a series of detailed Indy HIPEs and Aries RFCs about their format.

To be clear.... I want Indy Credential Schemas stored on ledgers to be valid JSON and JSON-LD and be compliant with DID Core.... In absence of evidence that they are, I am assuming they are not... How HyperLedger Indy Credentials ended up being handled in the VC spec is one of its biggest failures, we should try and hold ourselves to a higher standard.

I am mildly annoyed with the awkward way that Indy credentials map to and from the VC spec, but deeply frustrated by the human communication around the topic, which has distorted the problem in size and nature. I don't believe the latter problem will be fixed by spec content, though improving the spec content is a noble exercise.

I would like to prove that what Indy Credentials are doing is legal wrt did core, and I would like to include Indy Credential examples in did core, like we have for JWT and LD Proofs already:

The issue I have with this is that I think you're imagining a false parallel. In their issued form, Indy credentials are not intended to be shared. Rather, a new JIT credential is created from the issued artifact every time sharing occurs. Therefore, looking for issued Indy credentials to map onto a spec about what should be interoperable during a sharing operation can have little benefit.

What would be a useful exercise is to show how an Indy proof (the JIT derived VC that's shared and is thus an interoperability surface) maps to the VC spec. I raised a PR against Indy SDK in August 2020 to do that. It has not been accepted because it requires a dirty hack to fetch private variables from an internal cryptographic data structure. Rewriting it to be a pure JSON transform (no dirty hack) is probably a couple weeks of effort that I haven't had time to do. But regardless of the PR's state, here is the documentation associated with it: https://docs.google.com/document/d/1ntLZGMah8iJ_TWQdbrNNW9OVwPbIWkkCMiid7Be1PrA/edit#

I don't have the indy credential skills to actually do this... we should find someone who does, and get them to add a PR before DID Core closes the book on Indy's failure to define stuff properly, the same way the VC Data Model did.

As I sat at RWOT 9 in Prague (Sep 2019), clapping for the announcement that the VC spec was at long last finalized, the "how to write an Indy schema to the ledger" doc that I cited above was already almost a year old. It had been carefully tested, and it embodied techniques used in shipping code in production. The conclusion I draw from this is that characterizing what happened with the VC data model as a failure on Indy's part to define stuff properly is really unjust. Long before either of these events, Lovesh and I submitted an enormously detailed PR to the VC spec, trying to help the spec broaden its understanding of the JIT derived credential phenomenon at the heart of our ZKP approach. Getting the PR to affect the VC spec proved to be a slog; certainly we invested hundreds or even thousands of person-hours. Brent eventually took over that effort for us, and heroically got the effort to some semblance of coherence and closure. We did succeed in making certain features optional rather than required (e.g., an id property for a credential subject), and we did succeed in altering the non-normative language to acknowledge the viability of ZKP techniques in the problem space. But most of what got adjusted has been ignored by VC advocates who diss Indy for taking the very routes we fought so hard to put into the spec. We are told that we are non-standard because we use link secrets rather than DIDs to bind the holder to the VC. We are told that we are non-standard because we don't have a verificationMethod in our proofs, or because our signatures are tied to a credentialDef key instead of a key in a DID Document. None of these characteristics are required by the standard; they are only assumed by folks who believe the standard requires their favorite techniques. Further, modifying our code to comply with all required features of the spec that we actually do miss (e.g., using the PR I cited above, which would give you Indy in 100% compliant mode) will yield no interoperability, since nobody in the ecosystem intends to support the signature types we use.

I think the deeper issue here is that we have a fundamental disconnect about the scope or legitimate purpose of these standards. The VC standard is a data model standard. It is not supposed to say how that model is realized, except in very general ways, and it is not supposed to achieve interoperability at anything except the abstract data model level. The fact that it provides some examples does not mean that the examples are normative -- and the spec explicitly makes this point, repeatedly. But the community has used the spec like a data format standard anyway, and I feel like I've been clubbed over the head by critics who refuse to acknowledge that their favorite conventions are not actually as standardized as they claim.

Similarly, the DID spec is supposed to describe what is possible and fundamental about DIDs. It is not supposed to describe all the details about how DIDs are used in VCs, or how DIDs are used to publish schemas, except at a very high level. Putting in examples that are non-normative should not be necessary, since we shouldn't put too much stock in those examples anyway. Much of the reason why I have been uncooperative on this topic is that I don't want to reinforce the false impression that these standards actually standardize their non-normative examples.

What we need:

1. example of an indy credential schema that is identified with a DID URL
2. example of an indy credential that uses that schema with DIDs

I will leave this to Brent and Drummond.

[OR13]

The following indy credential schemas are both valid did+json and did+ld+json

Assuming that someone in hyperledger indy ecosystem can provide a context for indy credential schemas, hosted at:

https://w3id.org/indy/v1 or similar (happy to help set that up, just give me a list of terms and their definitions.).

Example 1

{
  "@context": ["https://www.w3.org/ns/did/v1", "https://w3id.org/indy/v1"]
  "id": "did:example:123",
  "name": "gvt",
  "version": "1.0",
  "attrNames": ["age", "sex", "height", "name"]
}

Example 2

{
  "@context": ["https://www.w3.org/ns/did/v1", "https://w3id.org/indy/v1"]
  "id": "did:example:123",
  "type": "PersonSchema",
  "name": "gvt",
  "version": "1.0",
  "attrNames": ["age", "sex", "height", "name"]
}

The following examples are illegal according to did core today, for both did+json AND did+ld+json:

Example 3

{
  "@context": ["https://www.w3.org/ns/did/v1", "https://w3id.org/indy/v1"]
  "id": "did:example:123?version=1.0",
  "name": "gvt",
  "version": "1.0",
  "attrNames": ["age", "sex", "height", "name"]
}

Example 4

{
  "@context": ["https://www.w3.org/ns/did/v1", "https://w3id.org/indy/v1"]
  "id": "did:example:123?/schemas/people",
  "name": "gvt",
  "version": "1.0",
  "attrNames": ["age", "sex", "height", "name"]
}

Notice that @context has nothing to do with making these illegal...

This is the normative requirement that makes example 3 and 4 illegal:

https://w3c.github.io/did-core/#property-summary

"id is required, and it must be a DID"

A DID cannot contain path, query or fragment.

It is this exact same requirement that makes the verifiable credential examples "illegal, but working":

https://github.com/OR13/did-params-and-you/tree/master/examples

To be blunt... this normative requirement is likely to get ignored by any developers attempting to store arbitrary data on a verifiable data registry.

Interpretation of this requirement might lead to a preference for JSON over JSON-LD see the tests I linked for evidence.

@brentzundel and @talltree have already expressed a desire to store arbitrary data on a verifiable data registry.

@jandrieu has objected to this, but ironically not objected to the abstract data model and the rest of the spec that essentially encourages this by describing extensibility features of DID Documents and saying that unknown properties must be preserved.

I recommend the following to any DID Method implementers:

1. Ignore the DID Core requirement that says that a DID Document id MUST be a DID and not a DID URL.

• especially ignore this requirement if you are building a linked data platform that makes any use of path or query.

2. Use the extensibility features of the DID Core data model to store whatever JSON, JSON-LD or CBOR you want in a DID Document.

• if you only care to support JSON do whatever you want in the DID Document.
• if you want to support JSON and JSON-LD make sure all terms are defined in the @context and that id and type are used correctly... see the JSON-LD spec for how to use them.

3. When you can, make your JSON and JSON-LD the same, so that clients don't have trouble handling 2 nearly identical did document formats.

• It is legal to return did+ld+json when did+json is requested... this allows methods like did:web to use a single json file for both representations, and also means that implementers that care to support both, don't have to do extra work once they support JSON-LD, and if they don't case to support JSON-LD, they are not required to.

[brentzundel]

@OR13 please correct me if I don't understand (sincerely), but I think dropping DID Parameters for schemas or other resources stored on a ledger may only be a problem if the schema or other resources are delivered via a DID Document.

My understanding of the consensus the group came to (which resulted in resource=true being moved to the DID Registries) was that a DID Document should never be the delivery vehicle for resources, but that resources identified by DIDs must be retrieved by dereferencing the DIDs rather than resolving them.

[OR13]

@brentzundel yes, although i am not sure dereferencing is defined well enough.... I guess my point is that did core makes a number of json based document formats illegal, (by preventing IRIs like didDocument.id from containing things otherwise legal in an IRI, for example query and path).... depending on how. dereferencing is defined... that might cause problems in the resulting document... for sure it will push some folks to violate the did spec, since this restriction on the IRI is not obvious.

[vdods]

I'm curious what the current status of this is.

And at risk of making things more complex, how would the "hl" query parameter (hashlink) be handled? It's infeasible to include the hash of a document within the document, so that presents an obstacle to treating "hl" as a query param for inclusion in the DID document as described in this thread.

[msporny]

I'm curious what the current status of this is.

IMHO, the current status is "unlikely to be resolved any time soon". The DID WG published the v1.0 REC and is expected to now go into maintenance mode. We will gather implementation feedback over the next year or two and then pick this item up in the v2.0 work (unless it's clear that this particular issue is causing significant interoperability problems).

And at risk of making things more complex, how would the "hl" query parameter (hashlink) be handled? It's infeasible to include the hash of a document within the document, so that presents an obstacle to treating "hl" as a query param for inclusion in the DID document as described in this thread.

Yep, good point, and I expect it would be reasonable to drop it. Similarly, there could be an argument made for keeping it "the id should reflect how the individual got to the resource in the first place... canonicalization should be used to determine if two resources are the same resource"... and of course, we invoke HTTP Range 14 and go around and around in circles. :P

All this to say, there are some fundamental architectural discussions that might need to happen around this specific item and, for the time being, it's probably safer to just strip the hl parameter... we need more implementer feedback to see if there is a use case for NOT stripping parameters like hl.

Hope that helps.