Verification process in the internet draft

[swcurran]

The following are comments/questions from reviewing the Verification Process in the Internet Draft.

1. The first step needs to be clarified as to whether it is refering to a DID (such as might be received in a VC) or a DIDDoc (such as would be returned in resolving a DID). The words say a DIDDoc, but the example is a DID.
2. A did:web may not be associated with a the domain of a DID. For example, it is quite easy to create a DID that is published in a repository on GitHub, where the publisher (the DID’s controller) does not control the domain. Further, in such DIDs, the domain is not the “last segment” of a DID as the text indicates. The domain is only the last segment in the special case of a did:web where the identifier is a domain. I think that will be in a minority of cases.
3. I think the more general case is to assume that in step 1, the DIDDoc is resolved, and that the domain linkage (if any) is in the DIDDoc itself. Then, in the special case of a did:web DID that references a domain name, the DIDDoc resolution MAY be skipped.
4. I think that step 3 needs a lot more detail — defining how the comparison between a verification method (which one(s)?) and the TLSA record(s) is carried out. For example, is it the full verificationMethod data that is checked, or just the key type and public key that is matched?
5. Given that in step 3, the verificationMethod and the TLSA records are found to match, how does is the level of assurance changed when using the TLSA method in verifying the DIDDoc proof item? I’m wondering if I’m not understanding something in the text.

A general question about this is how the DID controller keeps the TLSA record and the DIDDoc in sync. Presumably, there is a period when the two are out of sync as they cannot both be updated in a transaction. Is there a way to detect and compensate for that? In the Web-based DID Method we are considering, DIDDoc version is crucial to enable detect what version of a DID was used in signing something (such as a VC). Versioning could help in dealing with expected “out of sync” scenarios between the DIDDoc and the TLSA record.

[trbouma]

I am wondering, does a did doc, once a data integrity proof is added, become a verifiable credential, and therefore subject to the W3C Verifiable Credential Recommendation.?

Could a did doc be in the format of a SD JWT, or any JSON with a signature? I am inclined to make this as open as possible?

In your second question, where a did:web might not control the domain (such as GitHub) but they would need to the controller of a subdomain zone at least e.g., did:web:user.github.io

For Q4 - I don't think we have this all worked out yet. Lots of questions and insights are coming from building the prototype. More to come.

For Q5. We are purpose leaving how levels of assurance are defined to the trust framework providers. We are providing a table on how the series of verification checks, once passed, might map to levels of assurance, but it is the trust framework providers who must formalize that determination and mapping to their assurance models.

[swcurran]

On your question of whether a DID Doc with a DI proof is a VC, I would say no. I think there is a reason for the DI spec being separate from the VC-DI spec (using a DI in the case of a VC) — a VC-DI is a special case of a DI.

It does make sense that in the linkage of a did:web and DNS, that the controller must control both the DID keys and the DNS entry. That reduces my point to the obvious one that did:web’s suitable for this practice are a subset of all possible did:webs. Domain/subdomain DIDs are all did:web, but not the reverse.

[swcurran]

Happy to close this if you think there has been sufficient use from it.

[trbouma]

@swcurran - I agree - the DID Doc-DI spec should be separate from the VC-DI spec. I'd go one step further and allow the DID Doc-ID spec use other formats that are not W3C Recommendations, such as a signed JWT. Personally, I find the W3C DID Doc spec a little too complex for my liking. For sure, it does a lot of things and has flexibility, but it takes awhile to get your head wrapped around it. Anyway, my opinion only, as I see other ecosystems that would like to take advantage of this approach without necessarily adopting all of the W3C structural sugar.

In the end, irrespective of standards and exactly how it is implemented, it boils down to the controller of the did:web having control of the: 1) web server (including signing keys), 2) dns records, and 3) keys to sign the dns records (dnssec).

When all three of these controls are properly delegated and implemented, it is pretty secure,