Error handling and edge cases

[ashcherbakov]

It looks like the spec doesn't say how to handle errors and edger cases.
For examples:

• incompatible curves (keyAgreement types in DID DOC) between sender and receiver
• invalid data
• attacks (such as Need details about invalid curve and weak point attack resistance #217)
• the crypto algorithm that sender wants to use is not supported on the receiver side (in case when DID Comm spec is not fully supported on of the sides, or when new crypto is added to the spec).

It would be great if the spec can address some of this edge cases or provide a general strategy what to do in this cases: just terminate communication, send a specific error message, etc.

[dhh1128]

I am assigning this issue to myself and would like to produce a PR for the spec about it.

[kdenhartog]

Labeled/assigned to you so it's easier to track it

[kdenhartog]

@dhh1128 can you consider the usage of #83 when describing this. I think this issue should be more specific to returning specific errors in general scenarios around the payload layer and #83 is going to be about defining the generic structure and default errors I'd think.

[dhh1128]

@kdenhartog : I did read #83 and think about it. But I am not sure I understand the distinction between specific errors in general scenarios, and generic structure and default errors. Did you want me to define a few generic error codes (e.g., like the ones in errno.h from *nix)? Please feel free to push me to change the content; I just wasn't sure if I was covering your thinking enough.

[kdenhartog]

Based on what you're going towards in #232 I think we're on the right track. My thoughts on the topic aren't completely fully formed yet, but I'm aiming for the case where an error code response can be branched on to reduce the logic in the error code flows.

Specifically, I was thinking more along the lines of generic structure and default errors. Then these would be extended for more specific scenarios if needed, or if debugging is going on. I need to spend some time re-reading the problem report RFC before I think I can get a fully formed opinion on the topic.

[dhh1128]

You mean like an error code hierarchy -- so you can branch on errors at a high level even if you don't understand the low-level detail? Something like recoverable-error.resources.out-of-memory and recoverable-error.resources.out-of-disk and recoverable-error.resources.bandwidth, so you could handle recoverable-error or recoverable-error.resources without knowing the details about the right side of the codes?

[kdenhartog]

We discussed this on the 7-19 call and I thought this would be alright. It allowed for error branching based on classes of errors which is one of the things I was going for with default errors. I think we'll need to also define the basic errors that we want to support as well similar to how HTTP defined the original codes. Probably worth allowing this to be extensible to a certain degree with some limitations so the defaults actually remain generic enough.