Plug-In to store basic credential exchange information for issued/held/verified exchanges

[loneil]

ACA-Py has a global setting that allows the agent to retain credential exchange records after they complete (i.e.: they reach a state in the state-machine that does not allow further transitions) and it is controlled by the preserve-exchange-records argument. Currently, the Traction agent has preserve-exchange-records: true in order for the Tenant Ui to be able to display information about:

• held credentials (which issuer/schema they come from, when they were issued, etc.)
• proof requests
• issued credentials (schema, data, etc.)

It would however be good practice to turn the global exchange retention flag off for two main reasons:

• security: retaining records means that there is the potential for private data to be stored indefinitely in the agent
• operations: exchange records cause significant bloating of the agent's wallet

While controllers are supposed to retain any information about the various exchanges that they might need, for the Tenant UI to be able to provide meaningful information some of this data needs to be retained.

Acceptance Criteria:

• Determine minimum set of information to retain, and its origin (credential exchange or not) for each type of interaction (issuing/verifying/holding). Be mindful and try to avoid private data retention (i.e.: credential issued/verified payload) unless necessary - a configuration/toggle could be good for this.
• Create a plug-in that will store the information identified at the previous point for the Tenant UI to consume.
• Update Tenant UI to use new set of endpoints.
• Nice to have: the plugin will sync-up existing exchange data on first run.

c.c.: @loneil and @usingtechnology for extra background/thoughts

[usingtechnology]

i was thinking that it would be easier to not have new endpoints and just a have the plugin strip the existing records to whatever minimal data you need when the exchange is terminated. i think that would make it simpler for building out your list/table where you have exchanges in mid-flight and terminated exchanges (abandoned, complete). first step is what tenant-ui needs and maybe a future step would allow some configuration of what to retain, and open up the plugin for other use-cases.

as always, I am probably missing something that would cause a glitch but that's what I was thinking. no new apis, no new recordsets, just strip down the existing data.

[swcurran]

Are we staring the data in the ACA-Py database with this plugin? If so, that has impacts and is not the expected behaviour. The intention is that the controller/LOB app will store any data needed for any protocol instance that is needed after the completion of the protocol. Such data should not be kept in the ACA-Py data store. Or if that is to be done, we will need to re-write the DITP STRA and PII documents — which I think is a bad idea.

Our approach should be that if the controller wants the data, it needs to store it — for all protocols.

[esune]

@swcurran the catch is that Traction (and the associated Tenant UI) are basically a LOB application inside ACA-Py. This conversation is mostly around that scenario, and potentially around some extra bits regarding which creddef/schema each credential is associated with (sort of metadata) that I believe is not easily accessible otherwise, other than through the credential exchange (if it is retained).

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[github-actions[bot]]

This issue was closed because it has been stalled for 5 days with no activity.