So as of right now, Vaksina is using a very simplistic design which has a JSON file with all know keys from the VCI issuers list. This doesn't handle key revocation (which is a custom rolled thing in SHC and is semi-complex), but essentially, we need to do the following.

Each SHC has a specific signing key in the iss field, but that doesn't specifically denote who actually issued a given card, and that should be available in plain text if possible (this will also be true for other card types later) through the API. For fully offline operation, we need to be able to generate a datafile that has all the information in a single go, and then load it as needed.

In practice, the key management tool needs to do the following:

• Download all known VCI key signers from (https://github.com/the-commons-project/vci-directory)'s metadata
  • The keys are specifically at VCI base path + /.well-known/jwks.json, and are represented as a JSON Web Keyset format
  • However, the CRL system is unique
• Merge VCI metadata with the VCI signers in such a way that all key information is available in a single go
• If CRL support is defined (aka crlRevision: 1 is present in the JWK object), then we need to do additional steps
  • CRLs are defined on a per key basis, and refer to the rid object on a given card.
  • We need to download `/.well-known/crls/kid.json to get a list of revoked keys
  • This file needs a validation check before incorporated in the dataset.
• Have a local database of keys. As of last run, the key database is 210 kb JSON file. That may or may not be acceptable to load at library instance.

While we could dynamically fetch a pubkey for an unknown issuer, I question if that's really a door I want to open ...

The following tools need to be implemented:

• Define a serialization type for the key signer database
• Implement a tool to download the VCI list and serialize it
• Tools to create a local test signing CA for development purposes

We need to test the following scenarios to make sure we're handling this properly

• Download and validate a JWS claim for a given key (this is coded, but not unit tested)
• Ensure expiration and NBF (not valid before) is handled
• Check revocation status (example03 of SHC data is a revoked example)
• Model the issuer somewhere in Card information properly

There's probably more I'm forgetting, but this is a relatively good baseline in which to start