Add integrity to did document profile pointer.

[andorsk]

Discussed on ToIP call: possibly profile document is different than intended over serving URL. Should have an integrity check on the profile exposed in DID Document.

[a-fox]

In DID Core spec it is strongly advised that external links are integrity protected: https://www.w3.org/TR/did-core/#content-integrity-protection Even though service profile does not have direct effect on the integrity of the DID Document itself, IMO it is important that there is an optional mechanism to add integrity protection on the DID Document end as well.

[a-fox]

Here are some thoughts on how this could be solved:

What about checksum in services? Add checksum field (like the one removed in PR #10 ). This is likely the easiest and straightforward, but in itself is not enough, as we would also need to include information about the hashing algorithm, supported algorithms, etc. Not a bad approach, but IMO it's a quick fix and not sustainable, as it would be better to have a generic method on referencing insecure URL's from DID doc (probably one of the reasons why it was removed earlier).

This leads to the Linked Resource approach: Cheqd approached this with heavier requirements, creating a a full linked resource -approach, and also using ToIP TR as a possible use case. Apparently their Work Item proposal was accepted into W3C CCG to be developed into a spec, but so far the repo is empty. See their nice proposal, including more information here.

My problem with Linked resources is the extensive support it would require from the implementing DID methods. IMO a light version would be welcome that would solve only the content integrity check portion.

Hashlinks The DID Core spec references IETF Hashlinks internet draft. . It would be a simple solution to the problem, but as to my knowledge, it's not adopted or supported by community at large, or at least I couldn't easily find libraries or clients that support it. Hashlinks would be a good and simple mechanism that solves exactly our problem with a lightweight solution. Adoption-wise, we don't necessarily want to bind requirements to an obscure, expired spec.

Thoughts?

[a-fox]

From 5.10.2023 EU/NA meeting: One approach to integrity protection is 1) hashing the main structure of the profiles document, 2) signing it with one of the private keys associated with public keys in DID Document, and 3) storing it to the profiles document (outside of the hashed structure),

This allows the profiles document creator to specify which algorithm to use for hashing & which keys to use for signing.

[jacqueslatour]

Planning to talk about this tomorrow NA meeting, integrity of the did document can be verified with a proof, see example https://[trustregistry.ca/.well-known/did.json/](https://trustregistry.ca/.well-known/did.json/) and also authenticity is important, how do you know it's not an hijacked web server, so adding a mechanism in the DNS for that domain to verify authenticity is important. Jesse and I will show an example tomorrow.

[andorsk]

16 resolves this. Closing this issue.