17:26:09 RRSAgent has joined #did 17:26:09 logging to https://www.w3.org/2020/01/17-did-irc 17:26:11 RRSAgent, make logs Public 17:26:12 please title this meeting ("meeting: ..."), ivan 17:27:19 Meeting: DID Extra F2F preparation call 17:27:43 chair: brent 17:28:09 date: 2020-01-17 18:00:22 Orie has joined #did 18:00:38 markus_sabadello has joined #did 18:00:53 azaroth has joined #did 18:01:20 present+ 18:01:39 present+ Rob_Sanderson 18:01:47 present+ manu 18:01:52 present+ rhiaro 18:01:57 present+ orie 18:02:04 present+ markus 18:02:17 present+ jricher 18:02:28 present+ 18:02:28 present+ dlongley 18:02:33 jricher_ has joined #did 18:03:08 present+ 18:03:17 present+ brent 18:03:21 present+ 18:04:02 oliver has joined #did 18:04:05 present+ oliver 18:04:21 mike-lodder has joined #did 18:04:41 tplooker has joined #did 18:04:50 scribe+ rhiaro 18:04:59 brent: Today's primary topic is agreeing on where we disagree 18:05:05 ... Any additional questions that we feel need to be answered? 18:05:29 ... Anything else people want this meeting to be used for? 18:05:53 q+ 18:06:04 ken has joined #did 18:06:09 ... manu got a document out 18:06:10 present+ 18:06:18 present+ 18:06:56 manu: the email sent out to the list is here.. 18:07:06 Manu's list of concerns, disagreements, questions -- https://lists.w3.org/Archives/Public/public-did-wg/2020Jan/0013.html 18:07:30 ... I've had some one on one conversations and tried to read through all of the PRs and issues and consolidate it into root cause disagreements, issues and concerns 18:07:35 ... not complete by any means, just documenting what I can see 18:07:41 ... I think we're picking up with disagreements this time 18:07:54 ... These are things we agree that there's a disagreement on this 18:08:02 DISAGREEMENT: Extensibility is being prioritized above security in the current DID specification. 18:08:04 ... Somebody said something and soebody else agreed that it was a disagreement 18:08:29 ... That we're focussing on the wrong thing, that we shouldn't focus on extensibility but on security, there's disagreement on that 18:08:34 ... The second one I've heard only two people raise this 18:08:38 ... I thought it was interesting 18:08:41 DISAGREEMENT: IOT is the primary use case for DIDs by many orders of magnitude. 18:08:54 ... There's disagreement about the primary use case 18:09:11 ... There are at least two people who said VCs are nice but if you think that's the primary driving use case for DIDs it is not 18:09:25 ... The use case is that we'll have billions of devices which need to be able to do activities, already working groups on that stuff 18:09:34 present+ 18:09:44 ... If the DID WG messes this up you're going to have a whole bunch of IOT devices that pick a different solution, primarily by making it over complicated by using JSON-LD 18:09:44 DISAGREEMENT: The IOT use case and use of JSON-LD are incompatible. 18:10:07 ... IOT is simple, compact, straightforward, low code size, really tight security parameters, and JSONLD is the opposite of that in almost every way 18:10:17 ... There's little to no overlap 18:10:35 DISAGREEMENT: Data in DID Documents are not intended to be co-mingled with data retrieved from Verifiable Credentials. 18:10:35 notes that "JSON-LD is the opposite of that in every way" is an assertion that is contested and part of the disagreement 18:10:56 ... Folks are saying that JSON-LD is fine for VCs, because there's all this data that needs merging and you need good semantics 18:11:00 ... And that you don't need that for DID Documents 18:11:11 ... You don't need that level of extensibility, you're not going to be merging DID Docs with VCs 18:11:20 ... Where it makes sense for VCs it doesn't make sense for DID Documents, two different problem domains 18:11:23 present+ 18:11:24 ... Disagreement over whether that's true 18:11:29 DISAGREEMENT: JSON-LD makes the same mistakes that XML made in the late 1990s. 18:11:46 ... This one, that in the 90s people were excited about namespaces, and having globally understandable documents 18:12:04 ... but what happened was those architectures lost because they were overly complicated, systems didn't need it 18:12:14 ... Therefore json-ld is trying to do the same thing that xml was but in JSON and we know how that played out 18:12:22 brent_ has joined #did 18:12:26 ... XHTML lost to HTML5, JSON won over XML, SOA was kicked to the curb 18:12:29 present+ 18:12:30 ... We don't need to relive that failure 18:12:30 q? 18:12:42 ... I'm sure there are more. That was the hardest list to get together 18:12:51 ... Difficult to articulate an assertion and disagreement over an assertion 18:12:56 ... What other disagreements are there? 18:12:59 q? 18:13:01 q- 18:13:08 brent: jump on the q if you have either a disagreement about a disagreement 18:13:17 q+ 18:13:18 ... If there are additional disagreement that you want recorded and addressed, chime in 18:13:35 q+ 18:13:36 q+ 18:13:37 ack mark 18:13:40 ack markus_sabadello 18:13:44 markus_sabadello: one item of disagreement, may be part of something already mentioned, is how extensibility should work 18:13:47 DISAGREEMENT: There is a simple way to support both JSON-LD and JSON-only expressions of DID Documents together. 18:13:47 SamSmith has joined #did 18:13:47 q+ 18:13:56 ... Should extensibility work through a registry process or in a decentralised permissionless way 18:14:05 ... it's connected to the things manu said, the namespaces and comingling of data 18:14:11 +1 (we don't agree on how the spec should support extensibility) 18:14:11 ... it could be a separate item 18:14:14 +1 to Markus' disagreement, because it's more precise. 18:14:37 ... DISAGREEMENT: How extensibility should work 18:14:45 ack tplooker 18:15:12 DISAGREEMENT: How will extensibility of DID documents work? E.g. registry process, or decentralized permissionless, process, etc. 18:15:17 tplooker: one of the disagreements I saw that stood out, related to markus, how extensibility would work using JSON-LD and the implications for JSON developers, and how the implications are on the level of understanding needed by someone who is unaware of JSON-LD 18:15:29 ... what are the requirements that would preserve JSON-LD like functionality for non-JSON-LD developers 18:15:43 scribe+ 18:15:53 ack jricher_ 18:16:05 jricher_: The disagreement I've seen throughout the issues, is what the burden will be on different classes of developer. 18:16:10 DISAGREEMENT: There should be a way to detect if JSON-LD is meant to be used or not. 18:16:41 jricher_: So, requirement or removal of @context, led to a lot of discussion about how much harder or easier it would make, depending on which camp you're in. There seem to be a lot of disagreement about what group of developers this group is trying to make things easier for. 18:16:53 ack dlongley 18:17:14 q+ to discuss DISAGREEMENT: There should be a way to detect if JSON-LD is meant to be used or not. 18:17:18 dlongley: I typed my disagreement above as well, there is a disagreement that there is a simple way to support both JSON-LD and JSON documents together. This has to do with who is going to bear what burden. 18:17:22 DISAGREEMENT: What is the burden on developers for either inclusion or removal of JSONLD components for either JSONLD or JSON devs? 18:17:24 +1 to dlongley 18:17:24 q? 18:17:40 DISAGREEMENT: There *needs* to be a way to distinguish between JSON-LD and JSON DID Documents. 18:18:00 dbuc: There is one implicit disagreement, which is who are we targetting - I hope there is an emperical argument... from my standpoint, target most number of developers in easiest way. 18:18:01 DISAGREEMENT: How extensibility would work in a JSON-LD enabled DID Document and the implications for developers who are un-familiar with JSON-LD 18:18:18 +1 to that statement, this is corrollary to what I was saying 18:18:23 present+ dbuc 18:18:28 dbuc: Are we targeting the broadest set of people in easiest fashion, or not - we could have a discussion around that. 18:18:30 DISAGREEMENT: who are we targeting as users of the spec 18:18:50 q+ to ask is there a disagreement that we even need extensibility at all? has anyone proposed just not having extensibility and keeping it fixed data model [for this version]? (I can't speak cos I'm in a dorm of sleeping people right now) 18:18:50 q? 18:18:52 dbuc: Is the spec targetting the broadest group of developers possible with the easiest integration, or is that not a primary goal? 18:18:59 ack Orie 18:18:59 Orie, you wanted to discuss DISAGREEMENT: There should be a way to detect if JSON-LD is meant to be used or not. 18:19:01 q+ 18:19:26 Universality with finite extensibility is more valuable than ultimate extensibility without universality 18:19:32 Orie: I might as well verbalize my #1 disagreement, we are agreeing to this disagreement, there is no way to detect the feature of JSON-LD today. We all agree that it's impossible to intend to support it in the current spec. I would like to see a resolution to that. 18:19:50 ack rhiaro 18:19:50 rhiaro, you wanted to ask is there a disagreement that we even need extensibility at all? has anyone proposed just not having extensibility and keeping it fixed data model [for 18:19:50 ack rhiaro 18:19:53 ^ 18:19:54 ... this version]? (I can't speak cos I'm in a dorm of sleeping people right now) 18:19:54 Orie: Independent of whether or not JSON-LD is used in the DID spec, I'd like to know whether or not it was intended to be used in the DID Method spec. 18:19:58 present+ SamSmith 18:20:19 Amy: is there a disagreement that we even need extensibility at all? has anyone proposed just not having extensibility and keeping it fixed data model [for this version]? 18:20:19 Best way to detect intent to use JSON-LD is the presence of @context 18:20:21 limited extensibility is a requirement 18:20:22 yes, that 18:20:25 no more additional properties 18:20:27 dbuc: Do you mean we can't add more properties, or fixed as it can never change? 18:20:33 brent_: No more additional properties? 18:20:34 [for this version] 18:20:37 Limited extensibility can be a process for adding properties 18:20:39 yeah I'm handwaving versioning a bit 18:20:41 dbuc: Ever? Or v1, then v2, etc. 18:20:57 brent_: This version would be fixed, if you want more properties, it would be in a future version. 18:20:57 q? 18:21:01 DISAGREEMENT: The best way to detect intent to use JSON-LD is the presence of `@context` as opposed to the presence of additional contexts beyond the core context. 18:21:01 present+ Benjamin_Young 18:21:04 disclaimer: I have only skimmed the threads 18:21:07 ack oliver 18:21:24 oliver: I think there is disagreement on who decides which datamodel or encoding will be used - is it resolver, DID Method spec, DID author, etc. 18:21:35 DISAGREEMENT: I think there is disagreement on who decides which data model or encoding will be used for the DID Document, e.g., resolver, DID method spec author, etc.? 18:22:13 q? 18:22:20 brent_: Does anyone disagree w/ the list of these disagreements? 18:22:24 Disagreement: with Disagreement the presence of @context is way to message intent to use JSON-LD 18:22:25 q+ 18:22:25 DISAGREEMENT: We have not established who defines did core spec compliance for a did method. (document author, method spec author, resolver) (duplicate of oliver's) 18:22:43 brent_: These will factor into the Chairs planning of the F2F meeting. 18:22:45 ack markus_sabadello 18:23:13 markus_sabadello: There may be disagreement about whether or not a DID Document is a resource on the Web, or is it more like a DNS record, lower layer that's not on t he Web? Sometimes we treat it like it is, sometimes we treat it another way. 18:23:20 +1 to markus_sabadello 18:23:21 q+ 18:23:27 q+ 18:23:29 ack dlongley 18:23:45 dlongley: Response to Markus, it might also be the case that DID Documents may play both roles depending on DID Method. 18:23:59 ack SamSmith 18:23:59 sounds like a duplicate of "who defines did core spec compliance for a did method" 18:24:29 Establishment of control authoruty or not in a DID Doc is a vital 18:24:38 trying to fix microphone 18:24:45 DISAGREEMENT: Is a DID document a resource on the web with a URL that can be dereferenced, or is it more like a DNS record that exists not on the web but on a lower layer. Or can it be both, and if it can be both, then what does it depend on? 18:24:50 let someone else go for now 18:25:00 q? 18:25:10 s/let someone else go for now// 18:25:20 s/trying to fix microphone// 18:25:22 q+ 18:25:32 ack Orie 18:25:44 q+ 18:26:03 ack dlongley 18:26:33 dlongley: There seems to be a cncern around primary purpose of DID Document. Keys, services... or if it's somehow used to get to the authoritative information about a DID Subject. 18:26:46 dlongley: There is confusion around "getting to" vs. "what is in" a DID Document. 18:26:56 q? 18:27:01 DISAGREEMENT: we don't have the separation of control authority from the semantics of a did subject defined 18:27:11 ^my attempt at dave 18:28:34 DISAGREEMENT: The primary purpose of a DID Document is to provide information about a DID subject (such as services to interact with them and what keys they have authorized for what purposes) vs. establishing authority over the DID. 18:28:43 SamSmith: My concern is that, per my presentation last DID meeting, we have two tasks in front of us as establishing a DID as the authority over a DID. There is confusion among whether or not the DID Document plays an essential role or an optional role. 18:29:06 DISAGREEMENT: DID resolution is about establishing an authoritative DID Document for a DID and DID Documents must necessarily express something else after that. 18:29:19 SamSmith: If DID Documents are optional, then the DID spec itself has a huge hole in indicating how we establish authority. If we say all methods get to decide how to do that, then we have to say that DID Documents don't establish control authority. 18:29:57 SamSmith: If we say that DID Doc does play a role, but we have multiple ways of establish control authority that will be a mess. It's more important than some of the things we're talking about. 18:30:07 SamSmith: The disagreement is that we don't know what we're doing. 18:30:21 SamSmith: We've said it's up to the method, and whether the method uses the DID Document or not is up to the method. 18:30:54 this sounds like a combination of markus's comment and daves. 18:30:56 SamSmith: Is this a lower layer? Role of a Dynamic DNS server, or is it a higher layer, once you've resolved the IP address, and authenticated, now you have an authorized piece of information that you can end-verify to the control authority and you know it's a valid DID Document. 18:31:07 DISAGREEMENT: A DID Document expresses information about a DID subject that may or may not self-contain a way to check the authority of that DID Document for that DID. 18:31:09 q+ 18:31:10 SamSmith: As far as I know, we've punted to the Methods on that question. 18:31:14 q+ 18:31:22 ack markus_sabadello 18:31:30 markus_sabadello: To what Sam said, maybe the disagreement is whether that's a bug or a feature. 18:31:57 dlongley: I was trying to capture that... A DID Document expresses information about a DID subject that may or may not self-contain a way to check the authority of that DID Document for that DID... so, it might be that some DID Documents can self-contain that information, and others don't, and that might depend on the DID Method. 18:32:11 q- 18:32:39 q+ to cover open questions. 18:32:44 Topic: Open Questions 18:32:44 DISAGREEMENT: A DID Document expresses information about a DID subject that may or may not self-contain a way to check the authority of that DID Document for that DID (it may depend on the DID method). 18:32:58 brent_: What are the open questions, we have some from Manu. 18:33:13 ack manu 18:33:13 manu, you wanted to cover open questions. 18:33:20 manu: back to the email.. 18:33:22 q+ to discuss graph vs non graph data models 18:33:27 Manu's list of questions - https://lists.w3.org/Archives/Public/public-did-wg/2020Jan/0013.html 18:33:50 ... They're intended to attempt to ask the righ tquestions so we get answers to the concerns and disagreements 18:33:57 ... we could maybe ask that would illuminate some part of the discussions 18:34:01 QUESTION: What is the technical use case that is made not possible due to the use of JSON-LD? 18:34:30 ... What use case can't you do because you are using json-ld? It could be 'make it as simple as possible' 18:34:37 q+ to ask what can json-ld not do using a json model? 18:34:38 ... What specific technical use case 18:34:40 QUESTION: What are the specific technical implementation burdens that are created by the use of JSON-LD? 18:35:00 ... What specific, these lines of code and that is unacceptable 18:35:05 ... or I have to go out to the network and that is unacceptable 18:35:08 ... Those types of answers 18:35:14 QUESTION: What are the specific costs of using JSON-LD DID Documents? 18:35:37 ... eg. I'm a JSON only developer and here are the very specific costs to my implementation or ecosystem because that document is JSON-LD 18:35:49 QUESTION: What is the definition of "JSON-LD Processing"? 18:36:01 ... There have been a number of people who have either asserted you don't have to do any json-ld processing, or of course I have to, jsut you saying I don't have to doesn't mean 18:36:20 ... Getting the definiition of what people mean by JSON-LD processing might be helpful, because it might be that people have different definitions, one is colloquial and one is from the JSON-LD spec 18:36:21 QUESTION: What is the extensibility model for JSON-only DID Documents? 18:36:37 ... We know what extensibility for JSON-LD DID DOcs is 18:36:52 ... W'ev seen people suggest mechanisms for JSON only documents but we should get them on the table, we need some understanding about the options 18:36:57 QUESTION: Do people understand that JSON-LD is a more restrictive subset of JSON, so JSON-LD is JSON and is designed to be a "Chimera document format"? 18:37:18 and what are the properties of the extensibility model? (e.g., does it create globally unambiguous semantics?) 18:37:21 ... When people are saying JSON-LD isn't JSON, from a technical standopint it is, but that's probably not the point of contention 18:37:30 ... Are people familiar with Chimera document formats? 18:37:39 ... Having a discussion around what are Chimera document formats and when to use them might be helpful 18:37:58 QUESTION: Does everyone understand that you do not need to go out to the network to process a JSON-LD document and that verifiers SHOULD NOT go out to the network to retrieve JSON-LD Context documents? 18:38:02 ... The last question had to do with a discussion we had on the list 18:38:30 ... Having a discussion around that might be helpful for folks who are concerned about security implications or what happens if the document changes 18:38:33 q? 18:38:39 ... Those are some of the questions that might help us have discussions 18:38:48 rrsagent, draft minutes 18:38:48 I have made the request to generate https://www.w3.org/2020/01/17-did-minutes.html manu 18:38:50 QUESTION: Can JSONLD processors work with an implied @context field? 18:38:51 ack Orie 18:38:51 Orie, you wanted to discuss graph vs non graph data models 18:39:42 Orie: I think what I wanted to ask might be covered by Manu's questions. When we are talking about abstract data models, are we talking about graphs or trees? 18:40:08 Orie: At the core, this is really Linked Data or not Linked Data, and that conversation is graph or not graph. Might be helpful to review graph vs. not graph data structures, why you would use one over the other. 18:40:12 ack ken 18:40:12 ken, you wanted to ask what can json-ld not do using a json model? 18:40:38 +1 to ken 18:40:44 (and that gets at my question too) 18:40:45 Ken: I wanted to look at the converse - if we adopt a JSON-only data model, what are the implications to the JSON-LD community? Are there things that are difficult to do, impossible to do? What happens if we use JSON-only? 18:40:49 q+ 18:41:00 QUESTION: If a JSON-only model is used, what kind of interoperability problems does it create (or could it create without careful work)? 18:41:06 ack markus_sabadello 18:41:09 q+ to read what I typed for some reason 18:41:36 markus_sabadello: One open question is - if you're in one of the two camps and you have a preference for one of the data formats, what will your software do when you see the other one? 18:41:44 QUESTION: If a JSON-only model is adopted, what are the things that are impossible or difficult to do as a JSON-LD developer? 18:42:08 markus_sabadello: One way of answering that is it's the resolver... but another is that DID Methods may only support one. 18:42:14 ack jricher_ 18:42:14 jricher_, you wanted to read what I typed for some reason 18:42:31 QUESTION: Can libraries be easily written such that they don't have to care about the DID method, only the DID Document? 18:42:34 q+ 18:42:46 jricher_, activitystreams 2.0 did that with an option to infer the context from a new MIME type, and I think in the end nobody liked that solution and I don't know if any JSON-LD libraries/processers or any generic tooling has implemented it at all 18:42:58 jricher_: All I asked was, could JSON-LD processors work with an implied context field? That gets at the question Ken was asking, if there was JSON-only, what are the costs to the JSON-LD community - can JSON-LD work in that space? That's a more fundamental question, I had a specific instancfe of that question. 18:42:59 ack dlongley 18:43:20 q+ to make an overall statement not a question 18:43:22 dlongley: I put my question into IRC - can libraries be easily created that can generically process DID Documents? 18:43:22 QUESTION: If you have a preference for a certain DID document format (e.g. JSON or JSON-LD), what will your software do if it encounters the other format that you don't prefer? 18:43:23 q+ 18:43:26 ack jricher_ 18:43:26 jricher_, you wanted to make an overall statement not a question 18:44:26 jricher_: Not to add a question, waiting for queue to empty - I think that we as a community really do need to come down on the side of this beign a JSON-LD document or always processable w/ just JSON tools and literally nothing else, no schemas, no nothing, because what we have right now is not serving either community well... because it's doing things that are not quite true. 18:44:36 QUESTION: Does the JSON-LD extensibility model prevent interoperability if security should not be compromised? 18:44:37 ack oliver 18:44:41 jricher_: I don't have a strong opinion on what side we land on, but I strongly thing that we do need to pick one. 18:44:55 s/strongly thing/strongly think/ 18:45:01 +1 to Oliver's concern 18:45:02 +1 we should absolutely enable processing with just things like JSON.parse() and `===`, even if JSON-LD is used. 18:45:15 q+ 18:45:19 dlongley: yes that's what I was going for 18:45:25 ack markus_sabadello 18:45:57 +1 to markus_sabadello, the quesiton is important 18:45:58 markus_sabadello: Not sure if it's a question or disagreement, Do we want to pick one, or do we want the ability for others to come up with more formats, like CBOR or IPLD? Do we want to include that in our thinking? Or do we want to absolutely pick one? 18:46:13 +1 to Markus question 18:46:40 DISAGREEMENT: We have to pick 1 data format vs. we will allow more (unlimited?) data formats e.g. CBOR, IPLD, etc. 18:46:43 q? 18:46:52 brent_: For the record, I am working on an interpretive dance format for DID Documents. 18:46:58 q+ 18:47:02 There are two aspects interoperability. One is at the encoding layer. Encoding leverages tooling for that encoding. Support for more encodings provides interoperability between encoding specific tooling. This broadens adoption. Limited extensibility between tooling ecosystems is to be expected. 18:47:03 brent_: So this is near and dear to my heart (and legs) 18:47:19 q? 18:47:22 brent_: Appreciate the input, the Chairs are going to try hard to address as many of these in the Agenda that's created. 18:47:33 ack azaroth 18:48:07 azaroth: A question, but not capital question, could there be a list of agreements that could contribute to the concerns/disagreements? Is there general agreement that toolchain needs additional work? Or is that not a disagreement we've talked about. 18:48:18 The other interoperability is within a tooling ecosystem. One can have higher interop and more extensibility within a tooling ecosysystem. The problem is trying to force a given tooling ecosystem on everyone. This is problematic 18:48:19 brent_: I think that's a great question - does anyone want to elucidate areas in which we agree. 18:48:20 q+ 18:48:29 ack manu 18:48:35 manu: a little generic, but all of us want to build the biggest possible tent 18:48:39 ... within reason 18:48:49 ... we want the DID spec to be used by the most number of developers 18:49:00 AGREEMENT: We should enabling processing DID Documents using JSON only tools like `JSON.parse()` and `===` even if DID Documents use JSON-LD. 18:49:06 ... without creating any security holes or vulnerabilities, and maximising peoples' independance while ensuring we're maximising interop 18:49:17 ... I don't think anyone would really argue, but that's the general thing you strive for with any kind of WG 18:49:25 ... I'd be surprised if anyones aid absolutely not, we have a narrow target 18:49:37 ... The other thing that I think we agree on is that security is probably the number one concern 18:49:50 ... it's not extensibility is number one. If this thing is not secure it won't work. Full stop. Security is number 1. 18:49:59 ... Secondary is developer usability, and then maybe a distant third is extensibility 18:50:04 ... There are variosu other things we care about as well 18:50:11 ... I think we all agree we want to make sure this thing is absolutely secure 18:50:31 ... I do also think we agree that we do want to .. someone might disagree... I think we agree that we don't want to lock ourselves in to whatever we're doing this year and next year 18:50:51 ... we do want to think about other syntaxes like cbor, we do want to target JSON - I think we agree on that - and I'm saying that includes JSON-LD - and we do want to think about the future 18:51:00 ... use cases like cbor and things like that 18:51:39 ... I haven't had a chance to look at many of the concerns and disagreements but at a fundamental basis I think people are operating in good faith and we're trying to work through tihs and get something that works for everyone without raising the burden so high for any community that it's impossible for them to use the spec, because that would be a failure becuase that subset will do their own thing and we'll all suffer if we confuse the market 18:51:51 ... I also think we agree on the notion that unbounded extensibility is a bad thing 18:51:52 AGREEMENT: Anyone reading the spec should be able to understand the core DID Document data model (not extensions) without having to understand how to write extensions. 18:51:57 ... Extneding whatever, whenever, is a bad way to interop 18:52:19 ... I think we also agree on limiting the spec in very specific ways and saying you shouldn't use these features of some of the technologies is an appropriate thing to do in the spec 18:52:29 s/Extneding/Extending/ 18:52:30 ... I think we do agree on the fundamentals, which is why I still have hope we'll find a solution 18:52:45 brent_: I think we all agree that we want DIDs to be a spec that comes out of the W3C and this WG 18:53:01 ... W're all here because we want to produce something and we want as many people to use it as possible 18:53:09 ... thanks azaroth for stimulating the agreements 18:54:00 brent_: our next time will be on our regularly scheduled call on Tuesday; next additional call is Wednesday at the same time as this 18:54:14 ... Thanks everyone! 18:54:29 RRSAgent, please draft minutes 18:54:29 I have made the request to generate https://www.w3.org/2020/01/17-did-minutes.html rhiaro 18:54:35 rrsagent, make minutes 18:54:35 I have made the request to generate https://www.w3.org/2020/01/17-did-minutes.html manu 18:54:39 ken has left #did 23:34:59 mitja has joined #did