1E/ DIDComm Mythconceptions: understanding the most misunderstood opportunity in SSI

From IIW

DidComm MythConceptions: de-myth-tifying the most misunderstood opportunity in SSI

Tuesday 1E

Convener: Daniel Hardman

Notes-taker(s): Charles Lanahan

Tags for the session - technology discussed/ideas considered:

DidComm, Myths, Implementations

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps: 

Session Slides: https://docs.google.com/presentation/d/1wz1cqUDI8M9w1Q8-gvJ_8zCjefTOd68LmrGj2UCBgI0/edit#slide=id.gefc9b12ddf_0_142

  • Myth: Security and Privacy of communications mechanism is only one feature of Didcomm it is not the central focus. Security and privacy of communications are considered table stakes in the modern internet

  • Myth: Didcomm is re-inventing its own security/crypto

    • Didcomm uses a variety of IETF RFCs and RFC drafts, some of which adhere to NIST specs.

    • Influenced by Jose specs and a variety of mature standards. Mostly focused on structure and high-level conventions in regards to the crypto/security.

  • Myth: MITM Gap

    • Didcomm focuses on transport mechanism, the “pipe”, and not necessarily the agents using those dids. MITM is a problem that operates outside the scope of the spec. Very similar to TLS spec.

    • VC’s are where the “human/agent trust” comes from while Didcomm represents the “cryptographic trust”. Mitm attacks usually focus on violating that “human trust”.

  • Myth: For Hyperledger Only

    • Did methods, cred types, blockchains/ledgers/kv stores, governance models are all outside the scope of the spec. None of these is hyperledger specific

  • Myth: “Not ready”

    • Didcomm v1 has been in production since 2018

      • V2, spec is 4 years old. Dozens of contributors, thousands of man hours at Hyperledger and DIF heading to IETF

    • Interop proven, multiple vendors, implementations in multiple languages, multiple forms of cryptographic support, and multiple crypto dependencies that can be chosen

  • Myth: Just another cred exchange approach

    • Undersells the potential within the didcomm spec. The difference between old style apis and didcomm is the generality in terms of what can be done. Old style apis are much more constrained with what’s possible in terms of communicating with other humans/organizations/agents.

  • VCs are a standard way to say something about an identity whereas Didcomm is a standard way to interact with an identity. This is one of the primary features of Didcomm.

  • “Without requiring institutional facilitators” one of the primary features of didcomm.

Q&A / Comments

  • Really cool because Didcomm generalizes and overlays what could be the whole Internet

  • Comment on Didcomm design. Security Protocols are incredibly difficult to design and implement. Long history in example TLS of specs being broken not because crypto failed but because protocol was broken. Didcomm could have been implemented using TLS 1.3 instead of Jose.

    • The reason Didcomm team didn’t do that (although they started with TLS 1.3) was that they made an intentional design decision not to use TLS 1.3 because they wanted to move away from basing their spec on a transport protocol. They thought about finding a place in TLS spec to put dids but the difference between implementations and specs (in TLS) remain somewhat far apart in the world (some things in the spec aren’t implemented in most of the TLS libraries) and so for ease of design they decided to start from scratch.

    • Another reason Jose was chosen over TLS was because Didcomm wanted to be session-less (TLS spec a lot of the time requires a session to exist).

  • Jose has many feature requests for perfect forward secrecy but none exist yet. Not sure if that should or should not exist yet.

    • There is a PR against the spec for this feature currently in discussion.

  • Privacy / anonymity not addressed in the spec. Do you think this is appropriate?

    • Privacy / anonymity hygiene is typically where privacy/anonymity requirements are often violated in the real world. Didcomm starts there so at least the possibility of privacy and anonymity is potential within the spec.

    • Didcomm cannot enforce restrictions/requirements on Bob’s use of Alice’s data as that was considered out of scope.

  • We’re used to ephemeral communication channels on the current Internet. However, with Didcomm we face a future of lifetime communication channels that represent a challenge in logistics, representation, and management between entities (like ATT and customer).

    • This represents a challenge for the future.

  • Re-authenticating control of a did by a person for example is a challenge for the future. Assuming Alice has given Bob a did, how does Bob later validate that Alice is actually in control of the Did he gave to Alice?

  • Risks of security of storage credentials among other things require thinking about that “human trust” and “cryptographic trust” on multiple levels.

Retrieved from "https://iiw.idcommons.net/index.php?title=1E/_DIDComm_Mythconceptions:_understanding_the_most_misunderstood_opportunity_in_SSI&oldid=23937"