W3C home > Mailing lists > Public > public-credentials@w3.org > April 2022

[MINUTES] W3C CCG Credentials CG Call - 2022-04-05

From: CCG Minutes Bot <minutes@w3c-ccg.org>
Date: Tue, 05 Apr 2022 21:45:59 +0000
Message-ID: <E1nbqzs-0006IM-E5@titan.w3.org>
Thanks to Our Robot Overlords and Manu Sporny and Mike Prorock for scribing this week!

The transcript for the call is now available here:

https://w3c-ccg.github.io/meetings/2022-04-05/

Full text of the discussion follows for W3C archival purposes.
Audio of the meeting is available at the following location:

https://w3c-ccg.github.io/meetings/2022-04-05/audio.ogg

----------------------------------------------------------------
W3C CCG Weekly Teleconference Transcript for 2022-04-05

Agenda:
  https://lists.w3.org/Archives/Public/public-credentials/2022Apr/0027.html
Topics:
  1. Intros and Announcements
  2. DIDComm v2
Organizer:
  Heather Vescent, Mike Prorock, Kimberly Linson
Scribe:
  Our Robot Overlords and Manu Sporny and Mike Prorock
Present:
  Mike Prorock, Daniel Hardman, Shawn Butterfield, Will Abramson, 
  TallTed // Ted Thibodeau (he/him) (OpenLinkSw.com), Sam Curren, 
  Edoardo Operti, Brian Richter, James Chartrand, Manu Sporny, 
  Michael Herman, Mahmoud Alkhraishi, Charles E. Lehner, Joe 
  Andrieu, Kimberly Linson, Heather Vescent, Paul Grehan (DIF), 
  Orie Steele, Kerri Lemoie, Dmitri Zagidulin, JeffO Real-IT, Juan 
  Caballero, Adrian Gropper, Jon St. John, Harrison Tang, David I. 
  Lehn, Andy Miller, Kaliya Young, Brent Zundel, Erica Connell, 
  Vivien, Phil L (P1), PL, Drummond Reed

Our Robot Overlords are scribing.
Mike Prorock: 
  https://lists.w3.org/Archives/Public/public-credentials/2022Apr/0027.html
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: https://www.w3.org/community/credentials/join
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:   You have everything said.
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.
Shawn Butterfield:  I'll take you up on that.
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:  Intros new to the group folks.
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> W3C CCG Digital Wallet Protocols Analysis 
  https://docs.google.com/document/d/139dTcWp28LePAQjrA1uXVy4d154B22Y2d-vn5GvIaec/edit#heading=h.wkav55i452ux
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:   Started exploring.
<manu_sporny> W3C CCG CHAPI Security Model 
  https://docs.google.com/document/d/1DavP0nFut41BZ3jNDyIECUEamSuqhbR0vkMTK96bc4s/edit#
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:   WACI correctly.
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.
Mike Prorock:  I've got that covered for you so.
<orie> Excited for this
Manu Sporny is scribing.
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.
Juan Caballero: +1
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.
<orie> This is what Open API is https://swagger.io/specification/
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.
Mike Prorock: +1 Orie
<orie> This is what DIDComm is 
  https://identity.foundation/didcomm-messaging/spec/
<bumblefudge> swag me, dawg
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.
<orie> only the coolest bro's have swagger
Juan Caballero: 
  https://identity.foundation/didcomm-messaging/spec/
Juan Caballero: https://identity.foundation/waci-didcomm/
<orie> ^ ty
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.
<orie> WACI DIDComm test vectors were merged yesterday - 
  https://github.com/decentralized-identity/waci-didcomm/pull/7
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.
Mike Prorock is scribing.
Juan Caballero: +1
Orie Steele: +1 Thank you for this presentation
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]
Lol, @heather - double scribe
<heather_vescent> I can take it Mike it you want.
<kimberly_wilson_linson> This has been enormously educational! 
  Thank you so much!
+! Thanks
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]
<jeffo_real-it> Thx All!
Juan Caballero: 
  https://www.wired.com/story/blockchain-copyright-portrait-piracy/
<bumblefudge> ^ Cool article about NFTs that came out today in 
  Wired!
<bumblefudge> 🌢🌢🌢
Received on Tuesday, 5 April 2022 21:45:59 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 April 2022 21:46:00 UTC