w3c / did-core

W3C Decentralized Identifier Specification v1.0
https://www.w3.org/TR/did-core/
Other
407 stars 96 forks source link

Deactivated flag moved to DID Document Metadata #581

Closed csuwildcat closed 3 years ago

csuwildcat commented 3 years ago

Preview | Diff

csuwildcat commented 3 years ago

@msporny don't you think we should state that the DID Method MUST populate this with a true value if the DID has been deactivated? Given we tell them every method must take care to sort out their deactivated story, how then is it not logical to tell the constructor of the resolution response to mark this as true if the method resolution determines it is deactivated?

csuwildcat commented 3 years ago

I guess I feel like we're taking the whole testability thing a tad too far, and these kinds of clear, logical directives that naturally follow from the other directives to DID Methods elsewhere in the spec are being watered down as a result.

msporny commented 3 years ago

@msporny don't you think we should state that the DID Method MUST populate this with a true value if the DID has been deactivated? Given we tell them every method must take care to sort out their deactivated story, how then is it not logical to tell the constructor of the resolution response to mark this as true if the method resolution determines it is deactivated?

That would be a DID Method-specific test... how do we test this without driving a specific DID Method implementation to register a DID and then deactivate the DID and then use a resolver to check that the DID is deactivated? That's the only way that I know of to test the statement. Our charter also lists DID Method specifications as out of scope:

https://www.w3.org/2019/09/did-wg-charter

So, if we were to start testing DID Method implementations, a W3C Member could assert that we're violating our charter.

I guess I feel like we're taking the whole testability thing a tad too far, and these kinds of clear, logical directives that naturally follow from the other directives to DID Methods elsewhere in the spec are being watered down as a result.

It it's a clear logical directive that flows naturally, it doesn't need to be stated at all. :)

Another way to put this is -- the intent of the wording is clear without the normative requirement. What are we afraid of... that implementations will set deactivated to 'false' when documents have been deactivated? I'm pretty sure no one would use that DID Method or resolver if that were the case.

msporny commented 3 years ago

Waiting on feedback from @csuwildcat on response to his questions. Waiting on others from the WG to break the normative language tie.

csuwildcat commented 3 years ago

I'll do whatever folks want here, I just thought it was important to make this a directive to get compliance from Method authors.

peacekeeper commented 3 years ago

Can we make it normative in DID Core and then test it elsewhere, e.g. in the CCG where we ARE allowed to work on DID resolution and concrete DID methods?

msporny commented 3 years ago

Can we make it normative in DID Core and then test it elsewhere, e.g. in the CCG where we ARE allowed to work on DID resolution and concrete DID methods?

We are not supposed to delay testing or put the burden of testing on an external group. If we want a normative statement that can be tested by a machine (which is ideally all the normative statements in the specification), we are expected to write a test for it. The normative language in the specification is expected to be self-contained (or rely on other existing standards that have an official standing).

OR13 commented 3 years ago

Related https://github.com/decentralized-identity/sidetree-reference-impl/issues/14

Does this look right?

"didDocumentMetadata": {
    "deactivated": true,
    "canonicalId": "did:sidetree:EiDyOQbbZAa3aiRzeCkV7LOx3SERjjH93EXoIM3UoN4oWg",
    "method": {
      "published": true,
      "recoveryCommitment": "EiBfOZdMtU6OBw8Pk879QtZ-2J-9FbbjSZyoaA_bqD4zhA",
      "updateCommitment": "EiDOrcmPtfMHuwIWN6YoihdeIPxOKDHy3D6sdMXu_7CN0w"
    }
  }
peacekeeper commented 3 years ago

Does this look right?

Looks great to me!

[Off-topic] Also, perhaps we should standardize and register the "method" metadata property so that any method can use it for putting their own method-specific things in there.

csuwildcat commented 3 years ago

Sounds good to me

On Wed, Feb 3, 2021, 2:00 AM Markus Sabadello notifications@github.com wrote:

@peacekeeper commented on this pull request.

In index.html https://github.com/w3c/did-core/pull/581#discussion_r569280178:

@@ -3862,6 +3855,15 @@

updated

  • deactivated

  • is property MUST be populated with a boolean

I agree with this language. Unless @csuwildcat https://github.com/csuwildcat has any objections, we should accept this suggestion and then merge the PR.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/did-core/pull/581#discussion_r569280178, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABAFSVC4BZV72RAX6SKJODS5ENCNANCNFSM4WT2QBFA .

msporny commented 3 years ago

Normative, multiple reviews, changes requested and made, no objections, merging.