Add example for Verification Method ID as a fragment

[wip-abramson]

For example

{
      "id": "#key-3",
      "type": "JsonWebKey2020",
      "controller": "did:example:123",
      "publicKeyJwk": {
        "kty": "EC", // external (property name)
        "crv": "secp256k1", // external (property name)
        "x": "U1V4TVZVMUpUa0ZVU1NBcU9CRm5IbmFaaEpGNkxkdWx", // external (property name)
        "y": "i5a2NtJoUKXkLm6q8nOEu9WOkso1Ag6FTUT6k_LMnGk" // external (property name)
    }
}

My understanding was that this was possible, but reading the spec I am not not sure.

The spec states for the id property:

The value of the id property for a verification method MUST be a string that conforms to the rules in Section 3.2 DID URL Syntax.

The did-url ABNF is below.

did-url = did path-abempty [ "?" query ] [ "#" fragment ]

[decentralgabe]

See 3.2.2. Relative DID URLs

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.

It would be helpful to add references to this section

[wip-abramson]

Ah great, I missed that. Think this can be closed, unless you are suggesting we should update the references?

I think it is in there, as it references 3.2 which includes 3.2.2. I just didn't read far enough down, my bad.

One thing we might consider is adding an example that uses relative DID-URLs to section A.

[decentralgabe]

I believe an example would be useful...it took me a few minutes to find the section.

[wip-abramson]

Happy to submit a PR for this. Would you prefer a new example, or should I just modify an existing one to include relative URLs.

[w3cbot]

This was discussed during the #did meeting on 19 December 2024.

View the transcript

w3c/did-core#860

manu: this one is also for you, Wip :)
… The W3C TAG raised an issue on the CID spec, saying we don't define fragment processing rules.
… It was not a problem when it was plain JSON-LD, but now that it has its own mime-type (and likewise for application/did),
… we need to define fragment-processing rules.
… Actually, I will make a new issue.
… If we are lucky, we can point to CID fragment processing rules, and avoid a class-3 change.

markus_sabadello: the IANA section says that we defer to the fragment-processing rules from JSON-LD.
… Isn't that sufficient?

<JoeAndrieu> +1 for us just using JSON-LD fragment processing rules

manu: now that we made the `@context` optional, and since we target communities that do not like JSON-LD,
… we might get some pushback if we do that.

ivan: is it possible to define a DID document as did+cid, and therefore inherit from CID like that?

manu: we could, but I suggest we don't, considering the troubles we had about this whole suffix question!
… It would be painful to explain which part we inherit, and which part we don't.

ivan: ok, forget it.

---