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:
User trusts (or doesn't) manufacturer
User trusts (or doesn't) device
device manufactured by manufacturer
device is of type deviceType
deviceType is (or isn't) vulnerable
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.
1) Check that Manufacturer is trusted by the network owner (or a user trusted by the network owner) before we proceed to contact the MASA for the voucher request for a new pledge.
2) Check that the device is trusted by the network owner (or a user trusted by the network owner) when the LDeVID EAP is issued before we pass it to the device to allow it to connect.
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.
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.
1) Check that Manufacturer is trusted by the network owner (or a user trusted by the network owner) before we proceed to contact the MASA for the voucher request for a new pledge. 2) Check that the device is trusted by the network owner (or a user trusted by the network owner) when the LDeVID EAP is issued before we pass it to the device to allow it to connect.
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.