Issued VCs never get cleaned up

[reinkrul]

When a VC gets issued, it is always stored in the VCR issuer store. This is to keep track of what is issued and to be able to revoke credentials. This was probably designed with low credential count in mind, so no pruning was needed at time when this got designed. Maybe even with the NutsAuthorizationCredentials the number were low enough not to consider pruning.

However, every data access request (or once per user session), an EmployeeID credential is issued and stored. To avoid an ever-growing store (with data that became irrelevant), we might need to consider pruning issued credentials.

[reinkrul]

Considerations:

• Is it harmful to automatically remove Verifiable Credentials that expired X time ago? If parties use the Nuts node for record-keeping, they might lose info (although that could be in the audit log).

Options:

• Provide DELETE operation for credentials, aside from revocation. But automatically-issued credentials are probably never cleaned up by the XIS app (complicated lifecycle).
• Automatically remove expired credentials that are older than, e.g. 1 month.
  • Are there cases in which this could be harmful?

[woutslakhorst]

Or combine automation with a hack to only remove these types of credentials.

The same also goes for AuthCreds that have been revoked, although record keeping might be more important there?

[reinkrul]

Maybe let it be configurable, based on type? I don't foresee you want to select credentials to prune on other criteria..

Say;

vcr:
  issuer:
    prune_expired:
      match_type: EmployeeIDCredential
      after: 1d

Important remark is that never-expiring credentials are never pruned, so another reason to let credentials expire at some point.

[reinkrul]

We made it ourselves harder by introducing a second store for non did:nuts-related VCs. We have several options:

• Do nothing: nobody complained, so the issue we see might not actually be a problem in practice
• Fix in BBolt/go-leia, but not in SQL store: for did:web-related VCs, stored in SQL, we might not support/advice using short-lived EmployeeID-like credentials (or NutsAuthorizationCredential), but we don't know yet.
• Fix in both SQL store and BBolt/go-leia: duplicate code/functionality in 2 stores, but we're at least "safe".
• Migrate BBolt/go-leia store to SQL and fix it once. Changes the original plan for SQL storage.

[woutslakhorst]

1 or 2 maybe

[reinkrul]

This is not an issue for the ServiceToService Access Token flow with employee credentials; the EmployeeCredential isn't actually issued and signed, and only protected by the VP proof (issuer-is-holder credential).