Did-core: Unclear which verification methods are authorized for did document operations

[tplooker]

In section 7.5 we currently have the following languages around the did controller

The value of the controller property MUST be a valid DID or an array of valid DIDs. The corresponding DID document(s) SHOULD contain authorization relations that explicitly permit the use of certain verification methods for specific purposes.

With this it remains unclear to me what proof purpose is used by the DID controller to express which verification methods are authorized to update a DID document.

E.g take the following DID documents

{
  "@context": "https://www.w3.org/ns/did/v1",
  "id": "did:example:123456789abcdefghi",
  "controller": "did:example:bcehfew7h32f32h7af3",
  "service": [{
    "type": "VerifiableCredentialService",
    "serviceEndpoint": "https://example.com/vc/"
  }]
}

{
  "@context": "https://www.w3.org/ns/did/v1",
  "id": "did:example:bcehfew7h32f32h7af3",
  "publicKey": [{
      "id": "did:example:123456789abcdefghi#keys-2",
      "type": "Ed25519VerificationKey2018",
      "controller": "did:example:123456789abcdefghi",
      "publicKeyBase58": "H3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
  }],
  "service": [{
    "type": "VerifiableCredentialService",
    "serviceEndpoint": "https://example.com/vc/"
  }]
}

Because the controller of did:example:123456789abcdefghi has one verification method listed in their did document, but it is not listed under any explicit proof purpose, is did:example:123456789abcdefghi#keys-2 authorized to update the did document of did:example:123456789abcdefghi?

Another variation of this example is when the controller is the subject

{
  "@context": "https://www.w3.org/ns/did/v1",
  "id": "did:example:bcehfew7h32f32h7af3",
  "publicKey": [{
      "id": "did:example:bcehfew7h32f32h7af3#keys-2",
      "type": "Ed25519VerificationKey2018",
      "controller": "did:example:bcehfew7h32f32h7af3",
      "publicKeyBase58": "H3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
  }],
   "authentication": [{
      "id": "did:example:bcehfew7h32f32h7af3#keys-1",
      "type": "RsaVerificationKey2018",
      "controller": "did:example:bcehfew7h32f32h7af3",
      "publicKeyPem": "-----BEGIN PUBLIC KEY...END PUBLIC KEY-----\r\n"
  }],
  "service": [{
    "type": "VerifiableCredentialService",
    "serviceEndpoint": "https://example.com/vc/"
  }]
}

Which key is authorized to update this document? did:example:bcehfew7h32f32h7af3#keys-1 or did:example:bcehfew7h32f32h7af3#keys-2 or both?

[msporny]

With this it remains unclear to me what proof purpose is used by the DID controller to express which verification methods are authorized to update a DID document.

It's DID Method specific. I forget if the spec says this yet or not, if it doesn't, it should.

Veres One, for example, uses the verification method associated with capabilityInvocation to update the DID Document. In Veres One, every DID Document is also an Authorization Capability and invoking that capability enables you to update the document. This creates a clean separation between authentication (like logging into a website or system), assertionMethod (for issuing Verifiable Credentials), and capabilityInvocation (for updating the DID Document).

Other DID Registries should be allowed to make different choices, which is why the spec should delegate how that works to DID Methods.

Would a PR that makes this clear in the spec address your concern?

[msporny]

This issue is blocked by the DID Core registry discussion.

The expectation is that one of the outcomes of the DID Core registry discussion will clearly list which verification methods are authorized for DID Documents.

[OR13]

@csuwildcat this is pretty much exactly we have been discussing... sidetree will either express its "internal representation" in a way that conforms with whatever is decided here, or doesn't.

certainly we will need to define "recoveryKey" verificationMethod for sidetree... I would suggest that we also use assertionMethod as the mechanism for this in sidetree... but this is why I believe this is a bit method specific.

[msporny]

At present, either DID Core or DID Methods will specify which verification methods are authorized to do which DID Document operations. We need a special topic call to finish this off. My expectation is that we'll decide that DID Methods are in charge of saying which verification methods are authorized to do which DID Document operations (as getting all DID Method implementers to agree that it should be capabilityInvocation that does this is highly unlikely).

[peacekeeper]

This is possibly a duplicate of https://github.com/w3c/did-core/issues/289

The spec currently has the following language in 7.2 Method Operations:

Determining the authority of a party to carry out the operations is method-specific. For example, a DID method MAY:

• use the verification methods listed under authentication to decide whether an update/deactivate operation is allowed; or
• use other constructs in the DID Document to decide this, for example, a verification method specified under capabilityInvocation could be used to verify the invocation of a capability to update the DID Document.; or
• not use the DID Document at all to decide this, but have rules that are "built into" the method.

[dlongley]

PR #312 may enable us to close this issue.

[msporny]

We should wait for PR #312 to be merged, assert that it addresses this issue, and then suggest we close the issue and see if there are objections.

[kdenhartog]

I think that makes sense. I'll mention this to Tobias as well to get him to take a look at it as well and weigh in.

[dlongley]

We should close this issue, we have a verification relationship available for performing actions/operations -- and it can be used by any DID method (see #312). Otherwise, DID methods may do their own thing.

[OR13]

Seems like the consensus is that there is no standard way of expressing "these vms control this did / are used for this dids operations".... I suggest we close this issue, we already have spec text that discusses authentication and capabilityInvocation... and Sidetree has specifically opted to NOT expose keys that control the identifier in the did document... despite them being public and available in resolver meta data... everyone is handling this differently :)

[peacekeeper]

+1 to closing, in my opinion this is sufficiently covered in 7.2 Method Operations.

[tplooker]

Agreed, subsequent PR's have addressed this issue.