14:39:11 RRSAgent has joined #did 14:39:11 logging to https://www.w3.org/2021/05/11-did-irc 14:39:13 RRSAgent, make logs Public 14:39:15 please title this meeting ("meeting: ..."), ivan 14:39:25 Meeting: DID WG Telco 14:39:25 Chair: brent 14:39:25 Date: 2021-05-11 14:39:25 Agenda: https://lists.w3.org/Archives/Public/public-did-wg/2021May/0009.html 14:39:25 ivan has changed the topic to: Meeting Agenda 2021-05-11: https://lists.w3.org/Archives/Public/public-did-wg/2021May/0009.html 14:39:26 Regrets+ burn 14:47:15 regrets+ 14:58:39 justin_r has joined #did 14:59:06 brent has joined #did 15:00:20 present+ 15:01:04 present+ 15:01:17 present+ markus, shigeya, TallTed 15:01:23 present+ justin_r 15:01:35 markus_sabadello has joined #did 15:01:43 present+ 15:02:30 present+ adrian 15:02:44 agropper has joined #did 15:02:59 present+ 15:03:12 present+ 15:03:19 present+ manu 15:03:21 present+ 15:03:27 I'm semi-present today... driving to and getting and driving from Moderna #2. Have audio, will not have IRC (though I'll leave my client lurking). 15:03:29 Geun-Hyung has joined #did 15:03:48 Present+ 15:04:22 present+ 15:05:38 scribe: manu 15:06:10 scribe+ 15:06:24 Topic: Agenda Review, Introductions, Re-introductions 15:07:07 brent: We're going to talk about special topic call, brief section on status of implementations, we'll do discussion on DID Spec Registries (clarifications of previous resolutions), implementation guide, and as time permits, finish off with any open issues and PRs for DID Core. 15:07:12 brent: any questions/additions? 15:07:26 None 15:07:37 brent: foregoing intros/reintros because we all know each other well at this point. 15:07:39 Topic: Special Topic Call 15:07:59 brent: The special topic call is today, Tuesday, 6pm ET 15:08:09 brent: The topic is "The Implementation Guide" 15:08:14 brent: any questions? 15:08:25 Topic: Status of Implementation Feedback 15:08:34 q+ 15:08:41 brent: What's the current status? 15:08:43 ack manu 15:08:51 https://github.com/w3c/did-test-suite/ 15:08:59 manu: Heres a link to the test suite 15:09:16 drummond has joined #did 15:09:18 present+ drummond 15:09:22 present+ 15:09:39 dbuc has joined #did 15:09:40 manu: At present we have finished the tests 15:09:43 present+ 15:09:48 manu: We have sent a request out for implementations 15:10:05 https://lists.w3.org/Archives/Public/public-credentials/2021May/0046.html 15:10:30 manu: in the meantime, we have gotten a few implementations in already: https://github.com/w3c/did-spec-registries/pulls 15:10:52 manu: We're looking for more implementations, I've got a question for the group... is it okay if we just merge implementations immediately if they're passing the tests? 15:10:56 q+ 15:11:07 ack markus_sabadello: 15:11:08 markus_sabadello: The link may have been wrong... 15:11:31 manu: Sorry, wrong link -- right link to new implementations -- https://github.com/w3c/did-test-suite/pulls 15:11:59 brent: Question to the group -- any opposition to merge test reports as they come in as long as they're passing? 15:12:05 brent: I'm not hearing any objections... 15:12:15 brent: if there is no opposition, seems like a good sense move to me. 15:12:31 brent: Has there been any help in doing the automatic report generation? 15:12:32 q+ 15:12:40 ack mark 15:12:59 markus_sabadello: Yes, I also think we should merge passing tests/implementations as they come in 15:13:05 markus_sabadello: I'm not aware of any changes there. 15:13:09 ack manu 15:13:35 manu: we have had no automatic report generation 15:13:58 dmitriz has joined #did 15:14:03 present+ 15:14:14 ... we really need this done - we can't tell how many features have been - we're stuck - can't get out of CR 15:14:36 q+ 15:14:41 ack ivan 15:14:42 ... probably have enough for 85% of the spec but we're blind and will keep us from getting out of CR 15:14:59 ivan: Manu, is there somewhere... is there somewhere a clear description or something of what the automatic generation should mean? 15:15:01 q+ 15:15:12 report generation issue: https://github.com/w3c/did-test-suite/issues/78 15:15:46 ack manu 15:16:11 manu: there is not - we had calls - there's some record somewhere - "the gratin of the report will take in everything and when we generate the report it will put the normative things down - Orie did some and it's unsure if Orie will do it again 15:16:32 ivan: If it's not a difficult task, it seems like you have to know knowledge about test suite 15:16:32 q+ 15:16:49 ivan: It's not like you're processing a CSV file... that's a much easier thing -- you really have to know the testing inside and out. 15:17:01 ack manu 15:17:39 manu: Yes - you need to understand how MOCA and ??? run and then the thing could be converted to CSV and then to ReSpec - and then figure out the matching rules for each one 15:17:48 ivan: Something more clearly defined might help. 15:18:01 I'm wondering whether Orie will merge this PR: https://github.com/w3c/did-test-suite/issues/78#issuecomment-830204485 15:18:21 manu: I don't think we're going to get there - will take one or two hours 15:19:00 brent: to sum up, in order to exit CR, we need to know how many implementations of each feature are going to be submitted in order to automatically generate that report -- a manual painstaking process without automatic tabulation. We are still seeking volunteers to help with that work. If you have willingness and time, there are some links in the issue that can give you the guidance you need to get started. 15:19:08 q+ 15:19:09 brent: Any other questions/comments before we move on to the next topic? 15:19:18 ack shigeya 15:19:41 shigeya: I do not understand the patterns of the test runner -- the link I posted, Orie's comment, he mentioned that one PR never got merged into the test suite. 15:20:03 shigeya: This solves part of my ... missing part of my understanding of the test suite -- will this change be merged? 15:20:14 shigeya: I don't know if it'll be merged or not. 15:20:23 q+ 15:20:50 shigeya: I can't say if I can contribute or not because of this... once I can generate with latest branch then I can estimate how much I need to spend there... I can contribute I think. 15:21:01 shigeya: That's a blocker to contribute at this point for me. 15:21:06 https://github.com/w3c/did-test-suite/pull/20 15:21:25 brent: This is high priority for us... what would it take to merge this PR? 15:21:43 q? 15:21:50 ack manu 15:23:14 q+ 15:23:28 ack markus_sabadello 15:23:49 manu: I think we need to move past this PR... it's old and has conflicts and there is frustration around the PR 15:23:49 q+ 15:24:42 markus_sabadello: I think there was something wrong about JSON vs. JSON-LD representations, but there is a lot that seemed perfectly fine, huge PR, did a lot of things... I did disagree with one small part of it, but not other parts -- I don't remember this in detail, not fully understand what's missing now wrt. what's missing for generating reports... don't understand what's needed from that previous PR right now. 15:24:44 ack ivan 15:25:15 ivan: practical issue, PR against master branch... can't remap the PR... this PR seems lost in any case. 15:25:15 q+ 15:25:24 ack justin_r 15:25:46 justin_r: It's simple enough to create a new PR with this branch as it is, retargeted towards main, if someone thinks it's worth pursuing it can be done. 15:25:54 q+ 15:26:00 brent: If there are no more comments/questions, let's continue. 15:26:11 ack shigeya 15:26:32 shigeya: I think I can look at the PR and grab part of the initial functionality to create an initial PR... I'll ask Orie if it's ok to merge PR into the repository 15:26:42 Topic: DID Spec Registries 15:26:57 brent: We made a number of resolutions about the registries. 15:27:00 https://github.com/w3c/did-spec-registries/issues 15:27:15 brent: The issues have not yet been acted upon... so we're going to go through the issues at this point. 15:27:34 brent: If you follow the link, you will see 76 open issues on the registries... that's a lot 15:28:01 brent: We have proposals and some resolutions that we need to look at, so, stabbing at random. 15:28:02 q+ 15:28:10 q+ to note we have resolutions on the books here. 15:28:23 ack manu 15:28:23 manu, you wanted to note we have resolutions on the books here. 15:29:26 manu: background: we had made a number of resolutions to remove, for example, the CDDL stuff, as a requirement for registration - it fell out of alignment with the specification - Orie put a PR to remove CDDL 15:30:30 ... but something else was also removed and the PR was closed - Orie was acting on a resolution that the group made - so now we need to make a new try to remove CDDL - 15:30:57 ... suggestion: let's remove CDDL but without JSO schema being caught int he cross fire 15:31:10 s/JSO /JSON / 15:31:25 manu: do you want me to author a Proposal? 15:31:34 brent: yes 15:32:25 brent: Let's have a proposal... 15:32:35 PROPOSAL: CDDL will no longer be required for registration of items into the DID Spec Registries. All current CDDL will be removed from DID Spec Registries. 15:32:38 +1 15:32:39 +1 15:32:39 +1 15:32:40 manu: +1 15:32:40 +1 15:32:42 +1 15:32:46 +1 15:32:48 +0 15:32:48 q+ 15:32:56 ack drummond 15:33:17 drummond: Just wanted to ask, if we're also going to get to discuss idea of adding a table w/ DID Methods indicate where representations they do support. 15:33:33 +1 15:33:46 RESOLVED: CDDL will no longer be required for registration of items into the DID Spec Registries. All current CDDL will be removed from DID Spec Registries. 15:33:49 q+ 15:33:54 ack manu 15:35:15 manu: the next one is removing JSON schema in DID core as well. It is required for registration -or - we publish a JSON schema that you can run against - 15:35:44 manu: I will make two proposalss 15:36:05 q+ 15:36:15 ack ivan 15:36:50 ivan: If one item has a JSON Schema, it will lose it -- have a slot in registry where people can voluntarily add their JSON Schema would make sense, not require it. 15:36:51 q+ 15:36:52 q+ 15:37:28 ack manu 15:37:39 +1 to supplying the normative schemas in the referenced specification --- which is NOT optional 15:37:44 ack drummond 15:37:44 manu: I get where you're going - but it would complicate the registry - people should put it in their specs - we would add language to pit it in your spec 15:38:16 drummond: That's the second reason -- what is in the registry -- surface just the MIME types that your specification supplies the schema for... indicate in a table what to do. 15:39:05 s/pit it/put it/ 15:40:13 PROPOSAL: JSON Schema will no longer be required for registration of items into the DID Spec Registries. All current JSON Schema, except for the one pertaining to DID Core, will be removed from DID Spec Registries. 15:40:16 +1 15:40:16 +1 15:40:17 manu: +1 15:40:19 +1 15:40:19 +1 15:40:21 +1 15:40:29 +00 15:40:35 +1 15:40:40 +0 15:40:57 RESOLVED: JSON Schema will no longer be required for registration of items into the DID Spec Registries. All current JSON Schema, except for the one pertaining to DID Core, will be removed from DID Spec Registries. 15:40:59 q+ to note next item... 15:41:09 ack manu 15:41:09 manu, you wanted to note next item... 15:41:22 q+ 15:41:26 manu: we just passed we will do a JSON Schema for DID Core 15:41:49 ivan: The current JSON Schema will become out of date as soon as you change the publicKeyBase58 thing, I will do those changes once it's in Core. 15:41:50 ack ivan 15:41:53 q+ 15:41:59 ack manu 15:43:10 q+ 15:43:12 q+ 15:43:12 manu: This is the last one: We're trying to get DID Spec Registries easily maintainable - When you register things: you pu the item in, you point to the spec and as Drummanod says - put in the entries in a format to be changed 15:43:13 q+ 15:43:19 ack drummond 15:44:11 drummond: Just wanted to point out that -- the benefit is that it surfaces in the registry for prospective users of extensions to understand what's supported... some peer pressure to support more representations. Easy thing to check. Not required that maintainers verify that all those schemas / representations are valid... just that it's there in the spec. 15:44:12 ack markus_sabadello 15:45:08 markus_sabadello: I don't understand at all what it means for a property/extension to list what MIME types it supports -- whole idea of production/consumption is to support lossless conversion between all registered properties... if we now suggest that some mimetypes are supported and some are not ... it contradicts purpose of the abstract data model. 15:45:12 q+ 15:45:58 markus_sabadello: I do understand that not everything needs CDDL / JSON Schema, that's good... but concerned about things like additional representations defined in future, people shouldn't have to update their extensions/properties to make them work with their new representation... should be automatic implication of data model and registries 15:46:01 q+ to agree with Markus 15:46:04 ack drummond 15:46:52 drummond: That's true, purpose of MIME types for schema support is to indicate that they have done that -- that doesn't mean that's the only thing they work in... we would make that clear in the text -- this is to encourage specification writers to support schema support for different representations, not required for them to do that. 15:46:56 q+ 15:47:17 ack ivan 15:47:25 ivan: Mine is a minor point -- we still do not know what the MIME type is going to be, we don't want to make life difficult for registry maintainers... JSON/JSON-LD, that's all. 15:47:28 ack manu 15:47:28 manu, you wanted to agree with Markus 15:48:28 manu: agree with markus - the problem with registries happens when the information goes out of date - the second a new representation is created (e.g. CBOR-LD) 15:49:23 ... the second item: it's not clear that the field doesn't achieve what Drummond is trying to do - we don't want to say that some properties only work in some representations - we already have an ADM - 15:49:46 q+ 15:49:51 ... we don't want people to be confused about the role of registration 15:49:55 ack markus_sabadello 15:50:20 markus_sabadello: Could the field be named differently, propose to avoid language to avoid "supported representations" -- supported mime types, field could be linked to JSON Schema if available -- link to CDDL if available 15:50:24 ack drummond 15:50:35 q+ to run a poll 15:50:47 drummond: I wouldn't have called it supported -- we want spec authors to provide schema support for different representations. 15:51:52 drummond: Easy way for folks perusing to say which specs have schema support for new representations -- as specs are updated, those that choose, CDDL Schemas to spec... if it's not of enough value, too much value, let's forget it. The idea was keep schemas out of registry, idea is which specs hav them and which ones don't. 15:52:02 ack manu 15:52:02 manu, you wanted to run a poll 15:52:11 manu: I totally misunderstood your proposal: 15:52:52 ... you're saying: provide a box that says my spec is here and my spec defines CDDL and JSON Schema which has nothing to do with mime types 15:53:06 q+ to propose an alternative structure 15:53:13 Drummond agrees 15:53:16 ack justin_r 15:53:17 justin_r, you wanted to propose an alternative structure 15:54:35 justin_r: I share Markus' concern, wanted to propose something along the lines of what Drummond is saying, but perhaps more generically useful -- one of the goals of production/consumption is to allow explicit mapping of representation types/property identifiers, forget specific term we settled on... whole idea was to allow property to be defined that it always maps to a specific abstract data model data type and property name and optionally has a 15:54:36 property-specific translation to a representation-specific data serialization 15:55:27 justin_r: and a property identifier -- the idea here was to allow a property to be defined in such a way to be defined -- this property has this property name, JSON-LD has context, has this registered CBOR tag value and so on but also allow you to say this property has this proprty name and this abstract datatype and everything should still work. 15:55:42 justin_r: All representation are required to have default rules when something more specific isn't available. 15:56:11 justin_r: As a consequence, I agree with removing a requirement, but I disagree with a place to put it... but several steps past what Manu was saying as an interpretation of what Manu was saying. 15:56:13 q+ 15:56:36 brent: Next topic -- DID Implementation Guide 15:56:44 ack manu 15:57:47 manu: mate close off registries - do not make people read every spec that is in the registries - the easiest thing would be tell us what you're registering and then point to the spec - this makes it easy to maintnain 15:58:01 maintaining registries is difficult which is why IANA is a fully staffed professional organization dedicated to doing that. 🤷‍♀️ 15:58:12 ... the same thing could come into play as the CDDL problem - 15:58:16 But a JSON-LD context is still required, or..? 15:58:20 q+ to advocate reaching a happy medium of what is in the registry vs. what is in the spec the registry points to. 15:58:41 ... there is a cost to adding useful information to the registry 15:58:44 ack drummond 15:58:44 drummond, you wanted to advocate reaching a happy medium of what is in the registry vs. what is in the spec the registry points to. 15:59:02 drummond: This is fairly short -- there is a happy medium, we want to keep the burden on registry maintainers as low as possible. 16:00:05 drummond: I like Justin's idea, maybe it comes down to 3rd column... guidance on providing essential information about your spec that you want to make easily visible, and we don't get highly prescriptive about what's there... you might list schemas you provide, types of things Justin covered, information covered by registrant... 16:00:11 my prediction: an "other" field will just collect garbage over time if it's not structured. 16:00:34 manu: I agree with justin_r -- it'll end up being a dumping ground :/ 16:00:54 @manu you did not say that out loud :P 16:00:57 brent: We look forward to seeing you at 6pm, pleasure working with you, see you later. 16:01:05 rrsagent draft minutes 16:01:09 rrsagent, draft minutes 16:01:09 I have made the request to generate https://www.w3.org/2021/05/11-did-minutes.html ivan 16:01:46 zakim, end meeting 16:01:46 As of this point the attendees have been brent, ivan, markus, shigeya, TallTed, justin_r, markus_sabadello, adrian, cel, agropper, manu, Geun-Hyung, drummond, dbuc, dmitriz 16:01:50 RRSAgent, please draft minutes 16:01:50 I have made the request to generate https://www.w3.org/2021/05/11-did-minutes.html Zakim 16:01:52 I am happy to have been of service, ivan; please remember to excuse RRSAgent. Goodbye 16:01:56 Zakim has left #did 16:02:11 rrsagent, bye 16:02:11 I see no action items