Credential CESR stream will grow indefinitely

[lenkan]

With the current solution, the ECR holder will fetch the credential CESR stream and directly or indirectly submit this to the verifier. This stream contains the KEL of the issuance chain up to the GLEIF delegator. This means that it will contain the KEL of the QVI as well, since the QVI will append an issuance anchor event for each issuance, the payload will increase which each issuance. This seems infeasible in the long run and we need a solution for it. For example, with only 15 issuance events, the credential stream reaches >100kb. For 3 events, it is around 70kb. I have not calculated the estimated size when we reach ~100 or ~1000 issuances, but it will just keep growing unless we come up with another solution.

[dhh1128]

Daniel, do you think we should log an issue in keripy about this? I understand that it is particularly relevant in QVI contexts, but wouldn't this be an issue with any ACDC-chaining-based mechanism?

[lenkan]

Yes, it is possibly a more generic issue. There might be tools in the keripy toolbox to solve this use case in a different way and circumvent the problem. For example, if the verifiers use another mechanism to keep track of the issuers KELs, the credential holders would not need to submit this information.

[m00sey]

A couple of things spring to mind reading this.

1. Delegation would help reduce KEL bloat, a pattern for a delegated AID per candidate LE for a QVI perhaps?
2. Watcher functionality to collect relevant KEL information so it's not the responsibility of the ECR holder to send the KEL, this was a stopgap in the original PoC. It should not be the responsibility of the holder.

Definitely worth discussing further.