Deactivated flag moved to DID Document Metadata

[csuwildcat]

---

Preview | Diff

[msporny]

Minor nit, don't think we need to make this statement testable.

[csuwildcat]

@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]

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]

@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]

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

[csuwildcat]

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]

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]

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]

Related decentralized-identity/sidetree-reference-impl#14

Does this look right?

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

[peacekeeper]

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]

Sounds good to me

…

On Wed, Feb 3, 2021, 2:00 AM Markus Sabadello ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In index.html <#581 (comment)>: > @@ -3862,6 +3855,15 @@ <h4>updated</h4> </p> </section> + <section> + <h4>deactivated</h4> + <p> +This property MUST be populated with a <a data-cite="INFRA#boolean">boolean</a> 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 <#581 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABAFSVC4BZV72RAX6SKJODS5ENCNANCNFSM4WT2QBFA> .

[peacekeeper]

+1 to merging after applying the suggestion 74f2d40#r564900912.

[msporny]

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