Updating Hub to follow the new request and response format. This format introduces commits as the primary data object, with extendible commit merge logic. A signed commit has been created to allow for client verifiable commits.
Replication can be built on commits, however optimizations and implicit DID document permission grant checks must be added. Replication is not included in this PR.
Additional tests have been with a total of 205 tests (95% branch coverage) all passing.
This PR does not include:
Actions interface
commit Read permission via DDO (for other hub replication)
commit field filters (requires a new return type)
extensive 'created_by' permissioning. A conflict between out of order commit submissions leads to unspecified behavior, as well as a potential for a denial of service attack.
commits in compact JWS format, or multi-signature format (why?)
There are still major security concerns. Do not rely on hub-node-core with real data.
Request signers are not verified against the iss (issuer) field. This requires additional parameters from did-auth-jose.
A request can be spoofed from any other DID
Commit signers are not verified against the iss (issuer) field.
A commit written by a third party can be submitted by a trusted party.
Updating Hub to follow the new request and response format. This format introduces commits as the primary data object, with extendible commit merge logic. A signed commit has been created to allow for client verifiable commits. Replication can be built on commits, however optimizations and implicit DID document permission grant checks must be added. Replication is not included in this PR. Additional tests have been with a total of 205 tests (95% branch coverage) all passing.
This PR does not include:
There are still major security concerns. Do not rely on hub-node-core with real data.
iss(issuer) field. This requires additional parameters fromdid-auth-jose.iss(issuer) field.