Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I have added a schemas package, which can be used with @anthonymccaigue 's VC toolchain to populate a volt running on the registrar with the schemas for the VC (Verifiable Credential) claims we want to use to communicate information to the registrar.
Namely:
I have also added a Rest API which can be used to sign and verify these VCs. The intention being that the registrar can run an instance of the Rest API and use the it to verify VCs it receives (through any means). An agent that wishes to communicate information to the registrar can run an instance of the Rest API themselves (connected to the regisrar's Volt) and use it to sign the claim VC they wish to send to the registrar.
Presently the Rest API must use the same user, but once Toby has finished the necessary updates to the Volt it should be possible for another user with access to the reigsrar's volt (with the schemas shared with them by the registrar) to run the Rest API using their own users credentials, allowing control by the registrar of which agents it trusts to sign VCs.
What I am working on now
I am now working on a Rest API to run on the registrar which can receive these VCs via a Post request and verify them using the API in this PR. If they verify it will then insert the contained data into the a local SQlite database on the Registrar. We can then use a rust (or other) script to perform the SQlite query to perform the two policy check's Nick wants in place for the demo.
Once both of these are working we will also add a check if the device is vulnerable - i.e. if the deviceType the device is bound to is vulnerable - which means a script needs to run the SBOM check on that deviceType and send a VC to the registrar claiming that the deviceType is vulnerable or not vulnerable.