What's the expected behavior for a DID Document that contains the same id property for publicKeys?

[kdenhartog]

Given the following DID Document, what's the expected result from the dereference function?

  {
    "@context": [
      "https://www.w3.org/ns/did/v1",
      "https://w3id.org/security/suites/ed25519-2020/v1"
    ],
    "id": "did:example:123",
    "verificationMethod": [
      {
        "id": "did:example:123#publicKey",
        "type": "Ed25519VerificationKey2020",
        "controller": "did:example:123",
        "publicKeyMultibase": "zAKJP3f7BD6W4iWEQ9jwndVTCBq8ua2Utt8EEjJ6Vxsf"
      },
      {
        "id": "#publicKey",
        "type": "Ed25519VerificationKey2020",
        "controller": "did:example:123",
        "publicKeyMultibase": "differentPublicKeyExample....."
      }
    ],
}

dereference("did:example:123#publicKey", {"accept": "application/did+ld+json"}) => ????

[peacekeeper]

Good question, I think that's basically a question for JSON-LD itself and is not really specific to DIDs or DID documents or DID URL dereferencing.

The JSON-LD spec at https://w3c.github.io/json-ld-syntax/#application-ld-json says this:

Fragment identifiers used with application/ld+json are treated as in RDF syntaxes, as per RDF 1.1 Concepts and Abstract Syntax [RDF11-CONCEPTS].

But this isn't very helpful, is it?

My assumption has been that the dereferencer picks the JSON object with the matching id, and also adds all applicable contexts, i.e. the result in your specific example would be:

  {
    "@context": [
        "https://www.w3.org/ns/did/v1",
        "https://w3id.org/security/suites/ed25519-2020/v1"
    ],
    "id": "did:example:123#publicKey",
    "type": "Ed25519VerificationKey2020",
    "controller": "did:example:123",
    "publicKeyMultibase": "zAKJP3f7BD6W4iWEQ9jwndVTCBq8ua2Utt8EEjJ6Vxsf"
  }

But this isn't really documented anywhere; and for application/did+json the use of the fragment is completely undefined (probably assumed to be the same as for application/did+ld+json).

[kdenhartog]

In JSON-LD's case it appears like it's treating them as nodes that can be merged (I think that's the right way to describe what's happening when the properties are being merged in the output of the frame). Here's a json-ld playground example to see what I mean.

This is interesting and unexpected for me. In our logic for dereferencing I realize now that it's just getting the first instance encountered which means the #publicKey instance wouldn't ever be returned since the JSON array is ordered and would get processed first by our logic. At least that's deterministic, but it seems a bit unexpected if I was really trying to reference the second key instead.

I'm wondering what the spec text should say here.

My initial proposal would be:

An id property MUST NOT match any other @id properties within the same DID Document. Seems good enough to cover it for now.

@dlongley and @OR13 curious what your thoughts are on this

[OR13]

An id property MUST NOT match any other @id properties within the same DID Document. Seems good enough to cover it for now.

Probably should have been explicit:

The Absolute DID URL of a verification relationship or service id must be unique and present only once in the did document.