Implement storage key secondary index for consent
Description
Environment
Activity
Should have been closed as resolved for 3.0.0 release.
In terms of using the frequency of access to an SP as criteria for pruning storage records from a cookie, I am thinking that a reasonably generic Counter action could be used to store the number of times a given flow has run. Such an action could be used for a variety of purposes. Over in IDP-511, I've left room for a function to return an iterator used to determine the storage keys to be deleted during pruning, and it would be straightforward to use the counter storage records to create that iterator. Perhaps the activation criteria for the Counter action would be that the storage service is client-side.
Don't know the structure well enough. If the record as a whole is what you're attaching the counter to, then yes, probably, but only if you actually updated the record. It wouldn't track "use" in the sense that it got reused but not updated.
Scott, do you think the StorageRecord version could be used as the frequency-of-use counter ?
I haven't looked at the structure, I wondered if a count could be stored in the per-RP portion and then the kick-out step would just iterate to find the lowest.
Store a list of storage keys per storage context as a secondary index.
This will be useful for management of consent as well as cookie size.