Examples such as Example 3 contain URIs that contain a path that is actually not sent during dereferencing. As dereferencing is at the core of the definitions around controlling a document, such URIs could better be avoided, to at least avoid confusion and to avoid problems with relative URI reference resolution.
Consider Example 3:
Example 3: Usage of the id property
{
"@context": "https://www.w3.org/ns/cid/v1",
"id": "https://controller.example",
"authentication": [{
"id": "https://controller.example#authn-key-123",
"type": "Multikey",
"controller": "https://controller.example",
"publicKeyMultibase": "z6MkmM42vxfqZQsv4ehtTjFFxQ4sQKS2w6WR7emozFAn5cxu"
}]
}Here we have two URIs, https://controller.example and https://controller.example#authn-key-123 with an empty path component.
Now consider RFC9112, which says Sec. 3.2.1. in RFC9112 about a request other than OPTIONS or CONNECT, i.e. about dereferencing using GET:
If the target URI's path component is empty, the client MUST send "/" as the path within the origin-form of request-target.
Also consider RFC3986, which says Sec. 5.1.3 in RFC3986 about the base URI against which relative references are to be resolved:
If no base URI is embedded and the representation is not encapsulated
within some other entity, then, if a URI was used to retrieve the
representation, that URI shall be considered the base URI. Note that
if the retrieval was the result of a redirected request, the last URI
used (i.e., the URI that resulted in the actual retrieval of the
representation) is the base URI.
Then you get a problem with relative reference resolution, e.g. if the above JSON can be retrieved from https://controller.example/, a relative URI, say #authn-key-123 to stick with the example, cannot be resolved to https://controller.example#authn-key-123.
Examples such as Example 3 contain URIs that contain a path that is actually not sent during dereferencing. As dereferencing is at the core of the definitions around controlling a document, such URIs could better be avoided, to at least avoid confusion and to avoid problems with relative URI reference resolution.
Consider Example 3:
Example 3: Usage of the
idproperty{ "@context": "https://www.w3.org/ns/cid/v1", "id": "https://controller.example", "authentication": [{ "id": "https://controller.example#authn-key-123", "type": "Multikey", "controller": "https://controller.example", "publicKeyMultibase": "z6MkmM42vxfqZQsv4ehtTjFFxQ4sQKS2w6WR7emozFAn5cxu" }] }Here we have two URIs,
https://controller.exampleandhttps://controller.example#authn-key-123with an empty path component.Now consider RFC9112, which says Sec. 3.2.1. in RFC9112 about a request other than OPTIONS or CONNECT, i.e. about dereferencing using GET:
Also consider RFC3986, which says Sec. 5.1.3 in RFC3986 about the base URI against which relative references are to be resolved:
Then you get a problem with relative reference resolution, e.g. if the above JSON can be retrieved from
https://controller.example/, a relative URI, say#authn-key-123to stick with the example, cannot be resolved tohttps://controller.example#authn-key-123.