Skip to main content
Version: 0.6

Problem Reports

info

The IOTA DIDComm Specification is in the RFC phase and may undergo changes. Suggestions are welcome at GitHub #464.

  • Status: IN-PROGRESS
  • Last Updated: 2021-10-29

Problem reports are a standard DIDComm feature for reporting errors or warnings between parties. Using this mechanism is not a general requirement but it is a best practice for relaying informative errors and may improve human experience.

Example​

A problem report is a standard DIDComm message:

{
  "type": "https://didcomm.org/report-problem/2.0/problem-report",
  "id": "7c9de639-c51c-4d60-ab95-103fa613c805",
  "pthid": "1e513ad4-48c9-444e-9e7e-5b8b45c5e325",
  "body": {
    "code": "e.p.xfer.cant-use-endpoint",
    "comment": "Unable to use the {1} endpoint for {2}.",
    "args": ["https://agents.r.us/inbox", "did:sov:C805sNYhMrjHiqZDTUASHg"],
    "escalate_to": "mailto:admin@foo.org"
  }
}

Note that problem reports may still use sender authenticated encryption or even be signed DIDComm messages.

IOTA Problem Codes​

We follow the notation for problem codes defined by the DIDComm specification. In general, we use the error sorter e and protocol scope p to indicate that problem reports result in the abandonment of a protocol.

In addition to the problem report descriptors in the DIDComm specification, we define the following non-exhaustive list of general problem report codes that may be sent during the course of any protocol:

CodeDescription
e.p.msg.invalid-messageThe message is malformed or fails field constraints validation.
e.p.msg.unsupported-messageThe message type is unrecognised or unsupported by the recipient.
e.p.msg.invalid-stateThe recipient is unable to handle the type of message in its current state. Typically when an unexpected message is received in the middle of a protocol on the same thread.
e.p.msg.trust.not-authenticatedThe sender is required to authenticate to perform the requested action.
e.p.msg.trust.not-authorisedThe sender is authenticated but lacks sufficient permissions to perform the requested action.
e.p.msg.trust.not-sender-authenticatedThe recipient requires the message to use sender authenticated encryption.
e.p.msg.trust.not-encryptedThe recipient requires the message to use anonymous encryption
e.p.msg.trust.not-signedThe recipient requires a signed DIDComm message.
e.p.msg.trust.cryptoAny general cryptography-related error. E.g. the signature in a message payload or on a signed DIDComm message fails validation, or sender authenticated encryption fails.
e.p.req.timeThe party has timed out waiting for a response.

These messages may be raised during or between protocols to inform the other party that something went wrong. A problem report with the error sorter e and protocol scope p terminates the protocol on the current thread and MAY be followed by a connection termination.

Unresolved Questions​

  • Should we support the message scope m to allow resending / retrying individual messages?

Further Reading​