1J/ DIDComm Messaging V2 - Where we are and what to expect
DIDComm Messaging V2 - Where we are and what to expect
Tuesday 1J
Convener: Sam Curren
Notes-taker(s): Gabe Cohen
Tags for the session - technology discussed/ideas considered:
DIF, DIDComm
Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:
Link to repository to file issues: github.com/decentralized-identity/didcomm-messaging/
Session will be recorded.
Sam:
Message-based communication; trust in DIDs
Originated in 2019, now headed toward complete draft
V1 originated in Aries, V2 being discussed in DIF/now
DIDComm sits between Protocols (above) and DIDs & DID Docs (below)
DIDComm depends on DIDs & DID Docs
Johannes Ernst: What prompted V2?
Sam: People liked V1, but there were improvements to be made. Moved to DIF. Due to being Non-indy communication.
Johannes: As much organizational issue as technical.
Sam: Related work: JWM, ECDH-1PU in IETF
more standards based and similar to DIDComm
DIDComm benefits:
Security independent of transport
Foundational layer of interop
Repudiable by default - non-repudiation support
Fills gap b/w DIDs and protocols
Protocol development becomes easier + more robust
Goal is to provide more efforts on evangelism (how to use it + what it is)
DIDComm Transports -- agnostic
Http(s), websockets, bluetooth sockets, qr encoded msgs, etc
Michael Schafer: NFC?
Sam: Yes, discussed, but no formalization yet.
Current work:
Spec flow, completeness, examples, guide expansion
What’s new in V2?
Adjustments for Standards Track Deps
JWM & ECDH-1PU for authcrypt
0-RTT instead of DID Exchange
Includes more keys in original message – reduce noise
If you want to rotate, you can do it along w/ flow of messages. Don’t need to pause. DIDComm allows agents to be offline (cell-phone died, bad service)
Important to be as efficient as possible
Can send several messages if you know someone's DID
Johannes: Comparison to email?
Sam:
Yes, intended to work similarly. Extensions to DIDComm spec that allows “last-mile” messages to be sent. Can be compliant while having queue methods work differently. Allow msg to be routed in a standard way. Moving to 0-RTT makes this much more efficient. Supports rltns of any length.
JWM Headers vs decorators V1 had decorators about the message itself. Moved into JWM headers.
Return-route as an Extension
Allows a standard way of queuing. Extension in V2 makes it easier to be compliant with the protocol.
Authcrypt Only - No Anoncrypt directly, use Peer DID for better effect
Authcrypt (authenticated encryption), anoncrypt (different way for key to be communicated). For simplicity: no anoncrypt directly.
Peer DIDs provide value that anoncrypt did. Peer DIDs: DID can be created + communicated with another party without being recorded on a ledger. Efficient and desirable privacy aspects.
Impl Guide
Now exists!
Hob: Where’s the impl guide?
Sam: I’ll share
Bengo: Can you elaborate on protocols you’re excited to enable?
Sam: Focus on credentials. Excellent use. More excited about other protocols that facilitate interactions we have now. Ex. DIDComm relation we have with a website. Facilitate payment. Protocols that are powerful for business, but privacy respecting. Don’t want spam, but capability to have new conversations that one is in control of as a user.
Location sharing. Location sharing apps on phones are controlled by a central server (run by Apple or Google). Permissioned location sharing is useful. Where’s my wife???
Dave Huseby: JWM for messaging...does that mean we’re only talking about ??? transport protocol.
Sam: REST is not a term we use.
Dave: HTTP?
Sam: Doesn’t have to be HTTP. Websockets used in V2. Scanning QR codes, bluetooth, NFC popular for mobile uses.
Dave: JWM over arbitrary transports??
Sam: Yes!
Daniel Hardman: Implemented one over SMTP. Sockets, etc.
Dave: Encoded as text, using JWM?
Sam: Yes.
Kyle: Allowing for extension points in the future to improve. WG is not addressing all right now. Currently a PR.
Sam: Not trying to solve CBOR/other binary encodings right now.
Matthew Hailstone: How does it interact with other DID protocol stacks? What are the requirements?
Sam: Indy/Anoncreds will be quite receptive. It is a nice companion to things like DIF Credential Manifest/Pres Exchange. Can work well over DIDComm. No limit to the type of info that can be passed across DIDComm messaging. But not really trying to solve real-time-comms stuff.
Matthew: If I have a credential issued by a Sovrin protocol, how can I exchange the data back and forth? Is that something not targeted?
Sam: DIDComm doesn’t specify how creds are passed, but instead how such a protocol would be created. Existed in V1...yet to be done in V2. I hope you can use a well-supported protocol over DIDComm.
Bengo: DIDComm depends on a transport layer. What properties are required? Can it work on top of UDP or snail-mail?
Sam: Yes. Can be transported on anything, doesn’t have to support encryption. Some are more common: HTTP & Websockets. Lots of common use-cases on other transports.
DH: Other than HTTP & sockets, the filesystem is important. Has to be possible for one to save a DIDComm message on thumb-drive, stick it on a network file system somewhere. Has to be an option. Few demands on the transport layer.
Why isn’t it binary -- messages passed in DIDComm messaging is structured info that describes stuff. Nothing that prohibits moving binary data over DIDComm. A cred is binary. CBOR based creds over DIDComm -- knock yourself out. Problems would arise on a transport (e.g. 10GB over HTTP Post). DIDComm itself is un-opinionated.
Bengo: What would we be using HTTP/Websockets for if we had TCP+DIDComm 25 yrs ago?
Sam: No core ID layer on the internet. We don’t do mutual authN with HTTP. Possible to launch a video chat session coordinated w/DIDComm. Better foundation of trust for the resulting connection. Lots of current ID problems would go away. Would the “you are who you say you are” be different?
Places where DIDComm is not the right answer. But a good cousin/tool to travel alongside other things. Push notifications -- relationship with a bank, instead of SMS (security problems), a notification could arrive over DIDComm. A richer, more secure protocol.
Not betting on a single transport. Betting on a wide variety of interesting things being built on DIDComm as a platform.
Bengo: what would you like to see building that depends on the work you’re doing?
Sam: a number of these technologies. Involvement of DIDComm with a relationship w/ a website. DIDComm instead of username/pw. Longer-term DIDComm relationships. More mobile apps -- efforts underway. Make it easier for devs to do the right thing in terms of privacy.
I’d still use an email+pw for login (not social login!), but it’s universal & people get it. Need to change that. Get traction into systems people already use.
DH: Mesh networking if I had infinite time. DIDComm allows that HTTP does not: chatting with everyone around you at a sporting event. Reaching out to other devices in a connected mesh + talking to them. The future! No more HTTP calls back to some backend. More point-to-point comms. Still sci-fi.
Also digital cash. Not bitcoin. Transacting w/o internet -- phone to phone.
Sam: ultra-wide-band stuff. Location sharing, people in backcountry without a satellite.
Kyle: Automated scheduler using agents. Pass an .ics to someone, they pass one back, find a time to meet.
Something similar to SSB -- a way to pass GIT files.
Authentication would be great.
Bengo: what would a traditional http server look like?
Kyle: lightweight wallet into an express server or something. Use it as ID management. Pass DIDComm messages over the webpage.
Bengo: I will reach out to Sam + co.
Sam: Can go straight to authZ in some cases without authN. Cool from a privacy perspective. Can skip the “who are you step.” Progress to be made in the next 6 mo.
Matthew H: curious about QR code cases. QR codes for ticketing systems for events. Would it be a DID connection, or embed a credential in the QR code?
Sam: Initial use-case in spec has to do with passing invitation/initiation with another party. Designed to be scanned by a phone. Session tomorrow around custodial agents: interact in an SSI model without involving a device (by choice or limitation). Spec so far talking about QR code as an easy way to pass things between screen + camera. Facilitate the transfer of a cred.
Johannes E.: Do another session on the level of the actual code. I’d love to, in my terminal, send something and see it arrive at another participant.
Sam: Next IIW! Have code for v1, need more time for code examples for v2.
Johannes: Can be a foundational piece for a lot of things that are broken today on the internet. Email is broken. I encourage going to hands on.
Sam: Hasn’t happened yet, moving a lot. Moving less. Next couple of months there will be code examples + products (maybe).
Geovane Fedrecheski: Routing. With DIDcomm we have E2E encrypted channels. Is routing needed because we have NAT which prevents E2E channels? What is the role of routing in a home? How does it work?
Sam: NAT traversal, routing can help. Can send a message through an intermediary. Beyond network traversal issues, routing is useful for herd privacy. Cannot inspect the contents of a message, but can see it from A->B, I can do size inspection, etc. If passed through the routing protocol, your message is blended with many other messages. Much harder to determine what’s going on.
The routing protocol is simple but provides a wide variety.
Geovane: Is the routing protocol optional?
Sam: Mandatory to compose and send messages that respect the routing config of the receiving party. Up to the receiving party.
Micha Kraus: Q on Key rotation? How is it handled in V2? Difference b/w peer and ledger DIDs.
Sam: Key rotation is the problem of the DID. Done in the DID Doc it’s associated with. DID info can be provided in to/from fields in messages.
DID Rotation allows a party to change from one DID to another. A way to prove the rotation is authorized to happen.
Kyle: Question Ajay asked on how to migrate from V1 to V2?
We haven’t actually discussed this. We need to figure this out as we build impls. Going to be building an open source impl.
Migrating relies on the DID-layer. The serviceEndpoint itself is passed, and use that separation to handle it. Some edge cases.
Sam: We will have a section in the impl guide that addresses converting from V1 to V2. (identity.foundation/didcomm-messaging/guide/). Will be relatively straightforward.
Links on last slide.
Timeline: what’s next and moving forward. Depends on community effort. Pretty darn close to “final” before next IIW. Won’t be things moving around as much. Ongoing work will be guide expansion & reference functional code.
- wg-didcomm on DIF slack.
Andrew Whitehead: Routing protocol - what about re-encoding? Increasing the size of the payload?
Sam: Discussed, but not solved yet. When forwarding, contents are encrypted, 3-4 byte b64 encoding, there ends up being a ~30% increase in size of the message. Have ideas on how to solve, but not yet.
Kyle: Routing is likely to change the most. Expect to see a lot of innovation. Expect things to merge over time.
Sam: DIF WG will work on it until we decide where it will go. Not quite there yet. Will end up in the right place, unsure where yet. As it reaches stability here. No hindrances to building right away.
