Credential Request for a deleted message does not result in a Problem Report

[swcurran]

Specific issue reported:

1. Start the Get Person Credential Process in the BC Wallet
2. Continue in the Wallet and BCSC app up to receiving the offer
3. Delete the credential exchange record using Postman
4. Accept the offer -- received the “This is taking longer than usual”.

Presumably, the "Request Credential" message from the wallet did not trigger a Problem Report message to the wallet. This is (likely) using the Issue Credential v1.0 protocol.

The most general issue is if/should ACA-Py should (automatically?) send a Problem Report to a connection that sends a message for a non-existent protocol instance? When the thread-id for a message is not found, what should be done?

Options include:

• send a problem report automatically, for all protocols.
• send a problem report or not based on a configuration setting.
• send a web hook to the controller and expose an endpoint such that the controller can send a problem report.
  • Does such an endpoint exist?

Interesting to know if the handling (whichever is chosen) requires an update per protocol, or can this be handled at a higher level? My guess is that this would be a per protocol (and perhaps per message) change -- perhaps throwing an exception (e.g., "No protocol instance found") when the thread-id is not found, that can be in turn be caught, and a Problem Report sent or not.

Need to look at the Aries RFCs (notably, 0003 Protocols, 0005 DIDComm and 0008 Threads) to check for guidance there.

[esune]

What about updating the issue-credential protocol (0453-issue-credential-v2, probably not worth it for v1) include new states to handle the interruption of the issuance flow when the issuer (aborted) or the holder (rejected) stop it before it can complete successfully?

[usingtechnology]

Just leaving a little update here on progress of the investigation.
I am using issue credential 2.0, I can go to 1.0 if needed... (and should to confirm behaviour). I am just running a multi-tenanted instance locally to do the investigation; allows me to breakpoint and debug.

Basic Steps:

• create issuer and holder tenants
• connect tenants
• issuer get a public did
• issuer create schema/cred def
• issuer make offer
• holder can find the offer
• issuer deletes their cred exchange record
• holder wants to accept the offer ()

In the issuer side of the code, we hit a logic loophole where we create a cred_ex record when one is not found. The comment is holder sent this request free of any offer. See manager receive_request

However, that case still won't work as the next step is to throw an error when the cred ex record is not in offer_sent. See indy handler receive_request

So I am not sure that the exception thrown is the correct one but in any case it does not get translated into a problem report (which from looking over the protocols seems to be the best practice).

Need to do a bit more digging to see if this part of the code is indeed used when holder sends request (but that never applies to indy - only json-ld) without offer and see how best to break that up.

[swcurran]

Interesting.

If the request is for an AnonCreds (aka Indy in the code) credential, when it is found that there is no offer, a problem request should be sent and the cred_ex record put into (AFAIK) abandoned state (check the RFC to be certain). That should be a terminal state, allowing the cred_ex record to be deleted by a clean up routine (or, just deleted — I’m not sure how that works).

In theory, the discovery of the “it’s an AnonCreds request and there is no offer” could be done before the cred_ex record is created — but I don’t know if that is feasible.

In theory, AFAIK if it is a non-AnonCreds credential issuance, the process CAN start at the request, so it is not automatic that the cred-ex record either not be created or set to the abandoned state.

[usingtechnology]

Yeah, I'll have to test whatever logic I come up with using indy and json-ld; with indy failing and json-ld carrying on with the assumption that this is a request from the holder.

I think I can check the format of the incoming request message to determine indy/json-ld and change the logic when cred_ex not found.

Anyway, more to come! Just wanted to post some progress.