Can verification method exist as a separate document?

[silverpill]

Section 3.3 "Retrieve Verification Method":

2. Let controllerDocumentUrl be the result of parsing vmIdentifier according to the rules of the URL scheme and extracting the primary resource identifier (without the fragment identifier).

Later, controllerDocumentUrl is used to retrieve the controlled identifier document:

4. Let controllerDocument be the result of dereferencing controllerDocumentUrl, according to the rules of the URL scheme and using the supplied options.

This only works if the verification method is defined as a fragment within the controller document. Is that a requirement?

The text in section "2.2 Verification Methods" also seems to imply that verification methods should be embedded in some controller document, but this is not stated explicitly. The description of the verificationMethod.id property doesn't say that URL must contain a fragment identifier.

Example:

(controller document)

{
  "@context": "https://www.w3.org/ns/cid/v1",
  "id": "https://controller.example",
  "authentication": [
    "https://controller.example/main-key"
  ]
}

(verification method: not a fragment)

{
  "id": "https://controller.example/main-key",
  "type": "Multikey",
  "controller": "https://controller.example",
  "publicKeyMultibase": "z6MkmM42vxfqZQsv4ehtTjFFxQ4sQKS2w6WR7emozFAn5cxu"
}

[msporny]

IMHO, yes, what you provide above is valid per the data model.

However, there are questions that are raised with that approach... like, how do you ensure that the item pointed to is the same one intended by the DID document? (what happens if an attacker changes it)

There are also issues related to whether or not there might be DDoS attacks, dereferencing loops, and other things one needs to pay attention to. So, while it's allowed by the data model, we haven't seen any use cases where the security risks are worth the added complexity. That doesn't mean there aren't any, so perhaps we can use this issue to discuss the possibilities.

[silverpill]

I think verification methods that are on the same domain/origin as the controller could be allowed, because this doesn't seem to introduce new attack vectors. If domains are different, the risks are higher because there are two trusted parties instead of one.

That said, I have no objections to verification methods being fragments.

[iherman]

That said, I have no objections to verification methods being fragments.

One way or other, this must then be specified in the specification. Either this restriction must be explicitly specified, or the situation must be explicitly mentioned in the security section (at the moment there are sections on verification method rotation and revocation, but nothing that would cover this case).