Issues with Threading in Problem Reports

[mepeltier]

The Problem: DIDComm V2 problem-reports REQUIRE a pthid value, even though that may not always be possible to include.

problem-report spec for reference

Section of note:

pthid - REQUIRED. The value is the thid of the thread in which the problem occurred. (Thus, the problem report begins a new child thread, of which the triggering context is the parent. The parent context can react immediately to the problem, or can suspend progress while troubleshooting occurs.)

Consider the following scenario:

In this scenario, since Bob cannot unpack Alice's message, he has no idea what that message's thid is. Therefore, any problem-report he constructs is out of spec.

This is just one scenario in which this issue occurs. The spec itself identifies the possibility of problem-reports being triggered by events other than receipt of problematic messages:

ack - OPTIONAL. It SHOULD be included if the problem in question was triggered directly by a preceding message. (Contrast problems arising from a timeout or a user deciding to cancel a transaction, which can arise independent of a preceding message. In such cases, ack MAY still be used, but there is no strong recommendation.)

In this case, it's not that the appropriate thid is inaccessible to Bob; it simply does not exist. As such, any problem report generated in this manner is automatically out of spec.

[FabioPinheiro]

Yes, I agree that the Problem Report does not cover that cases.
But if you are not able to unpark messages or verify signatures, you also don't what to reply to anyone in specific.
Maybe the best would be to reply synchronously (if possible), with the problem report that is only signed, without any DID on the to field. But then you are exposing yourself to denial service attacks.

But that is a good question and we should have a guideline this what to do.
ATM I'm replying to HTTPS/Post with the code 400.