[Edited] Clarify Data Integrity proof generation step for creation and update of a log entry

[PatStLouis]

The Data Integrity Specification defines a mechanism to add an embedded proof to a document to be signed. The usage in the tdw spec doesn't follow normative requirements from Data Integrity since it's appending the proof as an array element, Therefore is non compliant with the specification it recommends.

Having an object for each jsonlines would make each line a perfectly valid data integrity secured document. This idea was proposed for different reasons here: #63

ex:

{
  "versionId": "1-...",
  "versionTime": "2024-...",
  "parameters": {
    "method": "did:tdw"
  },
  "value": {
   "id": "did:tdw:..."
 },
  "proof": {
    "type": ["DataIntegrityProof"]
 }
}

Edit:
My previous comment wasn't fully aware of the goal of the Data Integrity Proof in this context. I no longer see the jsonline requiring to be an object in order to be conformant since the proof is linked to the did document and not the log entry.

Is there anyone else seeing a need to clarify this section:

"Generate the Data Integrity proof A Data Integrity proof on the initial DIDDoc MUST be generated using an authorized key from a DID in the required updateKeys item in the parameters, and the versionId as the proof challenge."

It might be fine as is and I'm happy to close this issue if no further action is required. Clarifications I could see are specifying a proof configuration including a proofPurpose.

[stevenvegt]

Since witnesses can generate multiple proofs, should we define the proof as a proofSet here?

[PatStLouis]

Proof set or proof chain, I think regardless it should be an array, even if only 1 proof is present...Due to the complexity of proof chains over proof set, maybe leave that up to the software to configure if they require one or the other?