14:02:07 From Markus Sabadello : https://docs.google.com/presentation/d/1WbHU6wtMbZUZZbGHQc1GMa0ihrD11sfqM8AlxSQr1Ak/ 14:02:33 From Drummond Reed : ^^^link to the slides 14:03:53 From Drummond Reed : Link to the Google doc for our notes page for this session: https://qiqochat.com/breakout/2/DkUvCiojrsTzWXhDgdQLVvPXy 14:10:27 From camparra : It would be nice if Indy defaulted to did:indy and not did:sov 14:10:40 From Nathan_George : Early on we talked about having a config setting for the method name in the code — allowing a default symlink for the network that didn’t require a sub scope and then each folder name would just resolve, allowing names to be purely local 14:10:59 From Nathan_George : You could call your network did:indy:sovrin_mainnet or you could use did:sov depending on your local config 14:11:19 From Nathan_George : It doesn’t help when trying to move did:_________. Strings around though 14:11:49 From Nathan_George : Unless your config matches others’ 14:12:27 From Meeting Host : ^ both of these comments strike me as worth a hand-raise :D 14:12:42 From camparra : +1 for did:indy:________ 14:13:54 From Oliver Terbu : If indy has a unique chain ID per network, you could use that. No idea if indy does have such a concept. 14:14:19 From Andrew Whitehead : did:indy:192.168.0.100:zzz 14:14:39 From Oliver Terbu : E.g., Ethereum has that https://github.com/ethereum/EIPs/blob/master/EIPS/eip-155.md 14:14:57 From Daniel Hardman : q+ 14:14:58 From Nathan_George : If you check network hashes between interacting peers you can resolve name differences without having to enforce sameness 14:15:02 From Nathan_George : Of naming 14:17:26 From Meeting Host : thx Nathan! 14:17:59 From michakraus : q+ 14:19:57 From camparra : Indy defaults to look for this Sovrin package btw 14:21:12 From Drummond Reed : Reminder to me that I’m on the queue to talk about the persistence of a DID. 14:22:30 From Drummond Reed : Great point about differences in networks 14:22:54 From Nathan_George : Resolver as enforcer++ 14:23:45 From Nathan_George : But we can do hash compares at the protocol layer to allow resolvers to triangulate to see if they are “through the looking glass” so to speak 14:24:45 From Nathan_George : Dan++ we should be fork and merging of forks friendly 14:24:59 From Drummond Reed : Good point about thinking about other DID methods and their method specs and resolution. I don’t think anyone wants Aries wallets to only work with Indy networks. 14:26:01 From Nathan_George : Did:pokemon?? Is there a method spec that can capture and resolve all dids from other methods? 14:26:31 From Meeting Host : ^ Sam? 14:26:44 From Meeting Host : DID:un might be the exact opposite of DID:pokemon :D 14:26:47 From Sam Curren : Somebody may have said this already, but Options 1 and 2 are not mutually exclusive. We may end up with those doing both. 14:27:13 From Sam-Smith : did:un 14:27:36 From camparra : This might be a bigger fix in the code than we’re anticipating 14:27:43 From Nathan_George : Many methods also imply additional guarantees like on-ledger storage + finality 14:27:55 From Nathan_George : So mixing and matching causes mischief 14:28:02 From Sam-Smith : KERI provides a trust basis for the unique identifier prefix so Ledger not longer are the trust basis 14:28:22 From Sam-Smith : Sorry fingers not awake yet 14:29:16 From Nathan_George : If we rebel from BCovrin and form VictoriaNet, what does that mean to identifier continuity 14:29:37 From lynnbendixsen : Will whatever we choose be backward compatible? or will current DID's/schema's/cred-defs/credentials all need to be recreated? 14:29:51 From Drummond Reed : Sam, it would be helpful for folks in this session to have a basic idea of how the did:un: method will work, so that at least that concept is in the air… 14:29:54 From Nathan_George : lynnbendixsen: Noooooooo!!!!!! 14:30:02 From Sam-Smith : Cryptographic control over the prefix means that the same control establishment works for any namespace that uses that prefix. 14:30:07 From camparra : ' 14:30:15 From camparra : +1 for Lynn 14:30:44 From camparra : This is great and all but we’re talking what ifs and not implementations 14:31:00 From Nathan_George : Sam-Smith: that statement is simple enough to be dangerously profound. I hope we don’t gloss over why that naming control matters so much. 14:32:21 From Nathan_George : Lynnbendixsen: meaning reissuing old credentials is hard, and we should work with what we have and improve from there 14:32:23 From Meeting Host : that was sam curran! 14:32:38 From Sam-Smith : DID:Un does not exist yet. But the trust basis for DID:UN is based on Key Event Receipt Logs (KERLs) A set of witnesses provides these Logs. A special case is the witness set is a ledger. So an Indy ledger may be the witness. But KERI allows the controller to rotate its witness set, so at some point in the future could rotate to a new witness that is a different Indy Ledger 14:32:48 From rouven : > Resolver as enforcer -> what would that mean for the trust model on the resolver? 14:33:43 From camparra : Thinks about recreating 5 million credentials again *twitches* 14:33:46 From Sam-Smith : @Nathan_George I like being dangerously profound. 14:34:00 From Drummond Reed : :-) 14:34:01 From Markus Sabadello : Definition of DID method in the DID spec: https://w3c.github.io/did-core/#dfn-did-methods 14:34:09 From Sam-Smith : =;) 14:34:45 From vinomaster : +1 Sam-Curren 14:35:02 From Meeting Host : DID:GDPR 14:35:38 From Kyle Den Hartog : “must be implemented to work with a specific verifiable data registry” implies it’s supposed to be technology only which is how my original assumption was influenced by 14:36:31 From Sam Curren : could be, if option 2 folks enable the technical links required by option 1. 14:36:36 From Sam-Smith : @Nathan_George Yes in a DID world where the DID method in the namespace determines the trust basis then security becomes dependent on secure resolution of the method to produce any verifiable data. 14:36:48 From Drummond Reed : +1 14:37:50 From vinomaster : +1 Keith-smith … DID namespace needs to include “env” 14:37:57 From Sam-Smith : In a world where control establishment of the crypto prefix is end-verifiable and then any verifiable data is likewise end verifiable. The system design goal is to deliver end-verifiability. 14:38:14 From Drummond Reed : +1 to the secondary namespace being specified in an abstract Indy DID method 14:38:50 From Nathan_George : Sam-Smith++. This is why ultimately what code changes we make decide this. We can’t be too abstract here or we pontificate in a way that doesn’t impact real security or use. 14:41:43 From Sam Curren : Let the right number of cats out of the bag :) 14:41:43 From Kyle Den Hartog : Seems fair of an assumption 14:44:06 From camparra : It’s already really hard to rebrand indy 14:44:20 From camparra : Try getting rid of the sovrin name in the code base 14:46:27 From Drummond Reed : It’s true that the two options are not mutually exclusive 14:46:41 From rouven : Network of networks -> sounds like shards in Ethereum. Maybe we should all use the Beacon chain as registration layer for all shards ... 14:46:41 From Dave McKay : Could we do a straw poll 14:47:10 From Kalyan Kulkarni : I guess yes No 14:47:58 From Kyle Den Hartog : Would be good to get a sense of strong no’s for them as well if we could 14:48:16 From Lal Chandran (iGrant.io) : yes 14:51:12 From Jan Lindquist : yes 14:53:11 From Kyle Den Hartog : +1 14:53:18 From Kyle Den Hartog : To revisit over more discussions 14:53:27 From Jan Lindquist : could there be a universal DID across all type of networks and not only Indy? option 3 14:54:16 From Drummond Reed : Jan, yes, that’s Sam Smith’s KERI proposal for did:un: 14:54:16 From Kyle Den Hartog : For those strongly opposed would it be possible for us to know their objections like we do in the w3c? 14:55:06 From Meeting Host : 6% of us had strong objections! 14:55:27 From Jan Lindquist : did:un is a good option just to note for future consideration 14:55:30 From Meeting Host : https://indy-interop.qiqochat.com/breakout/2/DkUvCiojrsTzWXhDgdQLVvPXy 14:55:34 From Meeting Host : ^ notes for this session 14:55:56 From rouven : 6% of people on the call, or 24% of people who used buttons overall ;)