Skip to main content
Version: 0.6



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

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


Indicates the graceful termination of a connection. It is expected that no reconnection attempt will be made on any of the message thread/s in this connection following termination. This provides a chance for the receiver to clean up or archive any resources allocated to the connection.


Example Use-Cases

  • A verifier terminates the connection following a successful presentation from a holder.
  • One participant experiences an error and terminates the connection gracefully after sending a problem-report.


  • Sender: initiates the connection termination.
  • Receiver: is notified of the termination.



For guidance on diagrams see the corresponding section in the overview.


1. termination

  • Type: iota/termination/0.1/termination
  • Role: sender

Used to inform the receiver that the sender wishes to terminate the established connection.



2. termination-response

  • Type: iota/termination/0.1/termination-response
  • Role: receiver

Response from the receiver that the request to terminate the connection was acknowledged. MUST be sent if the field please_ack is present in the termination message.




This section is non-normative.

  • Which party terminates a connection depends on the application but is usually the same as the one that initiated it following a successful interaction to achieve.
  • Any party may terminate a connection at any time, even during a protocol.
  • A termination message indicates a graceful end to a connection but the underlying transport layer connection could terminate without this message. Implementors should implement reasonable timeouts and reconnection capabilities.