prototype

[gsvarovsky]

Prototype integration of the controls into m-ld, and verification of the threat mitigation with tests. Engineering will proceed with tests and implementation combined. The intention of the prototyping is to validate the design, in terms of implementation complexity and against tests, not to deliver a production-ready implementation.

• prototype implementation in GitHub
• automated tests & published results from continuous integration

integrity

• Whole domain authorisation to fixed user. It will be possible for an app to register the current user identity with the clone, and have the clone allow or prevent write access to the whole domain based on some hard-coded information. This is not a useful function by itself, but establishes the necessary framework for the following goals, and can be verified.

  Whole domain authorisation m-ld-js#85

• Data-driven authorisation. It will be possible to have the clone allow or prevent write access to sub-parts of the domain data, based on access control data in the domain. The available configuration complexity will be sufficient to show that it is possible to meet the requirements established in the threat models.

  Data-driven authorisation m-ld-js#94

• Externally-driven authorisation. It will be possible to have the clone allow or prevent write access to sub-parts of the domain, based on a configured protocol that is external to the domain data. One such protocol will be demonstrated.

  Added statute "prover" extension loading via "extension subjects" m-ld-js#98
  m-ld/m-ld-iroha: [Experimental] m-ld extensions using Iroha

traceability

• Journal API. In order to verify traceability, it must be possible to access the clone journal (for example, to cryptographically verify signatures; implementing such signatures is the next goal).

  Update after integrity milestones: As explained in the traceability design, no new API is required for the chosen technical approach for prototyping. However, it is necessary to include 'trigger operations' in the existing update API, so that an auditing clone can record the inputs into machine-generated updates.

  #3: Journal API prototype #13

• Signed journal entries. This is the ability to cryptographically bind the user identity and timestamp to write operations in the domain, such that their actions can be traced (and not repudiated).

  Edge timeld#50

[gsvarovsky]

Re: identity models

Atomic Data has the same problem of how to securely manage private keys for signing (in their case, of Commits)