less than 1 minute read


  • 2D/ Why the Internet Needs DIDComm - IIW From: IDCommons By: Sam Curren Type: Session notes Date: 2021-05-06 Event: IIW
    • Enables Verifiable Communication
      - Intelligence at the edge (like email)
      - Protocol Based (like email)
      - Supports HTTP(s) (like APIs) and others as a transport
      - Bluetooth enables Edge to Edge transport
      - Mobile / Offline Friendly (like email)
      - Supports rotating from one DID to another
      - Security independent of transport
      - Protocol development becomes easier and more robust (unlike email)
  • 2E/ Decentralized Semantics 101 - IIW From: IDCommons By: Paul Knowles Type: Session notes Date: 2021-05-06 Event: IIW
  • A digital network must contain authenticable data entry and immutable data

    capture elements in order to maintain balance and integrity.

    Within the context of a decentralized network, these fundamentals enable a self-regulating system where …

    (1) data inputs can be trusted as having come from an assured source under the control of a governing entity; and

    (2) semantic items ensure that the meaning and use of inputted data remains unaltered for all interacting actors.

  • 21A/ DIDComm and the Self-Sovereign Internet - IIW From: IDCommons By: Phil Windley Type: Session notes Date: 2021-05-06 Event: IIW
  • DID-based relationships are the foundation of self-sovereign identity (SSI). The exchange of DIDs to form a connection with another party gives both parties a relationship that is self-certifying and mutually authenticated. Further, the connection forms a secure messaging channel called DID Communication or DIDComm. DIDComm messaging is more important than most understand, providing a secure, interoperable, and flexible general messaging overlay for the entire internet.

  • DIDComm and the Self-Sovereign Internet By: Phillip J. Windley Type: Post Date: 2020-11-11
  • DIDComm is a protocol layer capable of supporting specialized application protocols for specific workflows. Because of its general nature and inherent support for self-sovereign relationships, DIDComm provides a basis for a self-sovereign internet much more private, enabling, and flexible than the one we’ve built using Web 2.0 technologies. This talk introduces DIDComm, discusses its protocological nature, and presents use cases in the Internet of Things. Demonstrations of DIDComm protocol interactions will be shown on the Pico platform, which implements the Aries Cloud Agent (ACA) specification.

  • Why we need DIDComm - Identity Woman From: DIF By: Kaliya Young Type: Post Date: 2022-01-12
  • This is the text of an email I got today from a company that I had a contract with last year […] I was reminded quite strongly why we need DIDComm as a protocol to enable the secure transport of all sorts of things not just signed VCs but intermediate uses

  • DIDComm Mythconceptions By: Daniel Hardman Type: Video Date: 2021-11-10
  • DIDComm is a peer-to-peer communication technology for SSI (self-sovereign identity) with security and privacy properties rooted in DIDs (decentralized identifiers). Its core value proposition is often misunderstood or oversimplified. This webinar provides a proper mental model.

  • DIDCOMM - Sam Curren, Importance of DIDs From: twit.tv By: Sam Curren Type: Episode Date: 2022-06-15
  • Sam Curren unpacks for Doc Searls and Dan Lynch why DIDs and DIDcomm are the best approach to identity—and to making people first-class citizens on the Internet. Curren also discusses the origin story of picos and the advantages of nomadic living and hacking.


  • Aries RFC 0453 - credential issuance protocol using DIDComm V1 data formats From: Hyperledger Type: Rfc Date: 2021-04-15
  • An optional mechanism for providing credential supplements during issuance. Supplements are also used in credential presentation.

  • Aries RFC 0454 - Present Proof protocol V2 using DIDCommV1 data formats From: Hyperledger Type: Rfc Date: 2021-04-15
  • A minor update to add mechanism for a Verifier to request the Prover submit multiple presentations in the “presentation” message(s), each presentation sourced from different credentials that satisfy the presentation request. An example use of this capability is an employer (Verifier) requesting multiple “proof of employment” presentations from a job application (Prover), each satisfying the one presentation request.