VCR: rethink store setup

[reinkrul]

Currently, VCR has multiple stores:

• VCR store
  • Populated with VCs received over the network
  • Used by ResolveCredential(ID), SearchVCs() and ListUntrusted()
  • Not part of backup, supposed to be restored from network using "reprocess"
• Issuer store
  • Populated with VCs issued by the local issuer/node
  • Used for revoking certificates
  • Part of backup
• Verifier store: unused (can be removed)
• Verifier revocation store:
  • Populated with revocations received over the network
  • Used for checking revocation status
  • Not part of backup, supposed to be restored from network using "reprocess"

With the introduction of OpenID4VCI not all credentials are issued over the network, meaning not all are added to the VCR store. Simply adding to the VCR store them when issuing/receiving is too simplistic: they'll be missing after a backup restore (since they're not rebuild from the network state).

The solution is redefining the VCR store: it is a place to publish credentials (ideally Verifiable Presentations), so they can be searched through. We also need to reconsider the public/private and publish concepts when issuing: it's not the issuer who should decide what is public/private and whether it should be published: a credential is private (only known to the issuer and holder) until the holder decides to publish it in a registry (as VP).

Analysis of relevant API operations:

• ResolveCredential(ID)
  • Used by the Auth module during token introspection to return VCs referenced by the access token
  • Used by Demo EHR when proxying FHIR calls to resolve VCs referenced by the access token (could just use the above)
  • Thus, it looks like it is only used to lookup credentials issued by the local issuer/node
  • Conclusion: could look in both VCR store and issuer store for backwards compatibility
• SearchVCs()
  • Used to search for published NutsOrganizationCredentials ("public registry" functionality):
  • Used by Auth to validate signed contracts (e.g. IRMA)
  • Used by Didman to search for organizations (e.g. to find receiver for eOverdracht)
  • Used by Demo EHR to find the organization details of a DID
  • Used by Demo EHR to find NutsAuthenticationCredential which can be used to access a specific FHIR resource at a remote EHR ("holder/wallet" functionality) - Conclusion: searching the wallet for an applicable credential is problematic; after restore it will be gone when the credential was issued over OpenID4VCI
• ListUntrusted():
  • Only applicable to published VCs, so no impact regarding OpenID4VCI.

[reinkrul]

A solution would be to introduce a holder storage which contains the credentials issued to the holder, which is in fact the wallet, which can then be backed up:

• Introduce "wallet" which stores received credentials (stoabs store, so they're backed up)
• Make wallet searchable by providing adding a leia store. Can be (automatically) rebuild after backup restore
• Remove private credentials from the VCR store: "private" means they were only meant to be in the holder's wallet, not to be published

Then, we could introduce a "registry" concept, which contains only public credentials (wrapping the current VCR Store). Then we have an abstraction which' implementation can be replaced by e.g. Verifiable Presentations or a different registry protocol ("network protocol v3"/"multichain").

[reinkrul]

For phase 1: make sure issued and received VCs end up in the VCR store (then functionality will stay the same), fix backup/restore issue in a future change (feature is disabled by default and experimental).

[woutslakhorst]

For phase 1: make sure issued and received VCs end up in the VCR store (then functionality will stay the same), fix backup/restore issue in a future change (feature is disabled by default and experimental).

backup/restore will work. Part of a restore is reprocess which will recreate the leia index. Then all data and the index is available in the VCR.

[reinkrul]

Yes, as long as the source data is available (which is currently the network DAG, which isnt sufficient for VCs excahnged over OIDC4VCI).

[woutslakhorst]

Yes, as long as the source data is available (which is currently the network DAG, which isnt sufficient for VCs excahnged over OIDC4VCI).

Then there's indeed a gap. The issuer store has its own backup shelf, could be example on how to solve. (although not perfect)

[woutslakhorst]

The issuer store has a mechanism to rebuild the search index based on a shelf. The shelf is part of the backup. We could do the same for the wallet?

[woutslakhorst]

Decision: add backup shelf like the issuer one. Remove when migrated to SQL.