The Future of Telecommunications is DID Comm

The Future of Telecommunications is DID Comm

Thursday 20D

Convener: Vic Cooper & Seth Back

Notes-taker(s): Bruce Conrad & Others

Tags for the session - technology discussed/ideas considered:

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

Note: the session was recorded https://www.youtube.com/watch?v=UxUQOVzpI6Q&t=729s

“DIDComm is your own private VPN”

One diagram from Vic’s slide deck <insert link to slide deck here>

A couple of points from Seth’s slide deck <insert link to slide deck here>

“Transport agnostic security”

“Strong identity guarantees”

Questions

Sam Curren. There is a DID for the conversation. Vic. the item, the bot, the live agent, the caller are all parts of the conversation. Sam: the management of a group. there is an agent which moderates. conversations which legally require auditing; the bot can do that, and store elements of the conversation. Is this what you’re doing. Seth: yes, the conversation object was always very important. Vic: from a telcom perspective, you are now choosing the channel first and then directing the conversation. here the conversation is created first; when an agent becomes available, you can choose the channel -- messaging, phone, etc. The conversation can span many interactions. It is more like a case. But the company isn’t opening the case, you as the customer open the case and control it, without having to remember a case number. Sam: that’s awesome

Marc Davis: multiple high fives. an abstraction of channel and device. an enormous opportunity. about presence and availability; is that built in? (see also conversation in chat). Vic: an organization could fit this into its web chat area; web chat with benefits. once established, can turn on audio, or Zoom conversation. Very difficult to spam because you don’t have a public endpoint. If one of your channels is misused, you can just shut it down. Seth: you have to be added to the conversation before you can send messages about it.

Vic: case of a credit union where people are receiving calls that appear to come from its 800 number. How do you stop this? Now, you can't. The agent which represents you operates almost like a web site. When I call my bank, I have to go through a ritual to identify yourself. But how to identify the bank?

Andrew Whitehead: good work, this is cool, more work with DID Comm transports than I’ve seen before. With the payload inside of JSON, wonder if you could use a binary transport instead to reduce overhead.

Seth: we use protocol buffers a lot internally so it’s quite a bit faster. I like binary protocols. We push our message stream through the nats that way.

Ryo Kajiwara: thank you for the talk. email lacking identity. This looks like the future of email and messaging going forward. Where can I look for information? Seth: we relied heavily on the Aries RFCs. What we’re doing is a bit of a departure. There is a huge amount of information and it's like drinking from a firehose. Vic: for a couple of weeks I couldn’t talk to Seth; he was busy understanding. Sam: working on DID Comm version 2, so there is information available. Vic: what is email exactly; is there a way it could go over the same kind of channel; definitely “yes.”

Ben Weaver: saw the demo, an example of me as a customer reaching out. We talked about spam. my email address or phone number can be shared around; but it allows my friend to share my number. How can inbound be facilitated? Vic: you can do introductions over DID Comm. Seth: There are “introduction” RFCs in Aries. For our purposes the communication can add users to the conversation.

Vic: also how do you connect to a rep from a company. the initial connection is to the company and they add that person in. We have personas: my work persona, my friend persona, etc. The company has people representing them, but all conversations are routed through them.

Dave Sanford: having a fantasy about having “allow” lists. one problem are all of the aggregators using web beacons etc. then they direct content to you. I want to unpeel the onion and aggregate into my devices myself. DIDs inside of DIDs. Vic: When you connect to a company you start by connecting to the agent (now, generally a web site). Once you make the connection they can use that to send content intended only for you. You could go even further and know that all my interaction with the company is going through the (something like a) VPN. Dave: a good citizen will behave well, but everything becomes a gateway and the company may want to pass content on to you that they get from someone else. Vic: were only scratching the surface

Ben: thinking again of spam; trying to connect this back to basic trust. How do I know I have the correct company? in the presence of all those phishers out there. [in the chat, people are saying, “Trust Frameworks!”] Vic: there’s an element of human trust, organizations that may certify the company.

Vic: the possibility of no more passwords or pins, no more waiting, should unlock faster better business processes, reduction of compliance costs, one-click customer support. The whole point of this is to reduce effort. What used to take ten steps (or a hundred) now just takes one. Goal is effortless communication.

Zoom Chat Content:

From swcurran to Everyone: (1:28 PM) 
Could someone ask the host if this can be recorded? I'd love to hear this session, but can't make it.


From Josh Verbarg (State Farm) to Everyone: (1:33 PM) 
You can set that yourself too.


From Sam Curren to Everyone: (1:33 PM) 
I have. :)
still a help for new folks though.


From Josh Verbarg (State Farm) to Everyone: (1:33 PM) 
very true


From Andrew Whitehead to Everyone: (1:39 PM) 
Possibly four DIDs..


From Andrew Whitehead to Everyone: (2:03 PM) 
I think that comes from the model where the ‘wallet’ is the only storage.. I think gradually things are moving away from the term wallet towards multiple specialized backends


From Drummond Reed to Everyone: (2:03 PM) 
+1


From Geovane Fedrecheski to Everyone: (2:05 PM) 
@andrew Just to make sure I got it right: "app wallet" and "cloud backup service" would be examples of those specialized backends?


From Andrew Whitehead to Everyone: (2:06 PM) 
The current division is probably more like KMS (key store), credential storage, protocol state - Mike Lodder has an Aries RFC proposal with more details on the proposed storage architecture requirements


From Drummond Reed to Everyone: (2:06 PM) 
We definitely need the DIDComm spec to define one standard DID document service endpoint type for requesting a DID connection.
queue?


From Nathan George to Everyone: (2:07 PM) 
The original though there was that the service endpoint was sufficient to specify that, but perhaps implementations haven’t fully implemented that?
Drummond++
Is whipped cream really whipped if it isn’t whipped with whips?


From Marc Davis to Everyone: (2:09 PM) 
I have some questions when at relevant point in presentation: 1) Do you have a model of “presence”/“availability” of communicating parties to enable communicating parties the way IM does? 2) Do you have a model of channels of communication (e.g., sms, email, IM, voice, etc.) and devices (phone, PC, etc.) to enable smart routing of messages and to most present/preferred channel+device?; 3) Can your architecture support better spam filtering of incoming communication requests, and if so how (Trusted connections? Reputation scores across multiple connections? etc.?)?


From Ryo Kajiwara to Everyone: (2:10 PM) 
+1 on spam filtering, would like to know about that


From Drummond Reed to Everyone: (2:10 PM) 
Who let Marc Davis in to ask all the graduate level questions?? ;-)


From Drummond Reed to Everyone: (2:11 PM) 
We’re still in elementary school here :-)


From Andrew Whitehead to Everyone: (2:11 PM) 
I think didcomm+http:// or similar


From Marc Davis to Everyone: (2:11 PM) 
+1 Drummond ;-)


From Nathan George to Everyone: (2:11 PM) 
A few spam approaches: didcomm means mutual authentication and if you attach proofs for attributes you get signed/certified attributes that can’t be spoofed, so you can request real legal names for orgs and people, next payment decorators can allow for staking like “if this call isn’t worth it to you, you can collect my X dollars/cents” (spam insurance if you will).


From Nathan George to Everyone: (2:13 PM) 
I think the proofs on top of the connect protocol means that you can fully authenticate existing protocols, track where introductions come from because the intro comes in on a correctable channel and as a result you don’t need the “connect stamps” stuff that never took off in email except for extreme cases


From Drummond Reed to Everyone: (2:13 PM) 
+1 to all of Nathan’s points. IMHO one of the MOST important points about DIDComm is that it runs over DID-to-DID connections and so once you establish a secure, private connection, you KNOW that messages on that connection are authentic unless the other party’s keys have been hacked.


From Nathan George to Everyone: (2:14 PM) 
I want all my caller ID data notarized by someone who collects money from you regularly. That way there is an appeals process for gross fraud.


From Drummond Reed to Everyone: (2:14 PM) 
While that’s not a non-zero risk, it’s SO much less of a risk that all the wide open vulnerabilities in non-secure messaging protocols today.


From Marc Davis to Everyone: (2:14 PM) 
I am imagining a spam filtering approach that uses trust across multiple parties in the network too create a reputation/trust score without sacrificing anonymity and that can be personalized to the querier based on a “transitive trust” assumption across your trusted connections and their trusted connections, but done anonymously.


From Marc Davis to Everyone: (2:14 PM) 
Typo: to create


From Drummond Reed to Everyone: (2:15 PM) 
I gotta run to another session, but I just want to say I LOVE the name of this session. DIDComm really IS the future of telecommunications (in fact nearly all digital network communications). It is THE protocol at the thin waist of the Trust over IP stack.


From Nathan George to Everyone: (2:15 PM) 
The think I love about HearRo’s model is they then share common authentication across lots of channels so my caller id and my web chat and my email can all aggregate into a coherent dialog centered on a relationship


From Marc Davis to Everyone: (2:15 PM) 
+1 Nathan George. That is what I was hoping for, and then to use that to enable smart routing.


From Nathan George to Everyone: (2:16 PM) 
Cool. Signal if you have it, fall back to apple, fall back to ....


From Drummond Reed to Everyone: (2:17 PM) 
I’m in exactly the same camp as Vic. I don’t accept calls from numbers I don’t know.


From Ryo Kajiwara to Everyone: (2:18 PM) 
Some questions: (1) Is DIDComm able to do multi-party communication or encrypted group communication? (2) Are there technical resources I can look into to start? Are there "unopinionated" (not tied to a specific implementation such as Aries) specs for DIDComm itself?


From Josh Verbarg (State Farm) to Everyone: (2:18 PM) 
Phone system can spoof numbers though. So I just need to know what numbers you trust.


From Drummond Reed to Everyone: (2:18 PM) 
HeaRo is one of the first companies I know that’s recognized the full power of DID-to-DID connections
Vic, you just need to give big bucks to Joe’s campaign and then politely ask them not to send any more emails ;-)


From Nathan George to Everyone: (2:18 PM) 
Group messaging is a hard problem. We have good thoughts there and the crypto is catching up. I would love a chance to take on that part of the problem in open source code, but no one has funded that work directly yet.


From Drummond Reed to Everyone: (2:19 PM) 
GET NATHAN SOME FUNDING!!!!!


From Me to Everyone: (2:19 PM) 
+1


From Andrew Whitehead to Everyone: (2:19 PM) 
MLS is another standardization effort for group messaging, still in the draft proposal stage


From Drummond Reed to Everyone: (2:19 PM) 
Gotta run to another session, but GO HEARO!


From Marc Davis to Everyone: (2:19 PM) 
In the Joe Biden example, would it be able to automatically work across all channels and devices a person uses? It is a form of universal “unsubscribe” which would be awesome.


From Sam Curren to Everyone: (2:19 PM) 
actually, HearRo might have done something here about group communication, in one form at least.


From Vic Cooper to Everyone: (2:20 PM) 
Yes, all channels. It’s connection first then channel


From Nathan George to Everyone: (2:20 PM) 
(Group signatures that ratchet on message delivery would force catchup and prevent those who left the channel from getting message delivery outside their time as a channel member — so it should let you do cool stuff — the crypto papers are there but the performance may not be, yet.)


From Ryo Kajiwara to Everyone: (2:20 PM) 
yeah, I wanted to know how MLS can tie into DIDComm. It looks like a good mechanism to use in combination with DIDComm


From Nathan George to Everyone: (2:20 PM) 
This ^^^
MLS should be a good encryption format for group DIDComm messages, but AFAIK it isn’t far enough along.


From Andrew Whitehead to Everyone: (2:21 PM) 
I have issues with the MLS approach, because the trade-offs for a small group (<100) to a big group (10000) are very different


From Nathan George to Everyone: (2:21 PM) 
Probably a case of needing different approaches for broadcast vs private groups with peer messaging


From Andrew Whitehead to Everyone: (2:21 PM) 
Just attempting key management with that many parties seems silly


From Nathan George to Everyone: (2:21 PM) 
Once you have that many parties it helps to differentiate between speakers and listeners


From Andrew Whitehead to Everyone: (2:22 PM) 
Good point


From Sam Curren to Everyone: (2:22 PM) 
also, mediated groups vs peer groups.


From Ryo Kajiwara to Everyone: (2:22 PM) 
good point > differentiation between speakers and listeners


From Nathan George to Everyone: (2:22 PM) 
(If you love this type of discussion on MLS join the Hyperledger Ursa and Sovrin Crypto Calls, we would be happy to put folks to work integrating these ideas)


From Me to Everyone: (2:22 PM) 
love the GET SUPPORT button


From Sam Curren to Everyone: (2:22 PM) 
peer groups require no infrastructure. most large groups will need some style of 'management' that can help there.


From Marc Davis to Everyone: (2:22 PM) 
Do you have a model of how people, roles, teams, and organizations are related to support routing of messages to the relevant level?


From Ryo Kajiwara to Everyone: (2:23 PM) 
Thanks for the pointer, will look into those calls!


From Vic Cooper to Everyone: (2:23 PM) 
We use credentials to allow a representative to be a rep for a company and join a conversation


From Nathan George to Everyone: (2:23 PM) 
^^^ Revenge of the library sciences it is an ontology problem. Peer to peer private lets you model those aggregations with credentials


From Marc Davis to Everyone: (2:23 PM) 
Universal Unsubscribe is a killer feature.


From Sam Curren to Everyone: (2:23 PM) 
does the conversation itself have a DID and relationships?


From Vic Cooper to Everyone: (2:24 PM) 
Yes, the conversation has it’s own identity


From Nathan George to Everyone: (2:24 PM) 
Sending encrypted data to everyone that only some people can decrypt is a bad story (crypto eventually breaks)


From Andrew Whitehead to Everyone: (2:24 PM) 
Nevermind multiplying bandwidth by ’n’ for the sake of hiding who is talking to whom


From Nathan George to Everyone: (2:27 PM) 
Seth++


From Nathan George to Everyone: (2:28 PM) 
Drummond: Agents are now for people, organizations, things, and conversations ;)


From Geovane Fedrecheski to Everyone: (2:28 PM) 
A way to allow many to many, end to end encryption, is attribute based encryption (ABE). I don't know much about it but maybe credentials could be used as attribute sources for that.


From Nathan George to Everyone: (2:29 PM) 
Geovane if all the keys are pairwise you don’t have to go that far, the derivation (if needed) is just an optimization, as you can associate the attributes with the new keys you roll when you initialize each new interaction


From Nathan George to Everyone: (2:35 PM) 
Andrew++ WebRTC as a communications channel is underrated


From Andrew Whitehead to Everyone: (2:38 PM) 
Although the layering of DTLS over SCTP over UDP or TCP hurts a little :)


From Sam Curren to Everyone: (2:42 PM) 
There is an Aries protocol for introducing alice to bob.


From Marc Davis to Everyone: (2:42 PM) 
Like LinkedIn Inmail perhaps?


From Andrew Whitehead to Everyone: (2:42 PM) 
The Tinder protocol
Sorry I mean Introductions


From Sam Curren to Everyone: (2:42 PM) 
lol Andrew.
For orgs, a public DID can bootstrap into a peer connection.
the did:peer method is awesome for preventing spam.


From Marc Davis to Everyone: (2:44 PM) 
Excellent: Person vs. Role/Persona


From Nathan George to Everyone: (2:45 PM) 
You don’t have to attenuate everything into capabilities when you have ZKPs credentials, you can associate capabilities directly with attribute values or combinations of attribute values and not disclose the irrelevant parts.


From Andrew Whitehead to Everyone: (2:50 PM) 
Trust frameworks!


From Sam Curren to Everyone: (2:50 PM) 
Trust Frameworks!


From Andrew Whitehead to Everyone: (2:50 PM) 
LOL


From Sam Curren to Everyone: (2:50 PM) 
:)


From Marc Davis to Everyone: (2:50 PM) 
+1 Trust Frameworks!


From Nathan George to Everyone: (2:51 PM) 
This is where you need pivot points between different trust frameworks, you want a thin global interop type layer that just helps the different frameworks translate between each other.


From Sam Curren to Everyone: (2:51 PM) 
TOIP FTW

From Marc Davis to Everyone: (2:54 PM) 
@VicCooper and @SethBack: Fantastic session and opportunity! Thanks!


From Sam Curren to Everyone: (2:54 PM) 
Awesome work!


From Randy Warshaw to Everyone: (2:54 PM) 
Will there be a link to the recording?


From Ryo Kajiwara to Everyone: (2:54 PM) 
Again, thanks for the talk! It looks exciting, and I will definitely look into the tech side of this!


From Nathan George to Everyone: (2:55 PM) 
Excellent work guys, look forward to more protocol integrations across the open source stuff.