feat: endpoint to process credential from (acdc, iss) without IPEX

[iFergal]

Endpoint to accept ACDC and issuing event from TEL and process it. The issuing event is only used to craft the SealSourceTriple used when processing and saving the credential.

I'd like in the future if this could be a bytestream but right now the signed headers interface doesn't allow it. In fact, we don't need the entire iss event to create the SealSourceTriple but I think it's OK for now.

This processing is effectively what the parser already does when the discloser in IPEX streams the events to the disclosee but supports use cases that have ACDCs available at

The operation will only complete if the TEL events (and anchoring KEL events) are known to the agent. More work needed to trigger TEL queries via KERIA. WebOfTrust/keripy#868 leads to supporting that properly but I can also submit a smaller PR there to just use tels without tsn to get something fully working.

[codecov]

Codecov Report

Attention: Patch coverage is 97.50000% with 1 line in your changes missing coverage. Please review.

Project coverage is 93.73%. Comparing base (18d3ad7) to head (e839110).
Report is 21 commits behind head on main.

Files with missing lines	Patch %	Lines
tests/app/test_credentialing.py	94.73%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #297      +/-   ##
==========================================
+ Coverage   93.06%   93.73%   +0.67%     
==========================================
  Files          36       36              
  Lines        7121     7902     +781     
==========================================
+ Hits         6627     7407     +780     
- Misses        494      495       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[2byrds]

@iFergal is it intended for issuance, verification, and/or migration?

[iFergal]

@2byrds 3rd party verification of public ACDCs that are available in some out of band way/API. I have a use case for this and IPEX is too interactive.

[2byrds]

@2byrds 3rd party verification of public ACDCs that are available in some out of band way/API. I have a use case for this and IPEX is too interactive.

@iFergal okay great, what do you think about:

1. naming the endpoint CredentialVerificationCollectionEnd?
2. eventually refactoring it to share the same code as IPEX?

[iFergal]

@2byrds Good call on the naming, pushed!

I'm not sure on sharing the same code as IPEX. IPEX payloads are completely different and processed in a different way. After granting, artifacts are streamed async to the disclosee, so processCredential gets called from messages on the 3902 port.

This endpoint is more similar to the credential issuance endpoint but even there it's different and very little that could be re-used.

I had even thought about the idea of a generic parsing endpoint that accepts events and necessary attachments (in this case, a SealSourceTriple) but it might get a bit messy tracking operations. Maybe will work better if we move to ESSR routed endpoints instead of REST.

[iFergal]

Note this will go into escrow if the TELs aren't up to date. We can try to auto fetch missing TELs - the code is kind of trying to do that but there are existing issues there: WebOfTrust/keripy#865

I'd maybe like to move towards TEL observers that are similar to watchers in trying to stay up to date with revocations etc, so ideally TELs would always be up to date in the background anyway.

[2byrds]

LGTM