mark did:webvh as dif recommended #67
Conversation
Signed-off-by: Jonathan Rayback <[email protected]>
|
Following the process outlined here, this PR triggers the 60-day formal review period for did:webvh. The review period closes on 28 September 2025. Please use PR comments to provide your feedback. |
|
Question about pre-rotation keys (I'm looking at https://identity.foundation/didwebvh/v1.0/#pre-rotation-key-hash-generation-and-verification) -- it seems like there should be a requirement that a used pre-rotation key be discarded after its pub key is revealed for use in a proof for DID update, otherwise the point of pre-rotation is defeated. Was this requirement intended but omitted? Or is pre-rotation key re-use meant to be allowed, up to the DID controller(s) to decide upon? |
As pointed out by @vdods on the mailing list, 60 days from 30th July will actually be 28th September 2025, and not 1st September. |
|
Yes. The correct date is 28 September 2025. Thanks @swcurran , @vdods , and @ankurdotb . I'll update the initial comment so it's clear and announce at the 13 August working group meeting. |
|
I've got a rather subtle question about authorized DID updates as it relates to DID duplicity. Say there are several keys in the updateKeys field (which I understand defines which keys are authorized to sign DID updates), but only 1 signature is required. Then two distinct and non-malicious authorized parties each create the same valid update to the DID, which means that they each append an entry to the DID Log with appropriate signature and DID doc content (among other things). Obviously their signatures will differ. Call the two different DID Log files A and B. But now, even though the DID docs for A and B are the same, their DID Logs have diverged from the perspective of their differing entryHash values. Now the question is: Is this considered DID duplicity? The DID Logs are different, so without a more involved definition, it seems like it could fairly be deemed so. The parties that created the authorized updates may have arrived at this situation by honest mistake (e.g. miscommunication about who was supposed to 'push' the DID update). I think witnesses are designed to handle this situation, but a DID could be created that has no witnesses, or the witnesses could be colluding with the DID controller. More generally, what is the definition of DID duplicity for did:webvh? If I understand (https://identity.foundation/didwebvh/v1.0/#did-watchers), watchers are intended to detect and respond to DID duplicity, though its governance is out of scope for the spec. DID resolvers arguably also have to deal with this situation, since they have the option of retrieving the DID's materials from alternative sources (https://identity.foundation/didwebvh/v1.0/#read-resolve). |
|
@vdods I wonder if maybe technical questions about did:webvh should be discussed in the did:webvh repository, and we should use this PR here for discussing aspects of the DIF recommended process? |
@peacekeeper , however, if @vdods questions are relevant to granting DIF Recommended status to |
|
@swcurran , sections 7.3 and 7.4 of the DID core spec, contain exhaustive lists of MUSTs to be covered in the 'Security Requirements' and 'Privacy Requirements' sections of a DID Method Specification. These sections are combined as 'Security and Privacy Requirements' in the |
|
@jrayback, @peacekeeper -- happy to have the (excellent) point raised by @vdods in the did:webvh spec repo and just linked back to here with a resolution. That might keep this convo more readable. @jrayback -- working on a PR to update the Security and Privacy sections as you suggest. This will not change the version and it is a clarification of the current content. But you are right -- organizing it to match the DID Core spec makes good sense. |
Sorry -- I missed this one. Definitely not intentionally omitted -- frankly, it never occurred to me that anyone would do such a thing. Easily added (I'll put in an issue). Presumably, they should not ever reuse an |
|
I suggest that this PR be put into Draft state to prevent accidental merging before the review period is up. |
|
In answer to @vdods two questions above 1 and 2. Both have been opened as issues to the did:webvh DID Method spec -- key reuse and DID Duplicity. Both have been fully answered there, and are pending closing based on some clarifications to the spec, and in the case of DID Duplicity, an addition to the FAQ Section of the did:webvh info site. The issue comments point to the specific commits that are in a larger Security and Privacy Considerations PR (discussed below). In response to @jrayback 's comment above about the alignment of the did:webvh spec with the DID Core sections 7.3 and 7.4 on Security and Privacy, we've created a PR to the spec. While there was no material change to the specification in the PR, the section is much improved on the previous that was mostly an update to the did:web content. The PR aligns with 7.3 and 7.4 as requested, adds additional specifics related to did:webvh capabilities (such as @vdods questions), and adds a sub-section |
|
The PRs directly addressing @jrayback 's comment, including clarifications inspired by @vdods comments, and the No Phone Home meme have been merged. The new content can be seen:
|
|
I've been thinking that at the end of the process, there should be some kind of "report" about the steps that have been taken and fulfilled criteria. I think I already mentioned this idea. This would not be a certification or something like that, and it wouldn't be a responsibility of the DID method proposer to do this, it's just some documentation written by someone who is not (closely) associated with the DID method. This is what it could look like: https://docs.google.com/document/d/1w59zWzzuUivL1VWLEj15t1rvJ3xAtyeVLfcYgsi2_XU/ Let's discuss in the next DID Method WG call. |
Mark DID:Webvh as DIF Recommended.