I believe we need to change the verification code for ACDCs in KERIpy ASAP because what we do now is not adequate. For example, it does not persist a credential if it is revoked upon presentation. I don't believe that is correct behavior, not to mention avoiding persistence if a chain is broken due to revocation. I think that is too heavy handed.
Instead I'd like to propose an update to the verification service that only checks the cryptographic validity of the credential itself, whether an issuance event has "ever" existed and whether the chains actually exist and then persists it and the relevant TEL events at time of admitting, then recurses through the chains. In the event that something like a TEL event or a credential chain node is missing, we escrow and wait for it to show up as we do today, but if all relevant data is available, we persist even if revoked or chains are revoked.
We should then add functionality that specifically reports on credentials status and chain status for already persisted credentials. In this way, we elevate the decision about revocation up to a "business decision" and not integral to the parser.
SmithSamuelM
commented
1 year ago
I believe we need to change the verification code for ACDCs in KERIpy ASAP because what we do now is not adequate. For example, it does not persist a credential if it is revoked upon presentation. I don't believe that is correct behavior, not to mention avoiding persistence if a chain is broken due to revocation. I think that is too heavy handed.
Instead I'd like to propose an update to the verification service that only checks the cryptographic validity of the credential itself, whether an issuance event has "ever" existed and whether the chains actually exist and then persists it and the relevant TEL events at time of admitting, then recurses through the chains. In the event that something like a TEL event or a credential chain node is missing, we escrow and wait for it to show up as we do today, but if all relevant data is available, we persist even if revoked or chains are revoked.
We should then add functionality that specifically reports on credentials status and chain status for already persisted credentials. In this way, we elevate the decision about revocation up to a "business decision" and not integral to the parser.