swcurran
commented
5 months ago We’re working in a similar area (web-based DID Method) and think that several items are needed that go beyond did:web. Wondered about your thoughts on these requirements:
- Signature across the DIDDoc in the DIDDoc from signature(s) of the DID Controller.
- This is not in the DIDDoc, but we think needs to be added — likely as a Data Integrity proof.
- A full history of DIDDoc updates chained together (hash of previous DIDDoc is included in the signature of the new, signature on the new DIDDoc is from the controller keys listed in the previous DIDDoc).
- The full history is needed so that VCs signed at any time can be verified in the face of DIDDoc updates/key rotations.
- A mechansim for traversing the history — ideally including a way to get the full history with a single request.
- The identifier for the DID is derived from the initial DID Document as the starting place of the history using some kind of hash (self-certifying identifier or SCID).
- Pre-rotation for use when private keys are exposed through accidental disclosure or quantum calculation.
- TTL does not solve these concerns — do you think it needs to?
- Ensures (or tries to…) that control of the DID can be retained.
- Use of alsoKnownAs to indicate intended places where equivalent versions of the DIDDoc are published.
- Support for multiple controller DIDs (keys) via the Verifiable Condition specification
- Defines the threshold/combination of keys needed to authorize an update to the DIDDoc.
I have reviewed this paper. It has a good outline of the issues and believe we can address (have addressed) the main issues. The paper is here:
https://github.com/WebOfTrustInfo/rwot12-cologne/blob/main/final-documents/beyond-did-web.pdf
Also, I don't believe we need key pre-rotation (a la KERI) because a similar revocation capability can be implemented using the "exp" field. This can be similar to a TTL that you can set (I have set for 3600s) - when you check the did doc, though the signature might check out you fail the verification due to the current_time > "exp". That means you need to request a new did doc which (hopefully) has rolled over to a new key.
In the end, we don't need to specify a new method beyond
did:web, but we do need to specify a series of checks that the did doc must pass before it relied on as a high assurance did. Since relying on a high assurance did doc is the discretion of the relying party, we need to make this as flexible and easy as possible, through "did doc extensions", etc.