Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

VC Schemas and VC Rest API #22

Merged
merged 8 commits into from
Jan 15, 2024
Merged

VC Schemas and VC Rest API #22

merged 8 commits into from
Jan 15, 2024

Conversation

AshleySetter
Copy link
Contributor

@AshleySetter AshleySetter commented Jan 11, 2024

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.

Copy link
Contributor

@anthonymccaigue anthonymccaigue left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

packages/nist_vc_rest_server/package.json Outdated Show resolved Hide resolved
Co-authored-by: Anthony McCaigue <anthony@nquiringminds.com>
@AshleySetter AshleySetter merged commit a4fdbbc into main Jan 15, 2024
4 checks passed
@AshleySetter AshleySetter deleted the vc_rest_api branch January 15, 2024 09:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants