-
Notifications
You must be signed in to change notification settings - Fork 93
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unclear which verification methods are authorized for did document operations #195
Comments
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? |
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. |
@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 |
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 |
This is possibly a duplicate of #289 The spec currently has the following language in 7.2 Method Operations:
|
PR #312 may enable us to close this issue. |
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. |
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. |
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. |
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 |
+1 to closing, in my opinion this is sufficiently covered in 7.2 Method Operations. |
Agreed, subsequent PR's have addressed this issue. |
In section 7.5 we currently have the following languages around the did controller
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
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, isdid:example:123456789abcdefghi#keys-2
authorized to update the did document ofdid:example:123456789abcdefghi
?Another variation of this example is when the controller is the subject
Which key is authorized to update this document?
did:example:bcehfew7h32f32h7af3#keys-1
ordid:example:bcehfew7h32f32h7af3#keys-2
or both?The text was updated successfully, but these errors were encountered: