added integrity field in did document specification

[andorsk]

Adding integrity field to the DID Document reference. Ensures profile integrity in presentation.

[a-fox]

Instead of adding the checksum in DID Doc, I propose integrity & authenticity checks be done from within the profile document itself (see comment). This has some benefits:

1. As additional integrity & authenticity protection of the profile is optional, depending on which infrastructure is used, it should not be the responsibility of the pointer (DID doc) to include the protection mechanism.
2. Using DID Document keys, we are able to include authenticity checks that the profile document is created by the same party that holds the EGF keys. (Note this doesn't mean that the profile document is not the same as some other generic profile, it just means that we ensure that the profile is signed off by the EGF owner).
3. If the profile doc changes, we don't need to update the DID Document because of it.

This also means that for this stage, when we do not have a profiles document content fixed, we don't need to solve it. We can just create a first proposal.

Example spec text:

The profile document MUST include integrity verification. This may be done for example by including an integrity check link through the infrastructure's own protocol features (e.g. Git object hash or IPFS CID), or by hashing the profile document using a well-known and secure one-way hashing algorithm (e.g. SHA-256).

The profile document SHOULD include authenticity verification capability. This MUST be done using a well-known and secure public key algorithm. For added authenticity linking, it is strongly recommended to utilize the public keys available in the referencing DID document.

The document MUST be first hashed, then the generated hash is signed.

Super simple example of the profile document:

{
  profile: {
    // Profile structure
  },
  verification: {
    // backreference to the used signing key
    id: "did:example:123456789abcdefghi#keys-1", 
    // SHA-256 hashed & signed profile structure. 
    SHA-256: "20b873f0d59c84f7cc162856ac67f8433923444e9da847188c47cd5a734c9d3c", 
  }
},

[andorsk]

@a-fox I thought we discussed that the signing of the profile document is not the point here. We already have a proof section in the document. The DID Document SHOULD update it's document verification proof if the profile document updates, b/c the profile being referenced document has changed. https://github.com/trustoverip/tswg-trust-registry-service-profile/blob/main/spec.md#profile-document-sample. Profiles are static documents, not living documents, and thus, need a pointer update when the document has updated.

The url field can stay the same since it's pointing to the same url, but the document integrity check should change on each update.

[a-fox]

Yes, we did discuss it, but after reconsidering I think it's a useful thing, but not mandatory. That's why I added it as SHOULD instead of MUST. As the checksum / hash is also in the profiles document, it will be changed there of course. And signing prevents it to be tampered with by others.

However, at this stage (IIW coming), I'm content if we add authenticity verification as a security consideration.

Anyway, if we choose to go on with the checksum, then we cannot do with checksum alone, we need to reference the used algorithm. So we need to add the algorithm reference in the field and/or specify in the spec, which algorithm is used. IMO both should be done (maintaining an up to date list of algorithms is a pain though).

So, instead of
"checksum: "ec54f8019b869d5511b42678ea859b9dc185f487bf1776cb079fda0930331689",

it should be:
“SHA-256: "ec54f8019b869d5511b42678ea859b9dc185f487bf1776cb079fda0930331689",

[andorsk]

I suggest we make the field integrity and follow precedence with SRIs.

[andorsk]

@TelegramSam: Generally just trust the signer, but the the problem is you don't own the document necessary. Hashlink, but not as much in adoption. Some core people not interested.

Implicit choice: slow moving propagation and infrequent changes.

Antti: Trust the Trust Service Profile.
Relationship of Implementations.

@talltree Hashlinks makes sense. DIDURL standard.