Update Verification Method Revocation section. #742
Conversation
index.html
Outdated
| own discretion. | ||
| </p> | ||
| <li> | ||
| <a>Verification method</a> revocation applies only to the latest version of a |
There was a problem hiding this comment.
I believe I understand the intent of this sentence, and agree 100% with it. However, I think this sentence is very hard to parse, because of ambiguity in the phrase "applies only to the latest version." I suggest this be reworded to something along the lines of "Verification method revocation can only be embodied in changes to the latest version of a DID document; it cannot retroactively adjust previous versions."
| Not all DID Methods support verification method revocation. | ||
| </p> | ||
| <li> | ||
| Revocation is expected to be understood as a <a>controller</a> expressing that |
There was a problem hiding this comment.
I disagree with this summary of the semantics of revocation. Previous text in this same section says that revocation can take place immediately after a key rotation to prevent the rotated key from a future compromise. This is at odds with the sentence here, which claims that revocation is understood as communicating doubt about the current security of the method.
Revocation does not always imply a belief that existing proofs or signatures might have been created by an attacker. Rather, it always implies an intention that future proofs or signatures shall not be creatable by an attacker, and it may or may not also imply a concern that existing proofs or signatures are suspect.
| was revoked. | ||
| </p> | ||
| <li> | ||
| Not all <a>DID methods</a> support <a>verification method</a> revocation. |
There was a problem hiding this comment.
This is at odds with the sentence that says that all DID methods support removing a method from a DID document as a form of revocation.
There was a problem hiding this comment.
I suggested a few words to remedy this above.
index.html
Outdated
| Some <a>DID methods</a> only allow the retrieval of the current state of a | ||
| <a>DID</a>. When this is true, or when the state of a <a>DID</a> at the time of | ||
| cryptographically verifiable statement cannot be reliably determined, then the | ||
| only safe interpretation of revocation is to make it apply both forward and |
There was a problem hiding this comment.
I disagree with the phrase "only safe interpretation" -- because it implies that retroactive cancellation is safe. It isn't. Just like unwise use of revocation when the two constraining safety conditions (knowing when the cryptographic statement was made, and knowing what the state of the DID doc at that instant were) rewrites history, interpreting revocation to apply backward in time ALSO REWRITES HISTORY; the difference is that it rewrites that history to maximize protections for the controller instead of rewriting it to maximize protections for the recipients of cryptographically signed assertions. Either way, there's still a winner and a loser -- a protected party and a party treated cavalierly.
I do agree (strongly) with the third sentence, "DID ecosystems that take this approach..." What I would suggest as a revision would be to say, "When this is true, or when the state of a DID at the time of a cryptographically verifiable statement cannot be reliably determined, then the only safe course is to disallow any consideration DID state with respect to time, except the present moment. DID ecosystems that take this approach..."
What I am trying to do with this revision is to remove the phrase "apply both forward and backward in time" in its link to safety -- because I think describing it that way is problematic.
|
|
||
| <ul> | ||
| <li> | ||
| The proof or signature includes the `versionId` or `versionTime` of the <a>DID |
There was a problem hiding this comment.
I agree with this content in its narrow sense, but I don't like how it gives the impression (by focusing only on trustless systems) that the only way to achieve trust is to provide all these properties as part of the cryptographic inputs. The date that a mortgage was signed may not be part of the cryptographic inputs to a verifiable statement, and yet it may be possible to achieve full trust, by deciding that metadata about the event from some other source (e.g., banking records, independent witnesses) is also reliable. In fact, this is likely to happen in a courtroom in many scenarios: metadata from many sources will be evaluated and accepted/rejected.
My suggestion is to add an extra paragraph right after the </ul> that says something like: "In systems that are willing to admit metadata other than those constituting cryptographic input, similar trust may be achieved -- but always on the same basis (making a careful judgment about whether a DID document's content at the moment of a signing event authorized the verification method)."
There was a problem hiding this comment.
I added a minor variation of your language to the specification here: https://github.com/w3c/did-core/pull/742/files#diff-0eb547304658805aad788d320f10bf1f292797b5e6d745a3bf617584da017051R4839
Co-authored-by: Kyle Den Hartog <kdenhartog@users.noreply.github.com> Co-authored-by: Dave Longley <dlongley@digitalbazaar.com> Co-authored-by: Amy Guy <amy@rhiaro.co.uk>
|
Editorial, multiple reviews, changes requested and made, no objections, merging. |
|
@dhh1128, I'm fairly certain that we addressed all of your concerns in this PR so I merged it. If we didn't, please don't hesitate to request more changes (via another PR). |
Partial editorial cleanup to appendices tracked as issue #728.
Preview | Diff