00:02:44 Manu Sporny (Digital Bazaar): https://docs.google.com/document/d/1wbaBx8p9Xe35IT4Lk4MnXAqzZ_ja68-9w7N8zkrCYvc/edit# 00:03:08 Manu Sporny (Digital Bazaar): https://docs.google.com/document/d/1wbaBx8p9Xe35IT4Lk4MnXAqzZ_ja68-9w7N8zkrCYvc/edit# 00:05:49 Evan Tedesco: https://xkcd.com/927/ 00:06:08 Kaliya Identity Woman: can you post the google document link again 00:06:40 Manu Sporny (Digital Bazaar): https://docs.google.com/document/d/1wbaBx8p9Xe35IT4Lk4MnXAqzZ_ja68-9w7N8zkrCYvc/edit# 00:06:58 Manu Sporny (Digital Bazaar): https://lists.w3.org/Archives/Public/public-credentials/2019Nov/0082.html 00:07:14 bbarnhill: Good afternoon everyone, this is Bill Barnhill 00:08:07 rhiaro: isn't a google doc bad enough? D: 00:09:50 Christopher Allen: Are we using an IRC channel? 00:10:04 Stephen Curran: No 00:10:19 Christopher Allen: So only this chat? 00:11:15 Dave Longley: yes, only this chat and the google doc above for scribing 00:11:17 Kim Hamilton Duffy: correct 00:16:31 Manu Sporny (Digital Bazaar): correct 00:19:58 Kim Hamilton Duffy: If you’re just joining, please add yourself to the list of attendees: https://docs.google.com/document/d/1wbaBx8p9Xe35IT4Lk4MnXAqzZ_ja68-9w7N8zkrCYvc/edit# 00:20:12 Kim Hamilton Duffy: That’s also where notes are being kept 00:20:42 Orie Steele (Transmute): https://www.hyperledger.org/blog/2019/07/23/rhythm-and-melody-how-hubs-and-agents-rock-together 00:21:45 Kim Hamilton Duffy: Minutes/recording of last CCG call where this was discussed (+Adrian’s presentation comparing approaches): https://w3c-ccg.github.io/meetings/2019-11-12/index.html 00:24:40 Stephen Curran: That's not what Sam said - DIDComm/Messaging is the lower level. 00:24:49 Stephen Curran: That enables storage 00:25:18 Orie Steele (Transmute): q+ to discuss can we maybe agree on a place to continue the discussion the storage layer in a single community location 00:25:25 Orie Steele (Transmute): first 00:25:36 Juan Caballero: +1 00:26:44 Kim Hamilton Duffy: Stephen, I think the gist of his point remains (i.e focus on storage), but q+ yourself if you feel that affects the outcome 00:28:22 Adrian Gropper: We should not scope down to “personal” data stores 00:28:29 Christopher Allen: Are there any other communities represented? Soldi, IPFS, etc? 00:28:47 KD: I’m not able to edit/add to minutes, would someone please add me to minutes: Katryna Dow, Meeco 00:29:02 Daniel Buchner: Folks who work with IPFS are on the call 00:29:15 Christopher Allen: I mean people from Protocol Labs. 00:29:15 Kim Hamilton Duffy: Will do Katryna, thanks for joining! 00:30:05 Kaliya Identity Woman: I added you Katryna 00:30:05 KD: also it’s 4:00am here, it’s brutal call time, if this will be regular I wonder if Australasia could be considered 00:30:07 Christopher Allen: I know I’m hoping that we can still support distributed/shared data stores 00:30:31 Sam Curren (TelegramSam): q+ to propose that the storage protocols are based on DIDComm protocols. This limits the scope of what this group is working directly on. 00:30:38 Orie Steele (Transmute): makes sense, lets proceed to narrow scope. 00:30:40 jonnycrunch: q+ to voice concern on initial focus 00:31:13 Kim Hamilton Duffy: @KD that’s brutal. This isn’t meant to be a regular time, and I agree that ongoing times should be Australasia aware/friendly 00:31:18 Michael: The scoping/priorities should a community based discussion ...not accomplishable in this single call 00:31:30 Christopher Allen: Where are people seeing the queue? 00:31:31 Dan Burnett: Everyone, please queue rather than jumping in. Looks like most folks are doing this, which is good. 00:31:53 John Jordan: personal = “entity that can exercise control” type thing perhaps Adrian (E.g. human, legal entity (which are humans anyways :)) 00:32:31 bbarnhill: +1 for focus on storage protocols, and being transport agnostic. 00:32:46 Robert Mitwicki: q+ regarding scope of the work and the data layer 00:33:21 Michael: Let's start by placing all of the related topics on the table ...a traditional brainstorming/analysis/synthesis approach 00:33:28 bbarnhill: You can do a raise hand on zoom as a queue too 00:33:49 Thomas Hardjono: Independent of *where* the work is to be done, is the goal to produce standards specifications ? 00:34:09 Christopher Allen: q+ to discuss my own need on scope of capabilities permissions, and not getting in way of sharded solutions. 00:34:29 Dan Burnett: bbarnhill, raise hand doesn't track order 00:34:41 Daniel Buchner: The key items, imo, are these: multi-recipient encrypted objects/attachments, OCap/permissions integrated, and ability to sync datastore state 00:35:25 John Jordan: adding to Daniel B ... portability of the store 00:35:29 Daniel Buchner: Q+ to highlight scope 00:35:36 Dave Longley: I'd like to see the scope be: Storage of data encrypted in transit and at rest, at least one interface to the storage, and another layer for authorization (capabilities, etc.) 00:35:37 Michael: How is it being decided that "X is outside the scope"? ...we're only hearing a single person making these determinations so far on this call 00:35:43 Adrian Gropper: q+ 00:35:43 Daniel Buchner: Sync infers portability 00:36:00 John Jordan: right ... got it 00:36:37 jonnycrunch: +1 to cryptographic facilitated ACL via OCAP using the DID spec. 00:36:55 Orie Steele (Transmute): +1 to cryptographic facilitated ACL via OCAP using the DID spec. 00:37:17 Kim Hamilton Duffy: @Thomas: ultimately that’s the goal. Because we have concerns about clean IP (IP release) of discussions/artifacts leading into standards groups, we need to make sure we discuss this in a “safe place”, hence this discussion 00:37:21 Manu Sporny (Digital Bazaar): q+ 00:37:29 John Jordan: not sure DID spec is the right layer .. OCAP more of a verifiable credentials like capability 00:37:30 Thomas Hardjono: @Kim: thanks 00:38:02 Dan Burnett: @Michael: Please feel free to get on queue to argue why something Manu thought not related to the stated topic of the call actually is 00:38:12 Thomas Hardjono: This is what I’m hearing: 00:38:13 Thomas Hardjono: (a) Data at rest protection; (b) Secure transport protocol (for data on the move); (c) Access control (permissions) to object; (d) Legal framework for data access. 00:38:17 Kim Hamilton Duffy: @Michael: no one is allowed to decide out of scope. Manu’s just saying his opinion, which is only that 00:38:42 Thomas Hardjono: Without (d), consumer won’t let you access their data. 00:39:01 Kim Hamilton Duffy: Thomas, can we get you on the q? This is an interesting point 00:39:22 Dmitri Zagidulin: @Thomas - d (legal framework) is supremely important, but may be out of scope for this group (which is primarily engineers / implementers) 00:40:18 Michael: @Kim: Many is oversteering 00:40:21 Thomas Hardjono: Similar to Identity legal framework, the technical architecture feeds into the legal contracts. But the the regulatory limitations may limit what engineers is allowed to do on personal data. 00:40:23 John Jordan: +1 to Thomas’s comment ... the paired nature of technology and governance is critical to trust ... which we have begun to try and describe here https://github.com/hyperledger/aries-rfcs/blob/master/concepts/0289-toip-stack/README.md 00:40:42 John Jordan: PRs and Github issues welcome on the doc above 00:41:05 Joe: q+ to add operations (including queries) to the list of things to be specified 00:41:05 Daniel Buchner: If we stay object-centric with the permission/sync values encapsulated in the stored objects themselves, transports and underlying database agnosticism becomes much easier 00:41:19 Sam Curren (TelegramSam): q+ 00:42:42 Daniel Buchner: Imo, we do need to have some certainty around the actual encryption scheme used for the multi-recipient features of the protocol, vs open ended 00:42:54 Dan Burnett: Governance good to be aware of but varies by region. IETF tries to stay out of it for that reason. 00:43:07 Robert Mitwicki: +computation on encrypted data 00:43:20 Daniel Buchner: Q+ for querying comments 00:43:47 John Jordan: +1 to Daniel Burnett .. the Trust over IP is a way of talking about governance aligned with the tech layer .. it is not in and of itself a governance framework 00:44:09 John Jordan: its meta :) 00:44:14 Tobias Looker: Q+ 00:44:50 Joe: q+ about scope vis-à-vis queries 00:44:59 Dmitri Zagidulin: q+ re querying vs sync 00:46:14 Orie Steele (Transmute): agree 00:46:27 Manu Sporny (Digital Bazaar): q+ 00:46:40 Kim Hamilton Duffy: +1 00:46:50 Dave Longley: +1 where will IPR be clean and so on -- focus on that. 00:46:56 Orie Steele (Transmute): we are getting lost in the details, we need a place to continue the discussion with proper protections 00:47:08 Dan Burnett: +1 Orie 00:47:15 Dave Longley: +1 to Orie 00:47:19 Kim Hamilton Duffy: q+ to ask about Manu’s proposal 00:47:39 Kim Hamilton Duffy: Q- 00:48:09 Daniel Buchner: If we don't know if this should be IETF, W3C, etc., would folks be OK doing the emerging spec work in DIF, then transferring the spec to whichever SDO we feel is best for what we end up with? 00:48:58 Thomas Hardjono: For DIF, can an individual person join? 00:49:19 Rouven Heck: @Thomas - yes 00:49:27 Thomas Hardjono: Is it expensive :-) 00:49:31 George Aristy: +1 to starting with submissions to DIF while we get going with IETF and/or W3C 00:49:55 Thomas Hardjono: IETF is free, but need to pay attendance at events 00:50:01 Adrian Gropper: q+ 00:50:03 Thomas Hardjono: W3C is $2K minimal 00:50:05 Dave Longley: I would prefer to see some portion of the work at CCG for IPR protections, etc. 00:50:13 Dave Longley: W3C CCG is free 00:50:19 Adrian Gropper: What is data at rest protection vs. access control 00:50:20 Joe: Btw, CCG is open to the public without fee 00:50:23 Manu Sporny (Digital Bazaar): PROPOSAL: The communities involved in this discussion have decided to collaborate on a specification for a foundational layer for personal data stores, specifically a data model, syntax, data at rest protection, CRUD API, secure transport protocol, access control, and minimum viable HTTP-based protocol. 00:50:25 Kim Hamilton Duffy: Rouven — great, I didn’t realize we sorted that already. what is the cost for an individual?or is this the free-for-certain-working-groups thing? 00:50:30 Daniel Buchner: DIF has the same IPR protection as W3C 00:50:32 Rouven Heck: @Dave - we have the same IPR protection in DIF 00:50:34 Dan Burnett: Thomas, all decisions are made by email. Many people NEVER go to meetings (and are successful contributors/participants) 00:50:46 Daniel Buchner: In fact, it uses the same IPR policy 00:51:04 Thomas Hardjono: @Adrian: yes that’s correct 00:51:18 Kim Hamilton Duffy: @Daniel — is that already in effect? (Asking because we just discuss on the SC yesterday and didn’t realize the process was underway) 00:51:19 Thomas Hardjono: Access control is separate from backend data protection 00:51:48 jonnycrunch: edit: PROPOSAL: The communities involved in this discussion have decided to collaborate on a specification for a foundational layer for personal data stores, specifically a data model, syntax, data at rest protection, CRUD API, secure transport protocol, access control, and minimum viable HTTP-based interface. 00:51:58 Daniel Buchner: Ironically, DIF having a legit IPR scheme is why it hasn't been completely 'open', because we were trying to be ipr compliant 00:52:03 Kim Hamilton Duffy: Re my DIF questions, this would be wonderful, just trying to tease apart what’s available now vs future. 00:52:08 Dave Longley: +1 to the proposal 00:52:14 Orie Steele (Transmute): +1 to proposal 00:52:15 Brent Zundel: q+ 00:52:34 Dave Longley: "HTTP-based protocol" => "HTTP-based interface" was johnny's edit 00:52:39 Dave Longley: which is fine, IMO 00:52:45 Dmitri Zagidulin: +1 00:52:55 Daniel Buchner: Kim: we've always used W3C as the IPR policy (it's in the WG charters) 00:53:15 Rouven Heck: @Kim - the ‘DIF feedback agreement’ is a CLA in the existing JDF framework that allows individuals to join conversations with IPR protection 00:53:17 Joe: q+ about transport 00:53:22 John Jordan: I am also confused about the addition of transport 00:53:22 Thomas Hardjono: Should support transport above IP and below IP 00:53:25 Manu Sporny (Digital Bazaar): q+ 00:53:48 Daniel Buchner: Agree w/ Joe 00:53:51 Dave Longley: "secure transport protocol" does seem out of scope, but there must be some way to .... yes what Joe said. 00:54:03 George Aristy: re: proposal - what is the "personal" modifier for in the term "personal data store"? 00:54:06 Brent Zundel: I agree with Joe 00:54:19 Kim Hamilton Duffy: @Daniel: ok that’s good to know. I guess the distinction is the fact that CG calls are open to the public and therefore we have to badger people about it every call 00:54:24 Daniel Buchner: We were able to get comfortable with the general JWE-esque wrapper EDV uses 00:54:29 bbarnhill: edit: PROPOSAL: The communities involved in this discussion have decided to collaborate on a specification for a foundational layer for personal data stores, specifically a data model, syntax, data at rest protection, CRUD API, a transport-agnostic secure data activity transfer protocol with an example HTTP binding, access control, and minimum viable HTTP-based interface. 00:54:33 Thomas Hardjono: “personal” means that person as joint legal rights to the raw data 00:54:35 jonnycrunch: q+ 00:54:38 John Jordan: storage should not be locked into a transport that puts personal agency of users at risk 00:54:40 Joe: q+ 00:54:43 Dave Longley: George: I think the idea is that the data *may* be sensitive/personal data and the design should account for that 00:55:20 Thomas Hardjono: Example: I am allowed to get a copy of my credit card transactions data (and so does the Issuing bank) 00:55:30 Brent Zundel: edited PROPOSAL: The communities involved in this discussion have decided to collaborate on a specification for a foundational layer for personal data stores, specifically data models for storage and transport, syntax, data at rest protection, CRUD API, access control, and minimum viable HTTP-based protocol. 00:56:24 Daniel Buchner: Thomas: in our view, you'd permit them to write to your hub/pds node(s), and it would be sync'd to them all 00:56:32 Dave Longley: seems fine to me 00:56:37 Daniel Buchner: Then you'd have it and do with it what you want 00:57:10 Dave Longley: PROPOSAL: The communities involved in this discussion have decided to collaborate on a specification for a foundational layer for personal data stores, specifically data models for storage and transport, syntax, data at rest protection, secure CRUD API, access control, and minimum viable HTTP-based interface. 00:57:10 Adrian Gropper: q+ 00:57:15 Daniel Buchner: Didn't see sync/replication? 00:57:22 Thomas Hardjono: @Daniel: Unfortunately many “data providers” guard their data jealously :-) 00:57:27 Daniel Buchner: In the proposal 00:57:41 Joe: The communities involved in this discussion have decided to collaborate on a specification for a foundational layer for personal data stores, specifically data models for storage and transport, syntax, data at rest protection, secure CRUD API, access control, and minimum viable HTTP-based protocol interface. 00:57:41 Kim Hamilton Duffy: Is Bill Barnhill’s edit worked in? 00:57:56 Dave Longley: PROPOSAL: The communities involved in this discussion have decided to collaborate on a specification for a foundational layer for data storage (including personal data), specifically data models for storage and transport, syntax, data at rest protection, CRUD API, access control, and minimum viable HTTP-based protocol. 00:58:00 Thomas Hardjono: @Adrian: subject data 00:58:01 Rouven Heck: identity centric data stores? 00:58:12 Thomas Hardjono: “Subject” is what GDPR uses 00:58:18 John Jordan: -1 to Identity 00:58:22 Dave Longley: PROPOSAL: The communities involved in this discussion have decided to collaborate on a specification for a foundational layer for data storage (including personal data), specifically data models for storage and transport, syntax, data at rest protection, secure CRUD API, access control, and minimum viable HTTP-based interface. 00:58:25 Joe: q+ 00:58:26 Rouven Heck: GRDP = just individuals 00:58:26 Dmitri Zagidulin: +1 to @Daniel’s question ‘what about sync' 00:58:36 Orie Steele (Transmute): +1 to proposal 00:58:40 Joel Hartshorn: +1 00:58:41 Dave Longley: +1 to proposal 00:58:47 Liam Broza: +1 00:58:51 Manu Sporny (Digital Bazaar): +1 to proposal 00:58:51 Dmitri Zagidulin: +1 to proposal. (esp. if we add 'sync') 00:58:59 Thomas Hardjono: +1 to participate, depending on cost 00:59:00 Tobias Looker: +1 to proposal 00:59:04 Brent Zundel: +1 00:59:07 Evan Tedesco: +1 to proposal. 00:59:10 Ken Ebert: +1 00:59:12 Dan Burnett: +1 to proposal 00:59:15 Adrian Gropper: q+ 00:59:30 Adrian Gropper: q+ to worry about sync 00:59:42 George Aristy: I suggest s/access control/authorization/ 00:59:52 Daniel Buchner: If you can't sync, you can't know what the state of your datastore is 01:00:03 Dave Longley: PROPOSAL: Add syncing data and "secure" to "data storage" to the proposal. 01:00:07 Daniel Buchner: Which means there's no truth in state 01:00:08 Brent Zundel: I think the sync could be considered part of the data model for transport 01:00:09 Thomas Hardjono: Isn’t “sync” part of securing data-on-the-move? 01:00:15 John Jordan: sync = transport + appropriate access? 01:00:16 Dan Burnett: Will solutions for individuals be different from solutions for corps? 01:00:16 Christopher Allen: If DID then maybe they are self-sovereign data stores, as we’ve already said that enterprises can use self-sovereign architectures. 01:00:27 Daniel Buchner: Sync is about correctness of state 01:00:38 Ken Ebert: +1 to consider syncing 01:00:44 bbarnhill: Authoritative data stores? I.e., a store of data for an entity where that entity is the primary authority over the lifetime of that data. 01:00:46 Dmitri Zagidulin: @Thomas re ‘isn’t sync securing data on the move’ - not quite. TLS secures data on the move, but sync (and version control) are on several layers above that 01:00:47 Orie Steele (Transmute): sync = access control + crud api 01:00:48 Robert Mitwicki: q+ data model vs semantic? 01:00:51 Thomas Hardjono: @Daniel: Thx 01:00:53 Daniel Buchner: Q+ 01:01:04 Dmitri Zagidulin: @Orie plus version control, tho 01:01:04 luca boldrin - infocert: would the storage deal both with "data" and "attestations about data"? They are possibly two differnent objects 01:01:09 Kaliya Identity Woman: the term “self-sovereign” is inherently alienating to key stakeholders who are good to involve in the work. 01:01:15 Christopher Allen: q+ 01:01:27 George Aristy: Kaliya - agreed. 01:02:07 Manu Sporny (Digital Bazaar): q+ 01:02:20 Dmitri Zagidulin: +1 to concern over sync. 01:02:25 Dave Longley: Robert Mitwicki: I think we're not talking about the semantics for the actual data you store (we should support arbitrary data), but the semantics for any encapsulating containers around that data. 01:02:49 Kim Hamilton Duffy: we don’t have to work this into the proposal now, but I do like grounding our terminology in GDPR language. We are doing this in Digital Credentials Consortium (even though it’s not an exclusively European effort) because it makes data architecture (and compliance implications thereof) much easier. 01:02:51 Rouven Heck: +1 re. sync is critical for censorship resistance 01:02:56 Brent Zundel: +1 to Daniel's point 01:02:58 Kaliya Identity Woman: I support including sync in the proposal - it provides protection for people to prevent locking. 01:03:02 Kaliya Identity Woman: lockin. 01:03:14 Dan Burnett: Agree with Kaliya re SSI, but we have to remember why we are doing this work; it's not primarily to provide better storage options for corporate data 01:03:42 Evan Tedesco: @luca I think attestations are grouped under the read in crud. 01:03:42 Adrian Gropper: +1 @Chris for SSI-compatible 01:03:45 John Jordan: so sync is a bit of a compound construct .. ability to maintain integrity of data stor 01:03:52 Dave Longley: +1 absolutely should be compatible with SSI/DIDs. 01:04:16 Dan Burnett: Compatibility with DIDs / VCs is an "of course", I think 01:04:22 Pamela: Could we re-post the proposal please? 01:04:22 Dave Longley: +1 to Dan Burnett 01:04:38 Ken Ebert: Repost please. 01:04:41 mo (schluss.org): +q Side discussion: I find the discussion between "corporate data" and personal data very confusing. Corporation might use data about people, but I don't understand what you mean with corporate data? 01:04:45 Kim Hamilton Duffy: +1 to Dan. thought that was why we were here. But worth repeating 01:04:48 Tobias Looker: +1 to SSI and DID compatibility 01:04:48 Dave Longley: This was the proposal people +1'd... PROPOSAL: The communities involved in this discussion have decided to collaborate on a specification for a foundational layer for data storage (including personal data), specifically data models for storage and transport, syntax, data at rest protection, secure CRUD API, access control, and minimum viable HTTP-based interface. 01:04:48 Daniel Buchner: With sync in, sounds great 01:05:14 mo (schluss.org): +1 proposal 01:05:17 mike.varley (SecureKey): Gotta quit +1 I like the first proposal 01:05:18 Robert Mitwicki: yep make sens, but there is much more into it then we could think of, moving data as a bytes does not empower decentralized data economy as we would like to. Google provides possibilities to extract the data but does that mean that this is enough? 01:05:19 Thomas Hardjono: Looks good. +1 01:05:25 Ken Ebert: with sync +1 01:05:27 George Aristy: With sync and DIDs: +1 01:05:28 Tobias Looker: +1 01:05:36 Dave Longley: PROPOSAL: Add sync support and "secure" to "data storage" description in the proposal. Make SSI/DID/VC compatible, etc. 01:06:03 Orie Steele (Transmute): without objection 01:06:05 Kim Hamilton Duffy: +1 01:06:07 Orie Steele (Transmute): +! 01:06:07 Tobias Looker: +1 01:06:07 Daniel Buchner: +1 01:06:08 Ken Ebert: +1 to dave’s enhancement 01:06:08 Adrian Gropper: +1 01:06:08 Christopher Allen: +1 01:06:08 Dmitri Zagidulin: +1 01:06:08 mo (schluss.org): +1 01:06:09 Rouven Heck: +1 01:06:09 Dave Longley: +1 01:06:10 luca boldrin - infocert: main difference between data and attestation is the ownership: data belongs to mr (i might be remunerated for my data) while attestations belong to issuer (issuer might be remunerated) 01:06:11 Manu Sporny (Digital Bazaar): +1 01:06:12 Sam Curren (TelegramSam): +1 01:06:13 John Jordan: +1 01:06:13 Markus Sabadello: +1 01:06:14 bbarnhill: +1 01:06:14 Dan Burnett: +1 01:06:15 Jonathan Reynolds: +1 01:06:15 jonnycrunch: q+ “to add portability” 01:06:16 Robert Mitwicki: +1 01:06:16 Joachim Lohkamp: +1 01:06:18 Brent Zundel: +1 01:06:18 Evan Tedesco: +1 01:06:27 luca boldrin - infocert: +1 01:06:28 Thomas Hardjono: +1 to Data Protability 01:06:35 Kayode Ezike: +1 01:06:43 Rouven Heck: +1 to data portability 01:06:52 Dave Longley: +1 to data portability ... but I thought that was built in already :) 01:06:59 Kim Hamilton Duffy: Same… 01:07:00 Dave Longley: (to the proposal) 01:07:03 Pamela: Can we see the entire proposal please 01:07:07 Daniel Buchner: Sync implies portability 01:07:13 Tobias Looker: Same I thought it was implied via sync 01:07:16 Robert Mitwicki: it does not 01:07:19 Manu Sporny (Digital Bazaar): PROPOSAL: Each community contributing work to the effort can, at any time, withdraw from the effort and/or continue to work on their draft in their own community. 01:07:27 Daniel Buchner: If you add a new instance to your DID doc, it'll sync/port automatically 01:07:27 Robert Mitwicki: sync you can with silo as well 01:07:37 Daniel Buchner: Or should, I'd argue 01:07:41 Dmitri Zagidulin: @Pamela - did you mean the original proposal, or this second one? 01:07:44 bbarnhill: +1 01:07:47 Adrian Gropper: +1 01:07:47 Robert Mitwicki: +1 01:07:47 Dmitri Zagidulin: +1 01:07:48 Manu Sporny (Digital Bazaar): +1 01:07:49 Orie Steele (Transmute): +1 01:07:49 Joachim Lohkamp: +1 01:07:50 John Jordan: +1 01:07:51 Tobias Looker: +1 01:07:51 Sam Curren (TelegramSam): +1 01:07:52 Ken Ebert: +1 01:07:54 Stephen Curran: +1 01:07:55 Kayode Ezike: +1 01:07:56 Evan Tedesco: +1 01:07:57 Markus Sabadello: +1 01:07:57 Dan Burnett: +1 01:07:59 Rouven Heck: +1 01:08:02 Kaliya Identity Woman: +1 01:08:03 Brent Zundel: +1 01:08:10 Pamela: I would love to see all the proposals, shared on the screen, rather than scrolling across 10% of my window :-D 01:08:31 Dave Longley: Resolved above proposal is: The communities involved in this discussion have decided to collaborate on a specification for a foundational layer for secure data storage (including personal data), specifically data models for storage and transport, syntax, data at rest protection, secure CRUD API, access control, a minimum viable HTTP-based interface, sync support, and with SSI/DID/VC compatibility. 01:08:47 Sam Curren (TelegramSam): q+ to talk about location of DIDComm 01:09:13 Dmitri Zagidulin: @Pamela - I think the google doc with the notes is the best bet, for seeing the proposals at once - https://docs.google.com/document/d/1wbaBx8p9Xe35IT4Lk4MnXAqzZ_ja68-9w7N8zkrCYvc/edit# 01:10:07 Daniel Buchner: What does adding as an input doc mean? 01:10:08 Rouven Heck: q+ - re input documents vs. ongoing work 01:10:17 Kim Hamilton Duffy: q+ 01:10:18 Daniel Buchner: Just something to kickoff discussion? 01:10:53 Thomas Hardjono: Is there an overarching Architecture Spec? 01:11:12 Thomas Hardjono: (somewhere) 01:11:33 Manu Sporny (Digital Bazaar): q+ to respond to Rouven 01:12:04 Adrian Gropper: q+ don’t assume DIDcom 01:12:13 Robert Mitwicki: didcomm should not impact data storage it can be use but not needed 01:12:22 Daniel Buchner: Something like DID Comm needs to exist, I think that's implied, but do we name DID Comm specifically as the thing? 01:12:28 Daniel Buchner: That seems to be a valid question 01:12:52 Adrian Gropper: q+ I worry a lot about postponing this 01:12:55 John Jordan: q+ we allow these efforts to evolve in parallel 01:13:15 Daniel Buchner: +1 to start by naming the generic need, and align/rely on things as much as we can 01:13:19 Rouven Heck: @Manu - fair enough, question clarified. 01:14:30 Daniel Buchner: Maybe we just list as a product requirement the need for a DID compatible envelope that includes multi-recipient capabilities? 01:14:56 Rouven Heck: +1 to Johns point 01:15:09 Daniel Buchner: It infers something like DID Comm without making it a waterfall blocker 01:15:20 Tobias Looker: +1 to johns point 01:15:27 Orie Steele (Transmute): +1 to johns point 01:15:33 Dmitri Zagidulin: +1 to john’s point 01:15:33 Sam Curren (TelegramSam): +1 john's point. 01:15:36 Dan Burnett: +1 to Daniel B / John J 01:15:37 Robert Mitwicki: +1 to John's point 01:15:37 Daniel Buchner: +1 01:15:43 Joe: +1 to parallel in sync 01:16:22 Sam Curren (TelegramSam): +1 01:16:25 Orie Steele (Transmute): +1 01:16:29 Daniel Buchner: +1 to that 01:16:52 bbarnhill: As input, the Peer DID Method spec seems to have a good balance regarding DIDComm as discussed but not required: “Work on this spec grew out of work on DIDComm, which is the basis of many JSON-message-based protocols that take advantage of DID-based encryption and privacy. However, using DIDComm is not the only way to build a protocol. Therefore, this spec presents a general recipe for creating, reading, updating, and deactivating DIDs, and then specifies how that recipe manifests specifically in a DIDComm variant.”- https://openssi.github.io/peer-did-method-spec/index.html 01:17:01 Rouven Heck: Pelle needed to drop - uPort is planning to donate little different approach as well to DIF very soon. 01:17:03 George Aristy: DIDComm already covers the "secure data in movement" requirement of the proposal. It also adds pseudoanonymity, which minimizes risks of correlation by third parties. 01:17:37 Dmitri Zagidulin: @Rouven - different approach to which - to DIDComm, or this overall storage spec? 01:17:44 Manu Sporny (Digital Bazaar): PROPOSAL: The Identity Hubs and Encrypted Data Vaults documents willb e used as use case, requirements, and technical input for the collaborative effort. The DID Comm work will continue in parallel in DIF and is acknowledged as important related work. 01:17:51 Rouven Heck: storage approach - focussed on VCs 01:18:08 Daniel Buchner: +1 01:18:10 John Jordan: +1 01:18:11 Tobias Looker: +1 01:18:12 Orie Steele (Transmute): +1 01:18:13 Kim Hamilton Duffy: I don’t think “important” should be in there but I won’t die on that hill 01:18:14 Adrian Gropper: q+ 01:18:14 Stephen Curran: +1 01:18:16 Joe: +1 01:18:16 Evan Tedesco: +1 01:18:16 Dan Burnett: +1 01:18:16 jonnycrunch: q+ 01:18:20 Christopher Allen: +1 01:18:23 Joachim Lohkamp: +1 01:18:24 Oliver: q+ how about other work? 01:18:25 Dave Longley: +1 ... i expect other specs might come in and layer things like zcaps. 01:18:32 Ken Ebert: +1 01:18:40 Thomas Hardjono: +1 for UMA 01:18:42 Joe: +1 to UMA as related spec 01:18:52 Kim Hamilton Duffy: +1 to UMA too 01:18:52 Dmitri Zagidulin: +1 to UMA (2, specifically) 01:18:52 Tobias Looker: +1 to ZCAPs being related 01:18:54 Robert Mitwicki: +1 for UMA 01:18:56 Rouven Heck: question - are we also including GDPR or something like this? 01:19:17 bbarnhill: Kim Hamilton Duffy: agreed. I don’t like important in there. I see DIDComm as an example of a binding, similar to what Peer DID Method Spec described (I posted it above) 01:19:21 Christopher Allen: -1 UMA as basic, but +1 for related 01:19:21 Orie Steele (Transmute): : ( 01:19:32 Joe: q+ about UMA 01:19:35 Orie Steele (Transmute): -1 to any unclear IPR input docs 01:19:45 Tobias Looker: Agree with Orientalists 01:19:54 Dave Longley: -1 to any unclear IPR input docs ... if that stuff can get cleared, bring it in 01:19:55 Dan Burnett: -1 to input, +1 to related 01:19:55 Tobias Looker: Ha*orie 01:20:08 Dave Longley: +1 to saying UMA is related work 01:20:12 Daniel Buchner: -1 to input, +1 to related 01:20:16 Kim Hamilton Duffy: ahhhh, I thought I was going to have to call you out for racism Tobias 01:20:17 Christopher Allen: I’m fine with UMA is an important related work. 01:20:30 George Aristy: +1 to not reinventing terms for things. UMA (and other things derived from OAuth 2.0) already defines pretty generic roles (RS, AS, RO, RP, etc.) 01:20:34 Thomas Hardjono: UMA2.0 specifically 01:20:34 Daniel Buchner: Tobias is fruit racist 01:20:40 Tobias Looker: Hahaha what an auto correct! 01:20:41 Daniel Buchner: He only likes kiwis 01:20:46 Daniel Buchner: 😂 01:20:50 Dan Burnett: @Kim, you clearly need to call out autocorrect as racist . . . 01:20:58 George Aristy: I would broaden the scope of input docs to all of OAuth 2.0, not just UMA. 01:21:02 Kim Hamilton Duffy: Autocorrect is canceled 01:21:17 Dave Longley: -1 to racism 01:21:17 Dmitri Zagidulin: -1 to OAuth 2 as input doc. 01:21:32 Kim Hamilton Duffy: -1 to autocorrect racism 01:21:33 Ken Ebert: +1 to UMA as a related document 01:21:36 Thomas Hardjono: There is already 10yrs of development on OAuth2.0, OIDC and UMA 01:21:37 Rouven Heck: Time check - 13min left, question: how do we best continue the conversation going forward? Doesn’t feel like a one-off discussion … 01:21:49 Kim Hamilton Duffy: q+ 01:21:54 Thomas Hardjono: Don’t reinvent authorization framework 01:22:00 Brent Zundel: +1 to Rouven's question 01:22:02 Markus Sabadello: Mention Solid as related work..? 01:22:10 Kim Hamilton Duffy: (q+ is to close on this section) 01:22:11 George Aristy: @Thomas - exactly. There is a DECADE of experience in OAuth2.0 and all related specs. I don't know why this is being disregarded for this effort. 01:22:47 Dmitri Zagidulin: @Thomas - I think everyone agrees there (that OIDC / OAuth2) are important. However, one, authentication is explicitly out of scope for this doc. As for authorization - the main focus is that it is pluggable / modular. Of course including OAuth2 01:22:54 Sam Curren (TelegramSam): +1 kim comment 01:22:57 Juan Caballero: 10min left-- venuetime soon? 01:23:00 jonnycrunch: still on q: https://github.com/hyperledger/aries-rfcs/blob/master/features/0036-issue-credential/README.md 01:23:04 Juan Caballero: i.e. +1 to kim 01:23:09 Dave Longley: +1 to figuring out how to pull in terminology from UMA separately 01:23:28 Daniel Buchner: Going to be hard, let's try to go fast 01:23:47 Thomas Hardjono: I think at the very least the UMA flows need to be re-used 01:23:54 Tobias Looker: +1 to Daves suggestion, use existing terminology when we can 01:23:56 KD: it’s already 05:20 in morning - 01:23:58 Thomas Hardjono: No need to copy/paste text from UMA specs 01:24:11 Daniel Buchner: Why can't we just do DIF, and do the SDO stuff after a draft? 01:24:12 Orie Steele (Transmute): we need a location… thats the only reason I am here. 01:24:16 Dave Longley: +1 to get to which standards body to put this in 01:24:20 Christopher Allen: +1 to moving along agenda. Close on input/vs/influence documents 01:24:24 KD: what time zone will you include for group? 01:24:29 Daniel Buchner: That way we don't have to have an SDO discussion right now 01:24:40 bbarnhill: W3C CCG is great, but the goal there is to transition it to W3C WG, which excludes those who’d like to contribute but cannot because they or their companies are not members. I’d push for IETF or DIF. 01:24:43 Dan Burnett: Manu, see what can happen in 9 mins 01:24:50 Kim Hamilton Duffy: +1 to Katryna’s point on time zones. 01:24:54 Daniel Buchner: DIF can export to wherever we all want 01:24:57 Thomas Hardjono: +1 for IETF & DIF 01:24:58 Adrian Gropper: stopper today 01:24:58 John Jordan: +1 to restrictive nature of W3C 01:25:07 Kim Hamilton Duffy: We should be intentional about this up front 01:25:33 Joe: CCG has work items targeted for IETF. So, yes, it is streamlined for W3C track, but it need not be. 01:25:36 Dave Longley: +1 definitely need it to go to an SDO 01:26:07 Manu Sporny (Digital Bazaar): PROPOSAL: The intent is to eventually standardize the work at W3C under W3C's Royalty-Free Patent policy. Regular calls will be hosted under the W3C Credentials Community Group under the aforementioned IPR policy. 01:26:07 Adrian Gropper: W3C or IETF 01:26:18 Daniel Buchner: IETF actually seems more logical 01:26:18 Thomas Hardjono: IETF 01:26:25 John Jordan: An open source (with a licence that is recognized by Open Source Initiative is a key outcome I believe 01:26:25 bbarnhill: +1 for IETF 01:26:27 Rouven Heck: I think DIF could be a good place for the current phase; give time to define the best place over time 01:26:30 Christopher Allen: -1 DIF as it isn’t an SDO 01:26:32 Dave Longley: +1 to proposal -- noting that parts can be moved to IETF but it's higher level than IETF. 01:26:32 Thomas Hardjono: Open to anyone. Very clear IP polocy 01:26:33 Adrian Gropper: q+ 01:26:37 Daniel Buchner: But why force us all to make that call now? 01:26:38 Christopher Allen: It could be someday, but isn’t today. 01:26:46 Juan Caballero: @rouvin - one future call to ratify/confirm/vote so that the 15 that left get a second chance? 01:26:57 Juan Caballero: +1 Daniel Buchner 01:27:03 Thomas Hardjono: Specifically, the Security Area in the IETF 01:27:04 Orie Steele (Transmute): DIF -> (W3C || IETF) 01:27:13 Sam Curren (TelegramSam): DIF -> (W3C || IETF) 01:27:17 Oliver: +1 01:27:27 bbarnhill: +1 for DIF -> (W3C || IETF) 01:27:40 Dmitri Zagidulin: +1 for DIF -> (W3C || IETF) 01:27:46 Kim Hamilton Duffy: Rouven — can you talk about openness to the public of DIF, since these changes are new? 01:27:53 Christopher Allen: q+ 01:27:55 Kaliya Identity Woman: DIF -> (W3C || IETF) 01:27:56 John Jordan: +1 to DIF -> (W3C || IETF) once there is a level of uncertainty reduction 01:28:09 Daniel Buchner: John put that nicely 01:28:19 Kim Hamilton Duffy: (I.e. I’m on DIF sc and still confused about whether DIF is open to free public participation) 01:28:21 Dan Burnett: @John, "open source" is not relevant comment for "open standards", which is our current discussion 01:28:35 Manu Sporny (Digital Bazaar): q+ 01:28:40 Kim Hamilton Duffy: q+ 01:28:50 Daniel Buchner: Kim: you can participate, just need the IPR docs and waivers all signed 01:28:52 Manu Sporny (Digital Bazaar): q- later 01:29:32 Rouven Heck: @Kim - we have the legal / IPR structure in place; yesterday we agreed to pilot the open participation with DIDComm; we could do the same to this group 01:29:36 John Jordan: @dan Burnett fair comment .. however the iterative development of code <-> spec is important I think to keep things clear and moving forward 01:29:41 Rouven Heck: q+ to Kims point 01:30:02 Dmitri Zagidulin: what is JDF? 01:30:16 John Jordan: and my interest from the public sector point of view is not only open standards but open source implementations 01:30:20 jonnycrunch: +1 DIF for more openness for community 01:30:20 Daniel Buchner: JDF is now under Linux Foundation 01:30:30 Dan Burnett: Feedback is not the same as agreeing to RF licensing. Just be careful about that. 01:30:40 John Jordan: http://www.jointdevelopment.org/ 01:30:53 Daniel Buchner: It's a lighter framework for emerging stuff that can be exported to SDOs while maintaining IPR 01:31:04 Thomas Hardjono: $100 max for individuals 01:31:14 Thomas Hardjono: With full voting rights 01:31:26 Dave Longley: we could use W3C CCG to host the specs and have joint DIF + W3C CCG calls 01:31:41 Dave Longley: W3C CCG is free and open to everyone 01:32:02 Kim Hamilton Duffy: thanks Rouven 01:32:08 Robert Mitwicki: don't get why we need to pay for giving contribution to the most important parts of new data economy. 01:32:18 Daniel Buchner: We have the CLA template 01:32:23 Thomas Hardjono: @Robert: its called capitalism :-) 01:32:31 Daniel Buchner: Correct, Rouven? 01:32:34 Robert Mitwicki: :) 01:32:46 Orie Steele (Transmute): … I agree with manu… this is not clear enough… 01:33:11 John Jordan: not sure that W3C is the end state ... 01:33:18 Daniel Buchner: Q+ 01:33:29 Tzviya Siegman: q+ to comment on IP issues of transferring from one org to another 01:33:39 Orie Steele (Transmute): only reason to start with DIF is that it would be easier than W3C… if thats not the case, there is no point in starting in DIF… 01:33:47 Christopher Allen: Corps don’t seem to be able to join DIF without membership, only individuals. 01:33:50 Adrian Gropper: Leaving the call 01:34:13 Robert Mitwicki: what is JDF? 01:34:19 John Jordan: these technologies are likely very disruptive to the incumbent members of W3C ... 01:34:22 Joe: q+ 01:34:24 Christopher Allen: q+ 01:34:26 Juan Caballero: joint devt fundn 01:34:32 Robert Mitwicki: thx 01:35:30 Thomas Hardjono: Can DIF website please show the cost of joining. https://identity.foundation 01:35:39 Juan Caballero: +1 John Jordan's argument for incubating without an SDO predetermined? 01:35:41 Thomas Hardjono: (or did I look at the wring page) 01:35:52 Robert Mitwicki: I also don't see those stuff in w3c as the idea is to disrupt what is build there 01:36:21 Dave Longley: no one stands in the way W3C CCG 01:36:28 Dave Longley: *at W3C CCG 01:36:37 KD: +1 Daniel & jurisdictional context 01:36:46 John Jordan: there is a huge public good we need to incubate here .. and we need to also work to get more public sector involved (which I would help with) 01:37:19 Kim Hamilton Duffy: q+ to complexity of corporate interests 01:37:25 Thomas Hardjono: The other option is create a new IETF Research Group (RG), as a forum 01:37:26 Dave Longley: -1 to IPR CLA mess 01:37:50 Thomas Hardjono: IETF RGs do not produce specs 01:38:20 Thomas Hardjono: https://datatracker.ietf.org/rg/ 01:38:31 Thomas Hardjono: Lots of crypto work there 01:39:06 Manu Sporny (Digital Bazaar): q+ 01:39:43 Daniel Buchner: But google/Facebook will likely fight this. I'd be shocked if they didn't 01:39:54 Kaliya Identity Woman: It is my understanding that Things can go from the CCG to some other standards body too. 01:39:56 Dave Longley: note: activitypub also came out of W3C 01:40:03 Orie Steele (Transmute): https://www.w3.org/TR/activitypub/ 01:40:05 Daniel Buchner: And if they don't, putting my Vader hat on, they're idiots 01:40:17 Kaliya Identity Woman: Which mailing list? 01:40:53 Daniel Buchner: This is 100x the threat to them as VCs 01:41:05 KD: for future calls can we consider Timezone for inclusion please? 01:41:06 Dan Burnett: @Daniel: are you saying that Google/Facebook are not allowed to join DIF? 01:41:14 Daniel Buchner: They are 01:41:20 Rouven Heck: The difference to others orgs - DIF’s mission is decentralized Identity :) 01:41:21 Daniel Buchner: But they've stayed away 01:41:33 Daniel Buchner: Which I'm kind of ok with for the time being 01:41:43 Thomas Hardjono: @Daniel: Not vader hat, but Devo hat 01:42:03 Juan Caballero: can we set an agenda for a future call 01:42:08 Thomas Hardjono: https://www.google.com/imgres?imgurl=https%3A%2F%2Fmusic.mxdwn.com%2Fwp-content%2Fuploads%2F2014%2F05%2Fdevo.jpg&imgrefurl=https%3A%2F%2Fmusic.mxdwn.com%2F2019%2F08%2F06%2Fnews%2Fdevo-reveal-plans-for-fall-2019-farewell-tour-dates%2F&docid=5LCcn3HfPxs36M&tbnid=Ihl_q8RJu54jZM%3A&vet=10ahUKEwjgqL-fu_7lAhVkhuAKHdw4AnUQMwhrKAMwAw..i&w=1224&h=768&client=safari&bih=1006&biw=1958&q=Devoi%20band&ved=0ahUKEwjgqL-fu_7lAhVkhuAKHdw4AnUQMwhrKAMwAw&iact=mrc&uact=8 01:42:48 Kaliya Identity Woman: which mailing lists there is one? 01:42:51 Daniel Buchner: Hahaah 01:42:54 Juan Caballero: ALL OF THEM 01:42:57 Kim Hamilton Duffy: Screw you Manu 01:43:05 Tobias Looker: The one mailing list to rule them all 01:43:09 Thomas Hardjono: @Thanks Manu. 01:43:13 Kaliya Identity Woman: so its our fault? 01:43:15 bbarnhill: Can we get a list of mailing lists where discussion is going on in the minutes, at least some base ones. 01:43:21 Tzviya Siegman: a meta list 01:43:23 Robert Mitwicki: thanks all 01:43:25 John Jordan: thank