Add methodology for signing using JWS

[doowt]

Pull Request

Checklist

• Have you read Digital Catapult's Code of Conduct?
• I have performed a self-review of my own code.
• I have commented my code, particularly in hard-to-understand areas.
• I have made corresponding changes to the documentation.
• My changes generate no new warnings.
• I have added tests that prove my fix is effective or that my feature works.
• New and existing unit tests pass locally with my changes.

PR Type

Please delete options that are irrelevant.

• Bug Fix
• Chore
• Feature
• Documentation Update
• Code style update (formatting, local variables)
• Breaking Change (fix or feature that would cause existing functionality to change)

Linked tickets

High level description

This PR expands on the description of using did:key to sign Veritable responses.

Detailed description

The idea of signing responses was previously discussed for Veritable. Allowing nodes to sign responses allows them to lay claim to responses later (by signing new challenges using the same key) without compromising their privacy, provided their parent nodes do not strip off or replace signatures when passing responses upwards to the querier.

Note that these signatures do not provide non-repudiation since the signing keys are not authenticated.

The proposed data structures provide a route to enable JSON Web Encryption, which may be useful for future Veritable iterations to allow responses to be encrypted under a key provided by the 'top-level' querier.

Describe alternatives you've considered

Signing without using JWS means defining serialisation methods and appropriate data structures. This is likely to require more work to implement (with the potential for making mistakes), whereas using JWS is likely to allow third-party libraries to be used.

Operational impact

N/a. The current description is only a suggestion of how to implement signatures.

Additional context

This PR is submitted as a draft as there may be better choices for creating the signatures:

• Using JWS means that payloads are base64-encoded and are therefore no longer human-readable, which may not be desirable.
• The params field is now either a JWS or a 'plain' response object. There may be better ways of defining these objects to distinguish between these cases.

[mattdean-digicatapult]

This makes complete sense to me. The loss in human readability is suitably offset by the improved standardisation imho. If we implement encryption on the responses this may make validation harder, but I see no reason why that would be an issue. One thing to consider is if we should somehow include a digest of the request in the response (so that a response can't be transfered over to an unrelated request)?