09:07:54 From Stephen Curran : How many networks? Hundreds 09:11:42 From lynnbendixsen : Where will the major "burden of discovery" lie? (verifier vs did method) 09:12:37 From Stephen Curran : Was there a final answer from the first session? 09:12:56 From Meeting Host : @stephen 19vs14 for option 1 vs 2 09:13:12 From Meeting Host : notes for that session also have more details (going off the top of my head) 09:13:21 From Drummond Reed : @stephen it was a great discussion but no clear conclusion 09:13:38 From Stephen Curran : I saw the 19 to 14 -- great notes, BTW. Was that consensus? I hope so. 09:13:55 From Stephen Curran : Make it 20 to 14 by adding my vote. 09:14:03 From Drummond Reed : @stephen we agreed we needed to have these other sessions to learn more and then do another straw poll tomorrow 09:14:18 From Stephen Curran : OK 09:14:22 From Stephen Curran : Thanks! 09:14:35 From Drummond Reed : Also, we agreed the two options are not actually mutually exclusive 09:14:50 From Markus Sabadello : yes, since option 1 had some NO votes, and option 2 had no NO votes 09:16:45 From Nathan_George : I am from Kiva and I _do not_ endorse this approach ;) 09:17:43 From Meeting Host : go ahead kyle after Stephen 09:18:53 From Meeting Host : Kyle then Markus then Tomislav 09:19:08 From vinomaster : Interesting Nathan. We should discuss pros/cons. I am not convinced. We need a way to discover trusted and none trusted utilities. 09:19:57 From Drummond Reed : What? How does the identifier identify the resolver? 09:20:04 From Meeting Host to Tomislav Markovski(Privately) : Did you still want to go after Markus? 09:20:39 From Kyle Den Hartog : The domain name points to the resolver and the only way to resolve the did is by going to a public resolver which exposes the private data on the fabric network 09:20:56 From Nathan_George : Markus++ 09:21:06 From Drummond Reed : Ouch! You don’t want a DID tied to a specific resolver 09:24:34 From lynnbendixsen : What about Private Indy networks? Don't we want them to be able to run w/o a DNS requirement? 09:25:15 From vinomaster : +1 DH I have deep trust concerns over this approach. 09:25:21 From Drummond Reed : Me too 09:26:46 From Stephen Curran : Should we vote on this one to possibly eliminate it? 09:27:19 From Nathan_George : Kyle: who dat? Who is doing the fabric+sidetree thing? 09:27:22 From Kapil Singh : Are we expecting to track changes to DNS entries? Without auditabilty, trust concerns will remain. 09:27:26 From vinomaster : +1 Kyle — In secure key the 7 banks are teh root of trust. 09:27:44 From Stephen Curran : That is the SecureKey team in Trustbloc 09:27:54 From Nathan_George : thanks 09:29:09 From vinomaster : We should be advocating for a decentralized registry of trusted utilities (regardless of DID namespace). 09:30:41 From Nathan_George : I thought DIDs were _not_ supposed to be certificates 09:30:55 From Nathan_George : As soon as we reach for them for attribute binding we should have used PKIx no? 09:32:49 From Drummond Reed : Decentralized is good. But we need to ask how many Indy networks we really want to encourage. 09:33:04 From vinomaster : Good point Nathan; I think th did doc should be more for service endpoints 09:35:32 From Dave McKay : Hierarchy could break if one of the networks/documents goes away 09:37:47 From Drummond Reed : Yes. I’m personally not in favor of the hierarchical model; it doesn’t feel consistent with the purpose of DIDs 09:37:56 From Stephen Curran : Is this another we should vote on to eliminate? 09:38:08 From Stephen Curran : **possibly 09:38:35 From Kyle Den Hartog : +1 to voting to narrow 09:38:43 From Meeting Host : +1 to narrow as well 09:39:27 From Kapil Singh : Hierarchy could potentially help organic growth of networks. 09:39:34 From Nikolaos Saklampanakis : I agree there should be muliple ways to get network configs. Devil's advocate question: Why is a credential issuing org trusted more to secure his indy identity than his own domain name? 09:40:39 From Drummond Reed : @nikoloas I think the question is whether DID networks can inherently be more secure than the DNS network 09:42:43 From Drummond Reed : This feels much more like a non-hierarchical, P2P model 09:44:37 From vinomaster : Just a thought — we are using consensus algorithms to establish trust in DIDs — why wouldn’t we use the same for trusting discoverable DID namespaces? 09:45:15 From Drummond Reed : Good point. This final proposal in Daniel’s slides is the closest for doing that. 09:45:27 From Kyle Den Hartog : There’s some interesting ideas that could benefit us by doing that @vinomaster 09:47:34 From Nikolaos Saklampanakis : @Drummond I agree with you, i am only considering if DNS could/should be ONE of the ways. This zoom chat is hard to discuss it in deep :( 09:48:13 From Drummond Reed : I am supportive of DNS being ONE of the ways (just not the only one) 09:48:16 From Stephen Curran : Oh Kyle.... 09:48:42 From Nikolaos Saklampanakis : @Drummond then we are on the same page :) 09:48:42 From Kyle Den Hartog : Some nuance to my Yes here, I think we’ll see a large number of networks at first and they’ll converge to a long tail curve over time similar to what we saw with browsers at the beginning of the network 09:49:35 From Kyle Den Hartog : @Stephen I don’t intend for us to rabbit hole on this, but wanted to raise it to see if we should optimise for short term or long term 09:49:46 From vinomaster : We do not know what we do not know about the potential of this market 09:49:56 From Drummond Reed : +1 09:49:59 From lynnbendixsen : I think huge number of networks is probable, but that several will be private and not wanting to join "network of networks" 09:49:59 From Kyle Den Hartog : +1 09:50:15 From bbosch : It's a little unclear for me how to vote :/ 09:51:01 From Nathan_George : It sounded like many in the 1000+ camp were thinking about DIDs more like scoping for UUIDs, I wonder if we have some implicit requirements expectations that are buried under this poll 09:51:28 From lynnbendixsen : +1 Nathan 09:55:34 From Dave McKay : Good for learning/testing 09:55:40 From Drummond Reed : +1