w3c
Can Verification Method Ids be fragments?
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 ]
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
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.
I believe an example would be useful...it took me a few minutes to find the section.
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.
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.
