Open reinkrul opened 1 year ago
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:
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").
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).
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.
Yes, as long as the source data is available (which is currently the network DAG, which isnt sufficient for VCs excahnged over OIDC4VCI).
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)
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?
Decision: add backup shelf like the issuer one. Remove when migrated to SQL.
Currently, VCR has multiple stores:
ResolveCredential(ID)
,SearchVCs()
andListUntrusted()
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
andpublish
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)
SearchVCs()
ListUntrusted()
: