Mike Prorock: Recording is on you all and welcome to the weekly Community credentials group meeting the this should be a good fun one today as we are talking about DIDCommv2 I am pasting the link to the agenda in the chat here we are graciously joined by Daniel Hardman to discuss details. ✪
Mike Prorock: Already saying oh wow did come to let me hop on so that's a good sign the just a couple of quick notes as we get started anyone can participate in these calls and that means anyone at all however any and all substantive contributors to actual work items must be members of the ccg with a full IP our agreement signed I will paste a link to join the chat in case you are so interested these minutes in an audio recording. ✪
Mike Prorock: GitHub and we do use either IRC or the jitsi chat to Q speakers so if you want to get on the Queue please type Q Plus to be added to the queue queue - to pull yourself out you can also say q+ followed by the word to all space than the word to and the thing you want to mention in case you are like me and forgetful and need to remind yourself when your turn comes up please do be brief when you pop up depending on what the state of the queue. ✪
Mike Prorock: Is just to make sure everyone gets a chance to chime in. ✪
Mike Prorock: This meeting is held by voice not by chatter IRC so any off-topic IRC comments are subject to lesion from the record we do work hard to manage a single thread of Contra conversation so everyone can participate and be heard please respect the group process by joining the queue when you have something to contribute we fortunately have robot overlords that can scribe for us today but if you do feel like making Corrections you can see what Manu who has been doing in order to correct that which is. ✪
Mike Prorock: Ash the thing you were correcting / the thing you are correcting it too so just normal said syntax there quick call for any introductions the anyone new to this call not been on this call would like to be introduced to the group etcetera we are a friendly bunch here and would love to have you. ✪
Topic: Intros and Announcements
Shawn Butterfield: Yeah I think that I'm probably new to this call I was on a couple of times so far I'm a software architect at Salesforce I lead a lot of our engineering groups for our development and as well as our safety Cloud our CRM course ERM cloud and some of our other platform Stacks I'm involved in building a new engineering Organization for decentralized identifiers self Sovereign identity and verifiable credentials. ✪
Shawn Butterfield: Happy to be here and working with you all. ✪
Mike Prorock: Awesome it is great to have you Sean and if you are at all interested in any of like the traceability side of things feel free to ping me or or a steel or anything like that we'd love to get some input from you and the team all know that side of the world is there's a lot of fun activity going on there as well as the usual suspects for other topics but that tends to be a area of interest that I'm working on a lot these days. ✪
Mike Prorock: Double check I didn't miss anyone in the queue awesome well we will move along here and go to any quick announcements or reminders anything from the community worthwhile of announcing I do have one I'll start with which is / nist's post last week they missed their window that they were shooting for of March 31st but they are very close. ✪
Mike Prorock: Android is ation so they said please be patient with us we are sorry so hopefully we will get an announcement on that very soon Manu I see you on the queue. ✪
Manu Sporny: Yes um to real quick ones last week the verifiable credentials 20 working group Charter was accepted by the working group so that's big news you know fairly fairly big group hard to get agreement but the charters done now for the verifiable credentials to working group it is being handed off to the w3c management to get a vote a formal vote among all. ✪
Manu Sporny: 450 Plus some odd w3c members so we should see that go out some point in the next month or so voting typically takes around a month or so ones voting starts and then the group starts shortly thereafter there is a face-to-face get together this year in Vancouver w3c it's the w3c's technical plenary working it's there you know yearly get together it's in person for the first time and in Vancouver early September early to mid September I think we will almost certainly have a face-to-face verifiable credentials working group meeting there so if you are interested in being there you may want to start looking into booking and travel and in that kind of thing getting approval okay that's the first one the second one is we've had a bunch of really great discussion on digital wallet protocols. ✪
Manu Sporny: Resulted in document that is under that we're currently working on called the w3c ccg digital audio wallet protocols analysis document it come B2 is is a part of the stuff that we're looking at so it's great that Daniels here to present that work we've got other protocols outline there we also have something called the. ✪
Manu Sporny: Copy security model in that document is here these are both very rough work in progress type things but you if you're interested I feel like we've been able to accomplish a lot in the past three weeks and will continue to keep working on those things if you are a specialist in some of these protocols like we've got a number of dude calm people here today please help us categorize did Cam and. ✪
Manu Sporny: It takes some work but we're trying hard to boil this stuff down so it's easier for everyone to understand that's it. ✪
Mike Prorock: Awesome ADI I think that wrapped audio bounced for me a little bit there but I think it's still coming through so with that I am going to pass it over to mr. Daniel Hardman to Dive Right In so that we're not burning any extra time here and we'll get off and going so. ✪
Topic: DIDComm v2
Mike Prorock: I can hear you fine you're coming through loud and clear. ✪
Mike Prorock: Yeah I would say at least 10-15 minutes Q&A Reserve at the end because I know there are some folks highly interested so you know so you know and I can watch the queue so like if something burning pops up while you were talking we can jump right in and get to that stuff if it's a high priority topic. ✪
Daniel Hardman: 30 Second elevator pitch on what DIDComm is -- sentence I want to use "A framework for safe, structured interactions built atop DIDs"... those words are chosen deliberately. ✪
Daniel Hardman: I don't mean framework in "Zend framework" -- in sense that there is a skeleton that you can hang things on. Specifically, don't mean DIDComm is an API, don't mean algorithm, data model, or format, or library or component. ✪
Daniel Hardman: Safe is a deliberately chosen word, means more than secure, one misconception... DIDComm is pursuing security -- DIDComm cares about security, but security is necessary but not sufficient. ✪
Daniel Hardman: Privacy is a rich word, has ambiguity, not trying to define rigidly, privacy aspect... one that's subtle not understood... safe -- decentralized... I mean, DIDComm is safe because of some decentralized properties it has. Common for people in CG to extoll virtues of particular blockchain... why do you care about blockchain, we gave them story about decentralization. ✪
Daniel Hardman: Maybe you're not a blockchain advocate, maybe not meeting definition of blockchain, we all resonate wrt. decentralized... co-editors of DID Rubric, started out trying to identify vaulues/what we mean by "decentralized"... know this word means different things to different people. DIDComm is safe -- means censorship resistant, owned by no one, can't be hacked in a particular place... more than saying its secured or private. ✪
Daniel Hardman: Structured interactions -- there are tech that allow you to carry on rich chat... Slack, Discord, Signal, etc. That is secure, but not structured (or very lightly structured), primarily content requires human intelligence to interpret. ✪
Daniel Hardman: Structured interactions -- deliberately broad, more than just client-server, this why I don't use API here. Doesn't necessarily cover request/response -- interactions involve more than 2 people. ✪
<orie> A major requirement for DIDComm is support of services... so some DID Methods may not support DIDComm easily (such as did:key).
Daniel Hardman: "Built atop DIDs", first sentence will mean more later -- bookmark here -- goal of DIDComm is to help DIDs interact while retaining properties of their associated DID Methods, the goal is NOT to use DIDs to authenticate people, DIDComm is compatible w/ that goal, but that's not at center of DIDComm's target. Operative thing here, in second sentence... when DIDs interact, you may or may not know if DIDs are involved w/ certain human being. ✪
Daniel Hardman: We all know VCs are a way to do that, DIDComm is compatible w/ layering human identity knowledge on top of channel, doesn't require it or assume it'll happen. ✪
Daniel Hardman: Separate from that in many respects -- JoeA sent a funny email about did:snail -- Could DIDComm work over postal service -- yes, absolutely, could it work over messages as git commits -- yes, what you're seeing is that nature of DID Method doesn't get in the way of DIDComm, it's relatively transparent... DIDComm could exhibit best values of itself... most important characteristics.... ✪
Daniel Hardman: DIDComm avoids sovereignty-endangering silos -- might be a controversial statement, will explain that in more detail later. ✪
Daniel Hardman: DIDComm Messaging specifies a lot of things, but doesn't tell you how to exchange a credential, how to verify identity of human, how to apply for a loan, high level business process kinds of things... DIDComm allows you to do low level things, to build protocols out of primitives. ✪
Daniel Hardman: Some things DIDComm explicitly tells you how to do -- create or use wallet, work with credentials, associte a DID with a human, bind to biometric, etc. ✪
Daniel Hardman: I have this list so we know what's out of scope for DIDComm... these are protocols that could be used to build on top of DIDComm -- IssueCredential, ProveWithCredential, Connect, Introduce, SayGoodbye, ✪
Daniel Hardman: ReportCrime for example -- identify reporters w/ DIDs, use DIDComm to build ReportCrime protocol, could call out to credential exchane protocol, schedule an appointment protocol, way of having composable rich interactions... interactions on our mind the most are IssueCredential and ProveWithCredential, can do that on top of DIDComm messaging. ✪
Daniel Hardman: I'd like to talk about Structured... talked secure messaging, mentioned Signal -- this is a venn diagram, shows sphere of concern for secure messaging... problem doman for structured messaging, or maybe messaging isn't right... structured interactions. Given example of each part of Venn diagram, suggesting contrast... Signal is clearly about secure messaging. ✪
Daniel Hardman: Salesforce provides security, but talking about difference in focus, the value of that technology is focused on what you can automate because you have the structure, structured is important for achieving the goals. ✪
<shawn_butterfield> In complete agreement, Daniel. Although we'd call it "Trust" :)
Daniel Hardman: DIDComm lives in the middle... protocol, tap to pay, two devices -- asked about cybersecurity risks of MitM -- if security is good enough, why do you need DIDComm -- example of misconception wrt. security... DIDComm security is necessary but not sufficient to accomplish goals... NFC interaction, if I get challenged for credentials, I can prove something, ability to structure interaction, tap to pay -- step 7, switch over and challenge for ✪
Credentials... I wanted that ability in NFC project, just having security wouldn't give me everything I wanted to accomplish there. ✪
Daniel Hardman: Example of Salesforce, they provide security as well, difference in focus on business value is most interesting... walk to talk about subtlety in security next -- how we examine security... before getting into that, though, some analogs. ✪
Daniel Hardman: DIDComm -- a frameworkf or salfe, structured interactions buil atop DIDs.. similar analogies... ✪
Daniel Hardman: Swagger A framework for APIs built atop REST. ✪
<orie> love this slide.
Daniel Hardman: S/MIME: A framework for secure, unstructured interactions built atop email. ✪
Daniel Hardman: CORBA - A framework for distributed objects and RPC built atop RMI. ✪
Daniel Hardman: One intersting thing to note is difference between safe and secure -- contrast DIDComm and S/MIME -- safety in DIDComm is intended to suggest that it has different set of goals than pure security... S/MIME is more true to say the "S" is an indication that it's focused on security. ✪
Daniel Hardman: Want to talk about Swagger and compare to DIDComm -- like Swagger, not trying to dis Swagger, trying to show why difference in focus has intersting consequences -- drew diagram on OpenAPI as foundation -- could argue on foundation, set of conventions, methodology lets you do things that build APIs, web service APIs, Yahoo Finance has Swagger file you can download, OpenStreetMap I think has that as well. ✪
Daniel Hardman: VC API that this group works on is in this category -- building APIs a particular way -- put REST/TLS, other tech that makes Web what it is today -- OpenAPI assumes is going to be there. OpenAPI Framework as a generic thing, and specific things built on top of it, are casually called Swagger by devs... developers don't say "Show me your Swagger"... drawing a box around grayed out box... I want one of those... let's talk about one of those things. ✪
DIDComm has been used by a cover term that confuses what it is. ✪
Daniel Hardman: DIDComm messaging is specific to OpenAPI -- WACI/PeX WACI/DIDComm is constructed out of those primitives... WACI sits above it... higher level construct than raw construct... all of it collectively is called DIDComm in some contexts... yellow rectangles on right -- application protocols, protocols at different layers -- application layer protocol, higher level construct than something underneath it. ✪
Daniel Hardman: Claim I've made several times -- world of web service APIs tends to lead to silo effect... this is not the silo effect that you might think I mean, everyone is insular, no interop can succeed -- not what I mean... ultimately, there is a silo effect with microservices. ✪
Daniel Hardman: If you think microservice, unit of encapsulation, and that encapsulation wants to draw boundaries... whatever functionality you want to expose through API -- pink vertical diagrams, mapping in code you wrote... lat/long, but then at top of set of code, you need an interface surface and what you do is you make some callable URLs, all behind a particular endpoint, particular URL namespace, pick certain kinds of behavioural expectations around ✪
Timeouts, state management, ... all these decisions, and that gievs you a surface for your API. ✪
Daniel Hardman: The problem is every surface is different, you combine those things in different ways... client and server are different things... you can have server act as a client, and client that has server behind it, but functionally client role is different... what you end up with is analysis where you want to plug client into surface, and you can do that. ✪
Daniel Hardman: But can that client plug into another API, chances are pretty low... what if all APIs have same authn mechanism -- that would be like OAuth2 or OpenID Connect, beneficial, but doesn't make surface identical across every surface that you create. ✪
Daniel Hardman: There is a link about authorization patterns in microservices... net effect here is you can't easily switch a client for service A and service B and you might say, you don'tw ant to do that, but the problem is that the unit of security you're able to achieve... subtlty about scope... unit of security is same as unit of API scope. ✪
<orie> Another way of thinking about this, is that true decentralization comes at a cost... peers need to be more equal, which comes at a cost.
Daniel Hardman: If you want security on one silo and security on another silo, nine dimensions that you have to translate across, if session expires in one silo and then not the other, timeouts in one and not the other, you have problems... these make it difficult for clients to wander around and talk to them. ✪
Daniel Hardman: An unsiloed solution makes sure that the interface is always the same -- DIDComm does that, many protocols but same interface. ✪
Daniel Hardman: Errors are reported a particular way, message types are done a particular way, state management is done a particular way, etc. ✪
Daniel Hardman: Plugging in doesn't mean you can get work done -- you can still have a conversation, you can discover what things you can do with someone else -- walk in building, get DL, you can't do that here, but you can get one in next door... next door you try same thing all over again, something like that can be done in DIDComm -- do you support following way of exchanging credentials... ahead or behind in compatability, keys you dont' support, etc... but you can find that out, you don't need inability to walk into office like human behing... but previous diagram, you can't even start. ✪
Daniel Hardman: Instead of client/server, you have peers -- doesn't mean you don't have servers and mobile phones... everything is modeled as peers, reciprocal relationship where anything can be plugged into everything else, can be unsiloed... renew DL, in middle of conversation about DL, then in middle you talk about paying, you don't have to have headache about translating all things to web service, all of that is common, not just mechanism for authn, but very data will be common. ✪
Daniel Hardman: Hopefully you'd guess this... DIDComm and WACI -- WACI is part of world of DIDComm, application layer protocol built on top of DIDComm messaging, there are other credential exchange mechanisms that do DIDComm messaging... hopefully when WACI hits a certain point of maturity, it'll exceed those. ✪
Daniel Hardman: What about DIDComm and CHAPI -- CHAPI might have another way of describing this... DIDComm thinks of CHAPI as a way to move wallet data to move things between things -- transport layer wrt. DIDComm. ✪
Daniel Hardman: The reason this relationship hasn't been explored more, DIDComm sweet spot and sweet spot for CHAPI aren't that close together. ✪
Daniel Hardman: DIDComm and OIDC -- ODIC is solving authentication problem and authn is one of these high level things, application level interaction, higher than low level messaging... OIDC is a rough analogue to WACI or other application layer protocols that do credential-based authn. ✪
Daniel Hardman: Versions of DIDComm... there was v0 (Agent to Agent), v1, v2 (not expected to be described as IETF or W3C), v3 is imagined, haven't started work on it, believe work will be done here at IETF. ✪
<orie> Based on W3C perspectives on decentralization, I would consider removing W3C from that list.
<bumblefudge> ��
Daniel Hardman: It might be done at ISO, don't know if it'll happen, CCG might be a good place -- might be interesting to talk about it. ✪
<orie> <3 JOSE!!!!!
Daniel Hardman: Shows relationship between IETF and DIDComm v2 components -- won't spend a lot of time, won't take a lot of technologies out of JOSE stacks. ✪
Daniel Hardman: About implementations, some of these are stale -- spec has evolved past -- other implementations are quite good -- something from thsoe four rectangles... JS, Rust, Swift, Python, Java are quite good. ✪
Daniel Hardman: If anyone is interested in experimenting, with that, I'm done and ready to answer questions. ✪
Mike Prorock: I know SecureKey has been working on implementations, standardization requires implementations -- who is signing up to do implementations... how are things looking on that front? ✪
<orie> It would be cool to get a version of this slides with brand logos instead of git repo
Daniel Hardman: This is one of the things that makes DIDComm ... not formal standard like W3C, we don't have formally defined test suite, however we have checked in test data and scenarios and tested four of these librarie sand got them to pass gainst these tests, demo that shows libraries from different programming languages calling each other... haven't met same bar as necessary by W3C/IETF -- who did it... formally tested ones are ones under SICPA DLab ✪
Account on Github, I was working w/ team that did that work. There might be others. ✪
Orie Steele: I've been waiting to start an implementation in Typescript, been waiting following spec at DIF, when would a stable permanent URL w/ a version would get attached? ✪
<orie> awesome!!!!!! make sure to get a perma URL :) so implementers can point to a permanent version.
Daniel Hardman: There is a PR right now that proposes to change status to WG approved. appropriate to merge? Not yet, still 2-3 places in spec that need work. Goal is to have it WG approved at IIW. We had it pretty close to that state at last IIW, but got interesting questions and decided we needed to hold off until we answer questions. Spec is much better as a result of that. ✪
<orie> I don't consume critical security deps I don't write when possible :)
Daniel Hardman: I don't feel like writing an implementation of DIDComm is very common, maybe it makes sense for you, but our expectation is that a lot of people can consume implementations on this list, they're all open source... Typescript? Two that are pure native typescript an wasm build, npm installed DIDComm already. ✪
Manu Sporny: Thank you for presenting. Learning a lot. Useful to understand your mental model. [scribe assist by Heather Vescent] ✪
Manu Sporny: Appreciate preso, learning a lot - standardization track? struggle with understanding how different is it from http, etc? ✪
Manu Sporny: Wanted to appreciate for always explaining. The questions about implementation were good. Wondering the standards track. Struggle to understand how it is different from the HTTP protocol. [scribe assist by Heather Vescent] ✪
Manu Sporny: What key thing does DIDComm do to not fall into the intraprotocol trap? [scribe assist by Heather Vescent] ✪
Daniel Hardman: Excellent question, important one -- risk is real -- we do have some experience implementing interoperable stuff, we know what it's like to interoperate... Aries Interop Profile had 10 different vendors, vendors used 5 different stacks, we achieved good interop, sharing credentials. [scribe assist by Manu Sporny] ✪
Daniel Hardman: An excellent and important questions. The risk is real. We do have expereience implementing interoperable stuff. The Aries interop 1, circa 2019, had 10 vendors. The vendors used 5 different underlying stacking, and achieved interop including sharing credentials. We also learned the spec wasn't tight enough in some places, and that can be a source of risk. [scribe assist by Heather Vescent] ✪
Daniel Hardman: We also learned that spec isn't tight enough in several places, that could be a source of risk, one thing that we're changing here is hard assumption that everything is a peer. [scribe assist by Manu Sporny] ✪
Daniel Hardman: The one thing we are chanign is that everything is a peer. DIDCOMM doesn't think about clients/servers. [scribe assist by Heather Vescent] ✪
Daniel Hardman: It's the peer characteristic and DIDs are the underlying under it that gives me hope. [scribe assist by Heather Vescent] ✪
Daniel Hardman: Doesn't mean you can't have clients/servers -- DIDComm doesn't think about clients/servers -- or supporting callbacks, if you understand how a server could behave as a peer you could read that into it and because spec refuses to talk about that, and peer characteristic, and DIDs are fundaemntal that gives me some hope. It's a guarded hope, does not guarantee glorious outcome. [scribe assist by Manu Sporny] ✪
<edoardo_operti> Thank you very much for the presentation, having some issues with my micro so I couldn't present myself today but I look forward to join the next weekly sessions!
Mike Prorock: I'm going to close it out w/ a question, had some JOSE questions -- post quantum signatures... question about COSE -- where are things going there, or are you lookin gat abinary side? [scribe assist by Manu Sporny] ✪
Daniel Hardman: That's been deferred out of v2 of the spec, on the table for a v3 -- it won't happen in the spec that's about to become frozen, but is under active discussion. [scribe assist by Manu Sporny] ✪
<heather_vescent> Thanks Daniels - appreciate you presenting on this today.
<orie> IMO defering COSE was/is super smart
<orie> COSE tooling still sucks.
Mike Prorock: Really appreciate the time today, lots of great info, as always looking as good ways to increase communications between CCG and DIF, this was a good demonstration of that desire. CCG spec or work item w/ DIDComm and/or leverage adoption, really appreciate it, know it's a mutaul feeling, want to thank you again. [scribe assist by Manu Sporny] ✪
<orie> Please share the perma URL for v2 when its available, on the list.
Daniel Hardman: I appreciate the time, if anyone wants slides, URL should keep working, download the slides, demonstration at IIW -- six months ago, more or less get demos... Hello World in DIDComm is pretty trivial. [scribe assist by Manu Sporny] ✪
<cel> ��
Mike Prorock: Great, have a wonderful Tuesday, will talk again next week. Enjoy your day! [scribe assist by Manu Sporny] ✪