14:17:15 <RRSAgent> RRSAgent has joined #did
14:17:15 <RRSAgent> logging to https://www.w3.org/2020/05/19-did-irc
14:17:17 <Zakim> RRSAgent, make logs Public
14:17:18 <Zakim> please title this meeting ("meeting: ..."), ivan
14:17:51 <ivan> Meeting: DID WG Telco
14:18:46 <ivan> Chair: brent
14:18:46 <ivan> Date: 2020-05-19
14:18:46 <ivan> Agenda: https://www.w3.org/mid/00000000000024bcce05a5b03f76@google.com
14:18:46 <ivan> ivan has changed the topic to: Meeting Agenda 2020-05-19: https://www.w3.org/mid/00000000000024bcce05a5b03f76@google.com0003.html0000.html
14:35:50 <yofukami> yofukami has joined #did
14:40:50 <chaals> chaals has left #did
14:54:03 <burn> burn has joined #did
14:55:31 <burn> present+
14:58:32 <Justin_R> Justin_R has joined #did
15:00:03 <ivan> present+
15:00:27 <yofukami> yofukami has joined #did
15:00:35 <phila> regrets+
15:00:40 <jonathan_holt> jonathan_holt has joined #did
15:01:27 <markus_sabadello> markus_sabadello has joined #did
15:01:38 <dbuc> dbuc has joined #did
15:02:22 <jonathan_holt> present+ jonathan_holt
15:03:12 <dlongley> present+
15:03:21 <Orie> Orie has joined #did
15:03:24 <Orie> present+
15:03:34 <manu> present+
15:04:56 <dbuc> present+
15:05:14 <chriswinc> present+
15:05:16 <manu> manu has changed the topic to: Meeting Agenda 2020-05-19: https://lists.w3.org/Archives/Public/public-did-wg/2020May/0010.html
15:05:19 <markus_sabadello> present+
15:05:20 <ivan> present+ identitywoman
15:05:25 <brent> brent has joined #did
15:05:29 <David_Ezell_Conexxus> present+
15:05:33 <identitywoman> identitywoman has joined #did
15:05:36 <markus_sabadello> scribe+
15:05:46 <dmitriz> dmitriz has joined #did
15:05:52 <brent> present+
15:05:52 <dmitriz> present+
15:05:53 <ivan> present+ chriswinc
15:06:02 <yoshiaki> yoshiaki has joined #did
15:06:20 <Justin_R> present+
15:06:29 <ivan> present+ kimhd
15:06:30 <markus_sabadello> brent: I'm going to ask dmitriz to re-introduce
15:06:32 <Eugeniu_Jolocom> Eugeniu_Jolocom has joined #did
15:06:46 <burn> Topic: Agenda Review, Introductions, Re-introductions
15:06:58 <markus_sabadello> dmitriz: I'm Dmitri Zagidulin, software developer at Digital Bazaar, I also worked with Solid. Currently one of the co-chairs of the Secure Data Storage Working Group at DIF/CCG.
15:07:02 <ivan> present+ Eugeniu_Jolocom
15:07:08 <markus_sabadello> dmitriz: I take a hands-on, development-orient approach to specs.
15:07:35 <kimhd> kimhd has joined #did
15:07:38 <selfissued> selfissued has joined #did
15:07:39 <kimhd> present+
15:07:41 <selfissued> present+
15:07:47 <markus_sabadello> brent: Any proposed changes to the agenda?
15:07:51 <identitywoman> present+
15:07:57 <burn> Topic: Next Topic Call
15:08:02 <ivan> present+ selfissued
15:08:03 <Eugeniu_Jolocom> present+
15:08:04 <dezell> present+
15:08:14 <markus_sabadello> burn: The next topic call will be at the regular Thursday time
15:08:15 <burn> https://github.com/w3c/did-core/labels/contract
15:08:24 <markus_sabadello> burn: The topic is going to be the DID Resolution contract
15:08:48 <markus_sabadello> burn: There's a relationship between DID Resolution and today's topic about testing
15:08:51 <burn> Topic: DID Parameters update
15:09:22 <burn> scribe+ chriswinc
15:10:04 <chriswinc> markus_sabadello: The WG has been discussing DID parameter syntax as part of a DID URL
15:10:38 <markus_sabadello> https://github.com/w3c/did-core/pull/285
15:10:48 <chriswinc> ... Query parameters proposed. PR285, looking for feedback.
15:10:58 <markus_sabadello> scribe+
15:11:08 <markus_sabadello> burn: manu can you give an update on spec structure?
15:11:14 <ivan> Topic: spec structure
15:11:17 <manu> https://github.com/w3c/did-core/pull/288
15:11:27 <markus_sabadello> manu: Drummond and rhiaro have been working on a rewrite of the front matter of the spec
15:11:43 <markus_sabadello> manu: It has been reviewed by a subset of editors+chairs, we believe it improves the introduction
15:11:47 <manu> https://pr-preview.s3.amazonaws.com/w3c/did-core/pull/288.html#introduction
15:12:12 <markus_sabadello> manu: Please review the PR, it basically consolidates some content in the Introduction
15:12:30 <markus_sabadello> manu: We would really like to get this into the document so we can start Horizontal Review
15:12:57 <burn> Topic: Registries Repo Renaming Straw Poll
15:12:58 <markus_sabadello> burn: We will then prepare for Horizontal Review (privacy review, TAG explainer, etc.) If you're familiar with this and would like to help, please let us know
15:13:46 <markus_sabadello> burn: There has been some discussion about the name of the Github repo, it currently is "did-core-registries". There is a proposal to change it to "did-spec-registries".
15:13:54 <selfissued> q+
15:13:58 <markus_sabadello> burn: If there is anyone with a particular concern, please let us know
15:14:00 <burn> ack selfissued
15:14:28 <markus_sabadello> selfissued: It should really just be "did-registries". I realize there is a conflicting term in the spec, but I think there is agreement to change that term
15:14:45 <dlongley> "did core spec" is not the same thing as "did spec"
15:14:47 <markus_sabadello> selfissued: The registries will contain more than just things from our spec. It will contain entries from other specs.
15:14:58 <dlongley> there will be many specs that talk about DIDs
15:15:04 <Orie> I am starting to agree with that, if we can get a shorter name that won't change
15:15:05 <Justin_R> q+
15:15:07 <markus_sabadello> burn: Let's allow a bit of discussion now
15:15:09 <burn> ack Justin_R
15:15:09 <Orie> thats better
15:15:19 <burn> zakim, what color is your bikeshed?
15:15:19 <Zakim> I think Prussian blue
15:15:29 <Orie> q+
15:15:39 <markus_sabadello> Justin_R: First I agreed with selfissued that "did registries" is a more generic name, but I think there's a problem with that sounding like a "place for registering DIDs"
15:15:42 <burn> q?
15:15:59 <markus_sabadello> Justin_R: "did-spec-registries" (spec = not just the core spec) does a better jobs
15:16:03 <manu> q+ to note we straw polled "DID Registries"
15:16:04 <dlongley> +1 to what Justin is saying, there will be many specs talking about DIDs beyond the did-core spec.
15:16:09 <burn> ack Orie
15:16:14 <markus_sabadello> Justin_R: It's generally applicable
15:16:58 <markus_sabadello> Orie: I agree with selfissued that there is a reputational issue. As the registry gets filled with information that's not necessarily reviewed by this WG; it's going to be filled with a lot of material, this may reflect on the reputation of the WG
15:17:19 <dlongley> "where do i go to find specs on DIDs" <-- "The DID spec registries"
15:17:24 <burn> ack manu
15:17:24 <Zakim> manu, you wanted to note we straw polled "DID Registries"
15:17:33 <markus_sabadello> Orie: We should consider what this will look like a few years from now. Calling it "DID spec" may make it sound like "spec stuff", when in fact it's about extensions including method names, etc.
15:17:49 <gannan> gannan has joined #did
15:17:49 <markus_sabadello> manu: We did contemplate "DID registries", and there were multiple -1 during the special topic call.
15:18:41 <markus_sabadello> manu: One of the important things to consider is that "registries" is plural. What the document does is, if you care about implementing, this document will give you links of all your options. You can look up items (properties, methods, extensions, etc.) in the registries documents. You will get a pointer to the specification.
15:18:50 <drummond> drummond has joined #did
15:18:54 <drummond> present+
15:19:01 <drummond> q?
15:19:11 <burn> zakim, close the queue
15:19:11 <Zakim> ok, burn, the speaker queue is closed
15:19:16 <markus_sabadello> manu: All other names we have considered so far (e.g. "DID registries") are too generic, and people come to wrong conclusions on what the names mean
15:19:21 <gannan> present+
15:19:34 <drummond> +1 to "DID Specification Registries"
15:20:00 <markus_sabadello> burn: Which of the following options do you like the LEAST?
15:20:12 <burn> Please list which of these three options for the repo you like the **least**:  did-core-registries, did-spec-registries, did-registries
15:20:22 <selfissued> did-core-registries
15:20:23 <drummond> did-registries
15:20:24 <manu> did-registries the least
15:20:24 <Orie> did-core-registries
15:20:27 <ivan> -1 to did-core
15:20:27 <dbuc> did-registries
15:20:28 <Justin_R> did-core-registries
15:20:34 <dmitriz> did-core-registries
15:20:34 <Eugeniu_Jolocom> did-registries
15:20:35 <kimhd> did-core-registries
15:20:37 <gannan> did-registries
15:20:37 <identitywoman> did-core-registries
15:20:39 <brent> did-core-registries
15:20:42 <dlongley> did-core-registries
15:20:42 <burn> did-core-registries
15:20:52 <jonathan_holt> 0, I've already finished painting
15:21:06 <markus_sabadello> burn: Winner for "least liked" seems to be did-core-registries
15:21:19 <burn> please list which you prefer of did-spec-registries or did-registries
15:21:21 <drummond> did-spec-registries
15:21:21 <dbuc> did-spec-registries
15:21:22 <selfissued> did-registries
15:21:23 <dlongley> did-spec-registries
15:21:25 <manu> did-spec-registries
15:21:27 <kimhd> did-spec-registries
15:21:29 <gannan> did-spec-registries
15:21:30 <identitywoman> did-spec-registires
15:21:30 <Eugeniu_Jolocom> did-spec-registries
15:21:32 <markus_sabadello> did-spec-registries
15:21:35 <Orie> did-spec-registries
15:21:35 <brent> did-spec-registries
15:21:35 <Justin_R> 0
15:21:39 <dmitriz> did-spec-registries
15:21:45 <ivan> 0
15:22:06 <burn> PROPOSED: Rename the did-core-registries GitHub repo to did-spec-registries
15:22:08 <markus_sabadello> burn: There's a pattern here
15:22:19 <burn> +1
15:22:20 <manu> +1
15:22:22 <gannan> +1
15:22:26 <Orie> +1
15:22:26 <dlongley> +1
15:22:26 <kimhd> +1
15:22:29 <markus_sabadello> +1
15:22:30 <drummond> +1
15:22:32 <ivan> +1
15:22:33 <Eugeniu_Jolocom> +1
15:22:35 <selfissued> 0
15:22:45 <brent> +1
15:22:48 <burn> RESOLVED: Rename the did-core-registries GitHub repo to did-spec-registries
15:22:59 <ivan> action ivan to rename the github registry
15:23:05 <burn> Topic: Testing
15:23:14 <ivan> action: ivan to rename the github registry
15:23:30 <markus_sabadello> burn: manu I think you wanted to talk about testing, we haven't had this discussion yet
15:23:54 <markus_sabadello> manu: we're trying to figure out how we are going to test the specification going into CR phase
15:24:09 <markus_sabadello> manu: we've had some assumptions about testing, but recent PRs suggest we needed to have a group discussion
15:24:22 <markus_sabadello> manu: There are many ways to test a spec when going through W3C standardization; I'm going to talk about 2 ways
15:25:06 <markus_sabadello> manu: We're trying to get WG feedback on what they would prefer; this isn't an A or B decision. There are many variations. We'd like to know what results the WG would like to see from testing.
15:25:18 <ivan> q+ on what testing means for a W3C CR phase
15:25:26 <markus_sabadello> manu: Once we have some feedback from the WG, it may make future discussions about testing easier; once we know what kinds of results we want.
15:25:32 <burn> zakim, open the queue
15:25:32 <Zakim> ok, burn, the speaker queue is open
15:25:44 <markus_sabadello> manu: This will help the editors to determine if certain statements in the spec are testable.
15:25:47 <ivan> q+ on what testing means for a W3C CR phase
15:26:01 <markus_sabadello> manu: (going to share my screen, but will also share links in IRC)
15:26:17 <burn> ack ivan
15:26:17 <Zakim> ivan, you wanted to comment on what testing means for a W3C CR phase
15:26:38 <ivan> I am and have problems
15:27:29 <markus_sabadello> manu: The specification we have right now - We thought it will largely be a data model with concrete representations, and that we would test syntax and data formats.
15:27:50 <markus_sabadello> manu: Since the WG started, there has been a desire to talk about the resolution process, and potentially testing against actual implementations.
15:28:41 <markus_sabadello> manu: In the VC WG, there were a number of things that people were not happy about in the test suite. We tested the data model, but there was still a lot missing for real interop (as discovered during the recent DHS SVIP program)
15:28:55 <markus_sabadello> manu: There were some gaps regarding concrete tooling.
15:29:16 <markus_sabadello> manu: In W3C, there are many groups that only do vocabulary testing
15:29:28 <manu> https://w3c.github.io/wot-thing-description/testing/report.html#impl-ercim
15:29:42 <markus_sabadello> manu: (showing Web of Things Implementation Report)
15:30:06 <burn> q?
15:30:26 <markus_sabadello> manu: The WoT WG released this Implementation Report. Their spec is a data model called (Thing Description), which is a data model used by some corporations to express things in the world (dimmers, signs, etc.)
15:30:45 <markus_sabadello> manu: It was a vocabulary spec, looked a bit like the DID Core spec, with an abstract data model, attributes, etc.
15:31:11 <markus_sabadello> manu: In their report, the first thing they have are statements by companies on whether they support the specification (self reported; there is no test suite).
15:31:53 <markus_sabadello> manu: Another thing they did is that for each normative statement in the specification, (e.g. "... the type of ... MUST be a JSON array")
15:32:14 <markus_sabadello> manu: They had an automated test for each statement, e.g. to test if ... is indeed a JSON array
15:32:25 <markus_sabadello> manu: They didn't run it against a live algorithm, they just tested static documents.
15:32:44 <markus_sabadello> manu: There were both automatic and manual tests.
15:33:29 <markus_sabadello> manu: E.g. "... each string MUST be processed independently". This was tested manually via self-reporting. Companies reported whether or not they did this.
15:34:23 <markus_sabadello> burn: Just want to point out, if you look at some of these statements, not everyone reported as passing. If you're worried about cheating, this is typically not a big issue during spec development.
15:34:42 <markus_sabadello> manu: There are tests that are only passed by a single company.
15:34:55 <markus_sabadello> manu: Another example of testing is Activity Streams.
15:35:20 <markus_sabadello> manu: Activity Streams is for decentralized social networking activity (articles, audios, likes, etc.)
15:35:44 <markus_sabadello> manu: There is vocabulary of terms.
15:36:01 <markus_sabadello> manu: There is a table with "P" (producing) and "C" (consuming) entries.
15:36:17 <markus_sabadello> manu: (showing an Implementation Report)
15:36:35 <markus_sabadello> manu: This is self-reported, there is only "y" (we implement this) or "n"
15:36:50 <burn> What self-reported tells you is whether the implementer cares about the feature
15:36:52 <jonathan_holt> q+
15:36:56 <burn> ack jonathan_holt
15:37:18 <markus_sabadello> jonathan_holt: I suppose most of this is looking at the structure of the data model. Can this be automated with JSON schema and CDDL?
15:37:28 <Justin_R> q+
15:37:31 <markus_sabadello> manu: Yes, there is a question do you want humans to determine this, or determine it automatically?
15:38:04 <burn> ack Justin_R
15:38:41 <markus_sabadello> Justin_R: It's a bit of a false dichotomy that we have to choose between human reporting, and automatic testing. There are options to combine them.
15:39:12 <markus_sabadello> manu: To underscore Justin_R 's point, WoT is an example of that. They have automated tests, and manual tests. They use JSON schema.
15:39:27 <markus_sabadello> manu: They passed the W3C Recommendation Track.
15:40:17 <markus_sabadello> manu: Another example is JSON-LD 1.1. This has a fairly brutal test suite. There are hundreds of tests, they are all programmatic. You need to implement an actual driver into the test suite, and you have to run every single test.
15:40:36 <markus_sabadello> manu: Some tests pass, some fail (boolean yes/no result).
15:40:54 <markus_sabadello> manu: You take your implementation, and the test suite runs every single one of the tests against your implementation.
15:41:14 <markus_sabadello> manu: Everything in the spec is a testable statement that is reflected in the test suite.
15:41:47 <ivan> q+
15:41:48 <Justin_R> q+ to talk about one such kind of hybrid approach used out there
15:42:04 <markus_sabadello> manu: The question to the group is, do we want self-reporting only, do we want purely test-driven, or a hybrid, or something else?
15:42:10 <burn> Our actual minimum required goal for the specification to exit the Candidate Recommendation phase (later in our process) is to test the spec, not implementations.  We need to at least see 2 implementations of each feature.  Ideally we may also want to show some interop.
15:42:18 <burn> ack ivan
15:42:25 <jonathan_holt> q+
15:42:30 <markus_sabadello> ivan: I think before making the choice we have to understand what testing really means and what its goal is in the process.
15:42:57 <markus_sabadello> ivan: From a W3C PoV, the goal of CR testing is to test the specifications. It's not necessarily a tool to test or rank implementations.
15:43:26 <markus_sabadello> ivan: Its goal is to test if the specification is correct, to test if it can be implemented independently.
15:43:34 <manu> forgot to put links in IRC
15:43:36 <manu> https://www.w3.org/2017/02/social/implementations/as2/
15:43:40 <manu> https://github.com/w3c/activitystreams/blob/master/implementation-reports/pubstrate.md
15:43:44 <manu> https://w3c.github.io/json-ld-api/reports/
15:43:47 <markus_sabadello> ivan: The spec must be implemetable based on the spec text alone, without additional knowledge.
15:44:03 <markus_sabadello> ivan: It has to be such that each feature based on the spec text is unambiguous.
15:44:07 <manu> q+ to note what we have today for the DID Test Suite.
15:44:12 <markus_sabadello> ivan: This has to be reported back by the implementation.
15:44:23 <Orie> 2 independent implementations of the test suite? or of a did method?
15:44:32 <markus_sabadello> ivan: We also have to prove that the feature we have there makes sense, and that implementations want to use it.
15:44:51 <markus_sabadello> ivan: E.g. if a vocabulary has terms that nobody uses, then that doesn't make sense.
15:45:17 <markus_sabadello> ivan: Looking as manu 's WoT example, this seems to say "yes we want to use these features and we plan to deploy them", and this has been done by more than one implementation
15:45:31 <markus_sabadello> ivan: I was surprised to see an entry that was only supported by a single implementation.
15:45:47 <yoshiaki> yoshiaki has joined #did
15:46:11 <markus_sabadello> ivan: In the procedural JSON-LD case, (I implemented RDFa a while ago) then this was a test suite that was useful for the implementation itself.
15:46:22 <markus_sabadello> ivan: It's fine to have this, but it's not a requirement for a CR Phase testing.
15:46:43 <dlongley> Orie: 2 independent implementations of every normative statement in the spec(s)
15:47:05 <markus_sabadello> ivan: So the voluntary reports are fine. We rely on the fact that implementations come in because they want to tell us that the specification is correct. We believe they are not motivated to "cheat".
15:47:24 <burn> What dlongley said
15:47:56 <manu> q?
15:47:59 <markus_sabadello> dlongley: We need 2 implementations of each normative statement.
15:48:01 <burn> ack Justin_R
15:48:01 <Zakim> Justin_R, you wanted to talk about one such kind of hybrid approach used out there
15:48:02 <markus_sabadello> ivan: Exactly
15:48:18 <Orie> so ... thats a test suite for normative statements.
15:48:31 <Orie> and thats 2 test suite implementations.
15:48:33 <markus_sabadello> Justin_R: It's not necessarily obvious what is under test, when we say we need to test a statement. We are defining on either side of a process.
15:48:45 <markus_sabadello> Justin_R: We are testing DIDs, DID URLs, DID document; potentially DID URL dereferencing
15:49:01 <markus_sabadello> Justin_R: This does not imply that we have to test DID resolution implementations in any automatic way.
15:49:01 <dlongley> Orie: or self-asserted/manual claims from implementers that they implement the statements -- there's a wide range of acceptable "types of tests" -- it's up the WG to decide how to test
15:49:40 <manu> q+ to have opinions as an Editor... and then possibly have opinions as an implementer. :)
15:49:56 <Justin_R> https://www.certification.openid.net/plans.html?public=true
15:49:57 <markus_sabadello> Justin_R: This goes into the DID resolution contract discussion. We need to test that the contract definitions are defined correctly (what goes in, what comes out). But this doesn't mean we have to plug in an actual implementation. It can be a useful tool to do that, but that's not actually what we're testing. We're testing how well the specification is defined.
15:50:03 <dlongley> Orie: obviously many of us (including you and me) would want to see two independent implementations passing each test in the test suite (note that for each test, the two implementations could be different, so long as each test gets at least two)
15:50:35 <markus_sabadello> Justin_R: These are OpenID Foundation tests. People have published these for their results.
15:50:42 <markus_sabadello> Justin_R: You can view the logs and see details.
15:51:08 <markus_sabadello> Justin_R: You can see in a lot of detail everything that has been automatically tested, plus results.
15:51:35 <markus_sabadello> Justin_R: These are technically self-asserted, but there is a process for making the automatable portions available. This is a hybrid approach.
15:51:36 <burn> q?
15:51:40 <burn> ack jonathan_holt
15:51:53 <markus_sabadello> jonathan_holt: I'm a big fan of test-driven (incl. behavior-driven) development.
15:52:39 <burn> q+ to explain what we are doing (not having tests drive spec at this point)
15:52:41 <markus_sabadello> jonathan_holt: I'm worried we're chasing our tails. The VC spec was changing, the core architecture was changing (e.g. proofs, signatures). I think the challenge is if we start driving with tests, we have to finalize that first and then decide what is in Core, what is in registries.
15:52:46 <burn> zakim, close the queue
15:52:46 <Zakim> ok, burn, the speaker queue is closed
15:52:50 <manu> q- later
15:52:58 <markus_sabadello> jonathan_holt: I think it would be valuable to automate validating proofs
15:52:59 <burn> ack manu
15:52:59 <Zakim> manu, you wanted to note what we have today for the DID Test Suite. and to have opinions as an Editor... and then possibly have opinions as an implementer. :)
15:53:09 <burn> ack burn
15:53:09 <Zakim> burn, you wanted to explain what we are doing (not having tests drive spec at this point)
15:53:14 <manu> q+ to say you wanted to note what we have today for the DID Test Suite. and to have opinions as an Editor... and then possibly have opinions as an implementer. :)
15:53:44 <markus_sabadello> burn: jonathan_holt , right now we are not proposing test-driven development. In new specifications, it is common to do the work the way we have been doing it so far.
15:54:02 <markus_sabadello> burn: There will come a point when we are going to require tests for any changes, but this is usually after feature freeze.
15:54:16 <rhiaro> regrets+
15:54:25 <markus_sabadello> burn: We do need to be talking about testing in general. E.g. with the DID Resolution contract, it's important that the group understands what testing means.
15:54:36 <burn> present+
15:54:48 <markus_sabadello> manu: I wanted to highlight what we have today. We do have a DID test suite, many people don't realize this. It's out of date, but we do have one.
15:54:48 <selfissued> When is the next special topic call?
15:55:13 <burn> Next topic call is this Thursday at the regular noon ET / 9 PT time.
15:55:14 <markus_sabadello> manu: We approached this by saying, this is a data model test suite, so we're going to have automated tests for syntax and data model.
15:55:35 <markus_sabadello> manu: More recently, the DID resolution contract has come up.
15:55:36 <manu> https://w3c-ccg.github.io/did-test-suite/
15:55:39 <manu> https://w3c-ccg.github.io/did-test-suite/implementations/
15:56:12 <markus_sabadello> manu: Another thing I wanted to mention, as an editor, at some point the editors will go through the document and determine the type of testing each normative statement is going to receive.
15:56:33 <markus_sabadello> manu: You look at a normative statement and ask "How am I going to test this? In an automated way, or by self-reporting"?
15:56:50 <markus_sabadello> manu: We did this for VC, and for JSON-LD, and we will do it for this spec.
15:57:19 <selfissued> The OpenID virtual workshop is at 9am Thursday.  So I'll be skipping that one.
15:57:28 <markus_sabadello> manu: Now as an implementor, I want to make sure we generate a test suite that generates yes/no results, whether or not an implementations supports a specific normative statement.
15:58:01 <markus_sabadello> manu: When it comes to things like what Justin_R pointed out reg. hybrid models, fundamentally we want this type of testing
15:58:27 <markus_sabadello> manu: We want people to use automatic test suite and demonstrate that they are 100% conformant with the spec. I want our group to aim for this.
15:58:56 <markus_sabadello> manu: With VCs, we may have missed the mark, people wrote custom test code instead of testing their actual implementation.
15:59:29 <markus_sabadello> manu: We have real DIDs, we have real DID documents, I would like our test suite to pulls in these real systems and test them; as opposed to a test suite that only tests the spec itself.
15:59:43 <markus_sabadello> manu: I'd like to see broad testability for real interop.
15:59:45 <Orie> q+ to describe tests at DIF / Regististries
15:59:47 <ivan> q+
16:00:05 <manu> Yes, I think we should do far more than what we're required to do.
16:00:10 <markus_sabadello> burn: Reminder what ivan told us is what we're required to do, vs. what manu told us can be very good for the industry.
16:00:32 <manu> present+
16:00:40 <drummond> present+
16:00:40 <identitywoman> present+
16:01:02 <ivan> zakim, end meeting
16:01:02 <Zakim> As of this point the attendees have been burn, ivan, jonathan_holt, dlongley, Orie, manu, dbuc, chriswinc, markus_sabadello, identitywoman, David_Ezell_Conexxus, brent, dmitriz,
16:01:05 <Zakim> ... Justin_R, kimhd, Eugeniu_Jolocom, selfissued, dezell, drummond, gannan
16:01:05 <Zakim> RRSAgent, please draft minutes
16:01:05 <RRSAgent> I have made the request to generate https://www.w3.org/2020/05/19-did-minutes.html Zakim
16:01:07 <Zakim> I am happy to have been of service, ivan; please remember to excuse RRSAgent.  Goodbye
16:01:11 <Zakim> Zakim has left #did
16:01:57 <ivan> probably...
16:02:08 <ivan> rrsagent, bye
16:02:08 <RRSAgent> I see 1 open action item saved in https://www.w3.org/2020/05/19-did-actions.rdf :
16:02:08 <RRSAgent> ACTION: ivan to rename the github registry [1]
16:02:08 <RRSAgent>   recorded in https://www.w3.org/2020/05/19-did-irc#T15-23-14