15:40:42 <RRSAgent> RRSAgent has joined #did
15:40:42 <RRSAgent> logging to https://www.w3.org/2021/02/16-did-irc
15:40:45 <Zakim> RRSAgent, make logs Public
15:40:47 <Zakim> please title this meeting ("meeting: ..."), ivan
15:40:50 <ivan> Meeting: DID WG Telco
15:40:50 <ivan> Chair: brent
15:40:50 <ivan> Date: 2021-02-16
15:40:50 <ivan> Agenda: https://lists.w3.org/Archives/Public/public-did-wg/2021Feb/0009.html
15:40:50 <ivan> ivan has changed the topic to: Meeting Agenda 2021-02-16: https://lists.w3.org/Archives/Public/public-did-wg/2021Feb/0009.html
15:58:49 <ivan> present+
15:58:49 <ivan> present+ shigeya_
15:58:50 <ivan> present+ TallTed
15:59:14 <justin_r> justin_r has joined #did
16:00:06 <ivan> present+ justin
16:00:06 <phila> phila has joined #did
16:00:27 <ivan> present+ dlongley
16:01:04 <ivan> present+ manu
16:01:21 <ivan> present+ brent
16:01:29 <ivan> present+ phila
16:01:34 <ivan> present+ orie
16:01:56 <ivan> present+ Geunhyung_Kim
16:02:07 <ivan> present+ drummond
16:02:12 <GeunHyung_Kim> GeunHyung_Kim has joined #did
16:02:18 <markus_sabadello> markus_sabadello has joined #did
16:02:20 <ivan> present+ markus_sabadello
16:02:28 <GeunHyung_Kim> present+
16:02:28 <ivan> present+ wayne
16:02:33 <wayne> present+
16:02:37 <drummond> drummond has joined #did
16:02:44 <drummond> present+
16:02:48 <drummond> scribe+
16:03:42 <drummond> brent_: Agenda review: details about special topic call, notice about deferred issues, tests, process for Notes, and then a review of subtantive PRs
16:03:51 <ivan> present+ selfissued
16:04:03 <ORie> ORie has joined #did
16:04:06 <ivan> topic: special topic call
16:04:11 <drummond> ...skipping intros/reintros
16:04:21 <drummond> ...special topic call is today at 6PM EST
16:04:22 <ivan> present+ burn
16:04:33 <drummond> ...the topic will be a working session on PRs
16:04:49 <ivan> topic: notice to the group deferred issues
16:04:51 <brent_> https://github.com/w3c/did-core/issues?q=is%3Aopen+is%3Aissue+label%3Adefer-v2
16:05:01 <drummond> ...notice to the WG: a number of issues are labeled as "Deferred"
16:05:13 <drummond> ...these are all issues being deferred to a future version of the spec
16:05:14 <ivan> Topic: writing tests
16:05:20 <justin_r> present+
16:05:33 <drummond> ...we have a test suite due to the labors of a very few number of contributors
16:05:35 <manu> q+ on tests
16:05:46 <brent_> ack manu
16:05:46 <Zakim> manu, you wanted to comment on tests
16:05:49 <drummond> ...now is the time for others to volunteer and contribute
16:06:05 <selfissued__> selfissued__ has joined #did
16:06:09 <JoeAndrieu> JoeAndrieu has joined #did
16:06:29 <drummond> manu: I would prefer if we got concrete commitments for specific tests for specific sections of the spec
16:06:36 <selfissued___> selfissued___ has joined #did
16:06:37 <manu> https://w3c.github.io/did-core/
16:06:40 <selfissued___> present+
16:06:45 <JoeAndrieu> present+
16:07:08 <drummond> ...the spec is fairly stable, so the expectation is that you as an implementer would commit to write the tests for a specific section
16:07:09 <agropper> agropper has joined #did
16:07:14 <markus_sabadello> q+
16:07:22 <drummond> ...that includes all normative MUST statements in that section
16:07:24 <agropper> present+
16:07:43 <drummond> ...it would also be good for WG members to note that you plan to implement those tests
16:07:55 <drummond> ...please only volunteer if you fully intend to implement
16:08:02 <brent_> ack markus_sabadello
16:08:02 <ivan> present+ JoeAndrieu
16:08:08 <ivan> present+ dbuc
16:08:10 <drummond> ...this helps identify anything that may be at risk
16:08:13 <ivan> present+ agropper
16:08:14 <markus_sabadello> https://github.com/w3c/did-test-suite/issues
16:08:34 <drummond> markus_sabadello: We have been keeping track of who has been saying they will commit to what tests
16:08:38 <manu> q+
16:08:54 <drummond> brent_: For example, Transmute has made certain commitments and so has Digital Bazaar
16:09:19 <brent_> ack manu
16:09:23 <drummond> ...also, this helps us know who is planning to implement what sections, and what we might need to mark at risk
16:09:23 <ivan> present+ rhiaro ]
16:09:37 <ivan> s/]//
16:09:48 <drummond> manu: ideally we would be tracking these in one issue
16:09:56 <dbuc> dbuc has joined #did
16:10:02 <dbuc> present+
16:10:09 <dbuc> I have tests for the equiv sections, Manu
16:10:11 <drummond> ...Manu would be like to get that we need to get volunteers for the other sections
16:10:26 <drummond> ...so it's very important that other member companies step up
16:10:26 <dbuc> Because I know how much you like it ;)
16:10:50 <drummond> brent_: The test suite is how we measure multiple implementations. Without it we won't exit CR
16:10:58 <ivan> Topic: call for implementations
16:11:18 <drummond> brent_: This is the official call for implementations
16:11:25 <drummond> ...this is the time to implement
16:11:37 <drummond> ...the way to do that is via commitments to the test suite
16:11:55 <drummond> ...we also want to get commitments to DID usage
16:11:59 <phila> q+ to ask about timeline for implementation reports
16:12:22 <brent_> ack phila
16:12:22 <Zakim> phila, you wanted to ask about timeline for implementation reports
16:12:29 <drummond> ...there are a number of different DID methods and usages in the wild—reporting those is also very helpful
16:12:55 <manu> q+
16:13:02 <brent_> ack manu
16:13:07 <drummond> phila: GS1 is planning to implement. Starting a 120 day program to do that. What's the timeline for completing implementation reports?
16:13:52 <wayne> q+
16:13:55 <drummond> manu: In theory we go into CR roughly the beginning of March. The shortest period is 60 days to get a first round of feedback. Then typically there will be a second round.
16:14:04 <drummond> ...so that timeframe should line up.
16:14:11 <brent_> ack wayne
16:14:11 <drummond> phila: Yes, that should work
16:14:18 <drummond> brent_: I second that timeline
16:14:26 <dbuc> q+
16:14:37 <ORie> Where is the latest list of normative statements?
16:14:38 <brent_> ack dbuc
16:14:40 <drummond> wayne: My company continues to commit to test suite conformance.
16:14:57 <wayne> our repo: https://github.com/spruceid/didkit
16:15:08 <drummond> dbuc: Microsoft is ready to go into production, and willing to be part of testing and reporting on pieces of the implementations that we've done
16:15:15 <ORie> our repo: https://github.com/transmute-industries/did-core
16:15:24 <drummond> brent_: Thank you, we look forward to your contributions to the test suite
16:15:45 <drummond> ...We very much want support for tests in the earliest time frame possible
16:15:46 <markus_sabadello> DIF Universal Resolver with support for ~40 DID methods: https://github.com/decentralized-identity/universal-resolver
16:16:02 <ivan> topic: review note publication process
16:16:19 <drummond> brent_: We have a number of Notes in process
16:16:38 <drummond> ...as the editors of those Notes near completion, they should contact the editors
16:16:58 <drummond> ...then the authors should contact the chairs
16:17:27 <drummond> ...when the chairs believe the note is ready as a final version, they will provide a one-week notice to the WG
16:17:36 <drummond> ...after which the note will be published
16:17:55 <drummond> ...reminder: a Note does not need to reflect the consensus of the group
16:18:25 <ivan> topic: substantive PR-s
16:18:28 <brent_> https://github.com/w3c/did-core/pulls?q=is%3Apr+is%3Aopen+label%3Asubstantive
16:18:45 <drummond> brent_: There are 3 substantive PRs to review today
16:19:07 <drummond> ...these 3 PRs make substantive changes that either add or change normative text
16:19:21 <drummond> ...so we want to be sure they have consensus
16:19:21 <manu> q+ to discuss #644
16:19:31 <brent_> ack manu
16:19:31 <Zakim> manu, you wanted to discuss #644
16:19:36 <drummond> ...if you disagree with anything about these, please make constructive feedback
16:19:56 <drummond> manu: There have been a flurry of PRs as part of the editors making a final editorial pass
16:20:24 <drummond> ...everything through sections 1 to 5 have had a pass and are fairly stable
16:20:37 <drummond> ...section 6 - the representation section - should be done this week
16:20:54 <jonathan_holt> jonathan_holt has joined #did
16:20:57 <drummond> ...so close review of the first 5 sections is recommended
16:21:13 <drummond> ....the resolution section is still being reviewed/discussed
16:21:31 <ivan> present+ jonathan_holt
16:21:36 <drummond> ...one issue with the resolution section is that it is abstract so we are still trying to figure out how to make it concrete enough to test
16:22:01 <markus_sabadello> q+
16:22:21 <drummond> ...one approach is to say that the metadata structure that represents the abstract data model can be serialized so that it can then be translated into various representations
16:22:38 <drummond> ...in order to do that we are suggesting a change to the abstract data model
16:22:50 <drummond> ...up to this point it has only been about DID documents
16:23:27 <drummond> ...but we are now considering making the abstract data model can represent other data structures that may be needed to create a specific representation
16:23:46 <drummond> ...and then you can use the representation production rules in order to create a concrete representation
16:24:04 <drummond> ...Markus and Justin have expressed some reservations about this
16:24:11 <brent_> ack markus_sabadello
16:24:14 <drummond> ...so we are open to discussing it
16:24:32 <drummond> markus_sabadello: I understand the motivation to make things more testable...
16:24:44 <brent_> q+ to clarify testable vs machine testable
16:25:01 <justin_r> q+ to talk about the line this crosses
16:25:01 <drummond> ...but the intention was to make the DID resolution section abstract because concrete resolution protocols were out of scope
16:25:18 <drummond> ...so it can be confusing to say that the abstract data model can be used for other things besides DID documents
16:25:46 <drummond> ...so Markus would prefer that the abstract data model stays focused on DID documents and not include metadata structures
16:25:51 <brent_> ack brent_
16:25:51 <Zakim> brent_, you wanted to clarify testable vs machine testable
16:25:56 <drummond> ...since metadata structures are "really something else"
16:26:29 <brent_> ack justin_r
16:26:29 <Zakim> justin_r, you wanted to talk about the line this crosses
16:26:43 <drummond> brent_: We have repeatedly used "testable" to be machine testable. However "testable" does not have to mean machine-testable.
16:27:10 <markus_sabadello> q+
16:27:14 <drummond> justin_r: What concerns me about this proposal is that it is "leaking requirements" of the test suite into the specification
16:27:16 <brent_> q+ to ask about the two possible approaches
16:27:42 <drummond> ...not all of the requirements of the test suite need to be represented in the spec
16:28:02 <drummond> ...for example, in the resolution spec we agreed to define "contracts"
16:28:14 <drummond> ...that does not mean that the core specification needs to go into this level of detailing
16:28:32 <drummond> ...and it does not mean the spec needs to change its nature to fit the needs of an implementation
16:28:34 <brent_> ack markus_sabadello
16:28:38 <drummond> ...this is dangerous and backwards
16:29:11 <drummond> markus_sabadello: In the section on metadata structures, we defined them the same way as the abstract data model where we use Infra and data maps
16:29:13 <manu> q+ to note that we said we'd do Resolution in the abstract, but then started using normative MUST language in the Resolution section, which the WG also said we wanted to be machine testable. We need to speak to specific language in the specification or have an alternate concrete proposal on the table that addresses everyone's concerns.
16:29:44 <drummond> ...so we do have examples for how this abstract data structure that could be represented in JSON
16:30:04 <drummond> ...so we could add some examples that show how the abstract data model can be made machine testable
16:30:06 <brent_> ack brent_
16:30:06 <Zakim> brent_, you wanted to ask about the two possible approaches
16:30:23 <jonathan_holt> q+
16:30:50 <drummond> brent_: Roughly the two approaches are either we need to describe how to make concrete the abstract parts of the spec in order to make them machine-testable...
16:31:05 <brent_> ack manu
16:31:05 <Zakim> manu, you wanted to note that we said we'd do Resolution in the abstract, but then started using normative MUST language in the Resolution section, which the WG also said we wanted
16:31:05 <drummond> ...or we alter the test suite in order to machine-test those statements
16:31:08 <Zakim> ... to be machine testable. We need to speak to specific language in the specification or have an alternate concrete proposal on the table that addresses everyone's concerns.
16:31:29 <drummond> manu: The issue we are in is that the group defined resolution in the abstract...
16:31:51 <drummond> ...but when the language was written for the resolution section, we used a whole bunch of normative MUST statements
16:32:11 <drummond> ...then we decided that we should have machine-testing of normative MUST statements
16:32:47 <drummond> ...so now we have a resolution section that needs testing
16:33:05 <drummond> ...so why don't we focus on the actual language of the PRs
16:33:26 <drummond> ...there are two proposals: make the normative statements testable OR
16:33:42 <drummond> ...put the logic for testing into the test suite and say that is good enough
16:33:42 <markus_sabadello> q+
16:34:00 <drummond> ...we need more input from the WG about which direction we should go
16:34:10 <drummond> ...and see what specific language we can agree on
16:34:37 <drummond> ...for example, Markus suggests that we can provide examples of how the abstract data model can be serialized
16:35:13 <brent_> ack jonathan_holt
16:35:14 <drummond> brent_: Let's move in the direction of looking at the PR text
16:35:19 <ORie> where is the list of normative requirements.
16:35:37 <drummond> jonathan_holt: Adding this detail this late in the game is not a good idea - it can be handled in the DID Spec Registries
16:36:14 <drummond> ...I added an example for CBOR that uses date time stamps using vanilla CBOR
16:36:27 <brent_> ack markus_sabadello
16:36:32 <drummond> ...so I added that detail to DID Spec Registries instead
16:36:56 <drummond> markus_sabadello: We should really look at the concrete impacts. I think this is a big change.
16:37:14 <manu> q+ to ask how this is a big change? Exactly what does this change?
16:37:25 <drummond> ...I understand the motivations, but I consider the metadata to be very different than the DID document data
16:37:41 <drummond> ...so keeping the abstract data model focused on the DID document is more precise
16:37:56 <drummond> ...it is not helpful to use the abstract data model for metadata
16:38:18 <manu> q+ to specify that we did define a generic INFRA data model
16:38:18 <drummond> ...we defined the abstract data model for DID documents, not for other metadata
16:38:27 <ORie> why is the type of did document an infra map... if its not an infra map?
16:38:44 <drummond> ...the metadata has some similarities, but it will be handled differently than the DID document data
16:39:00 <justin_r> +1 to markus_sabadello
16:39:00 <drummond> ...my proposal is to expand the examples of what the metadata would look like in JSON
16:39:09 <drummond> ...and then make it testable in the test suite
16:39:13 <manu> https://github.com/w3c/did-core/pull/644
16:39:14 <brent_> ack manu
16:39:14 <Zakim> manu, you wanted to ask how this is a big change? Exactly what does this change? and to specify that we did define a generic INFRA data model
16:39:18 <manu> https://github.com/w3c/did-core/pull/644/files
16:39:49 <drummond> manu: I would like people to look at the text that is under debate. WG members should read the PR.
16:40:06 <drummond> ...I disagree with what the abstract data model is supposed to do.
16:40:22 <drummond> ...it should apply to everything in the specification
16:40:54 <drummond> ...so from my perspective, the ADM was supposed to be for any data structure specified in DID Core
16:41:04 <justin_r> to me, the ADM was :always: meant to be :only: for DID Documents. that we use the same definitions for :other: data structures don't mean they're the same
16:41:33 <drummond> ...for those who are saying that the ADM should not apply, I'd like to know why we are "creating this other world" that needs to be respecified in the same way we define the ADM
16:41:38 <ivan> q+
16:41:56 <drummond> ...but we may just want to move on to other PRs at this point as we need the rest of the WG to engage on this issue
16:42:29 <drummond> ...but not deciding about this issue is going to slow down finishing this section
16:42:35 <brent_> ack ivan
16:42:43 <drummond> brent_: Note that the special topic call today will be a continuation of this discussion
16:43:12 <drummond> ivan: Taking it to a higher level: originally the goal of resolution was defining a contract
16:43:46 <drummond> ...regardless of whether INFRA can be used to define these contracts, we must ultimately make these contracts machine-testable
16:44:15 <drummond> ...so it has come up several times in the past few weeks which relies on human reports of implementability
16:44:21 <justin_r> +1 to ivan
16:44:24 <manu> q+ to note that we've removed many "purely abstract" things out of the spec because they were not testable... are we testing DID Resolution or not?
16:44:31 <drummond> ...and whether going to one extreme is the basis of the disagreement
16:44:39 <brent_> ack manu
16:44:39 <Zakim> manu, you wanted to note that we've removed many "purely abstract" things out of the spec because they were not testable... are we testing DID Resolution or not?
16:44:48 <drummond> q+
16:45:05 <drummond> manu: I worry that we are speaking out of both sides of our mouth
16:45:23 <ivan> q+
16:45:37 <JoeAndrieu> +1
16:45:45 <rhiaro> +1 DID resolution in a Note
16:45:46 <brent_> ack drummond
16:45:46 <drummond> ...we should either agree that we're not doing machine testability of the resolution section
16:45:48 <justin_r> -1
16:45:55 <JoeAndrieu> whoops I meant q+
16:46:03 <ORie> -1 to removing resolution... its 99% of what the spec is about...
16:46:03 <brent_> scribe+
16:46:27 <brent_> drummond: It feels like if we  lock in on what the requirements in the spec are for the contract
16:46:40 <justin_r> ORie: that's why it got added in a year ago, it doesn't make sense to talk about DIDs and Documents w/o talking about what's in between
16:46:50 <brent_> ... and if we say the contract is abstract, then maybe the way to test it can be described in the test suite
16:46:53 <justin_r> +1 to drummond
16:46:56 <brent_> q?
16:47:10 <brent_> ack ivan
16:47:13 <markus_sabadello> q+
16:47:54 <drummond> ivan: +1 to what Drummond said - in addition, the presentation of things whereby having a normative statement must be backed up my machine-testing is not a requirement
16:48:08 <manu> q+ to ask if we're testing Resolution or not?
16:48:08 <drummond> ...it is okay to have a normative statement that is not directly machine-testable
16:48:18 <drummond> ...we should be more liberal in that respect
16:48:52 <drummond> JoeAndrieu: I think the interpreted rule that all normative statements much be machine-testable is too restrictive
16:49:05 <dbuc> I strongly agree with Joe
16:49:15 <dbuc> Folks, JOE AND I STRONGLY AGREE
16:49:17 <brent_> ack markus_sabadello
16:49:29 <dbuc> this means it is the right thing, obviously
16:49:30 <drummond> ...the definition of a contract is that it will say what you must do, and whether or not it is machine-testable is a different issue
16:50:06 <ivan> q+
16:50:17 <drummond> markus_sabadello: Based on what others are saying here, I want to ask: is it acceptable to have normative statements in the spec that are not directly machine testable without additional information...
16:50:24 <manu> q+ to note why it's a bad idea to not test things in specifications.
16:50:46 <drummond> ...but that additional information is readily available in some additional documents
16:51:11 <brent_> +1 to Markus
16:51:12 <drummond> ...for example in other protocol specification documents in the W3C Credentials Community Group or at the Decentralized Identity Foundation
16:51:16 <brent_> ack manu
16:51:16 <Zakim> manu, you wanted to ask if we're testing Resolution or not? and to note why it's a bad idea to not test things in specifications.
16:51:25 <dbuc> q+
16:51:29 <drummond> manu: I'm confused now as to whether we are testing DID resolution or not
16:51:55 <drummond> ...some are staying that we shouldn't test it at all, vs. testing with some additional info that's not in the spec
16:52:00 <ORie> q+ to discuss machine testability
16:52:20 <justin_r> q+ to talk about the test suite
16:52:30 <drummond> ...I have been operating under the assumption that because there are so many normative statements in the resolution section, that we should make it all machine testable
16:52:33 <brent_> ack ivan
16:52:47 <drummond> ivan: First, to answer to Markus, I'm not sure I fully understand the question
16:53:03 <drummond> ...the implementation of the resolution contract should not depend on another spec or document
16:53:13 <drummond> ...the #1 question is whether the contract is fulfilled or not
16:54:01 <drummond> ...to reply to Manu, my view is that we have a contract definition. We can define "tests" that, for specific data, this is how the contract can be fulfilled and this is the response it should return
16:54:21 <drummond> ...but whether or not that is machine-testable is not required
16:54:35 <brent_> ack dbuc
16:54:36 <drummond> ...if it is machine-testable, that is good, but not required
16:54:51 <manu> q+ to note why machine testability is important, the highest bar, and what we should try to shoot for.
16:55:14 <drummond> dbuc: There are 3 classes of testability. 1) 100% testable via a local DID document. Fully deterministic.
16:55:59 <drummond> ...2) the class of untestable language, such as "you must not use data describing a human"
16:56:02 <brent_> ack ORie
16:56:02 <Zakim> ORie, you wanted to discuss machine testability
16:56:09 <justin_r> +1 to the coupling idea, that's what I've been saying all along
16:56:10 <markus_sabadello> Can't we use this in the test suite? https://w3c-ccg.github.io/did-resolution/#did-resolution-result
16:56:40 <drummond> ORie: I spent some time trying to implement the abstract data model this weekend and I'm starting to agree with some of what Justin and Markus are saying
16:56:55 <drummond> ...there is a class of tests that are not valuable to use as spec authors
16:57:05 <brent_> q?
16:57:20 <drummond> ...there probably needs to be a way to test what is in the spec without talking about a specific implementation
16:57:26 <manu> q-
16:57:28 <markus_sabadello> q+
16:57:41 <drummond> ...this is challenging because it requires some concrete implementation of the ADM in the test suite
16:58:00 <manu> q+ to speak to not lowering the bar.
16:58:00 <jonathan_holt> Orie: +1, that was extremely well stated!
16:58:06 <drummond> ...anyone who says that we should not test testable statements as long as there is some way to test them is harming the spec
16:58:20 <dbuc> We should test certain things with a default set of functions that implementers can put their own function bodies into them
16:58:25 <manu> Yes, +1 to Orie, that's the problem.
16:58:28 <drummond> ...the ADM is testable, but what's hard is that the language around the ADM how to interpret it
16:58:32 <manu> q-
16:58:46 <drummond> ...for example, if production works directly from the ADM, or does it take additional arguments
16:58:51 <markus_sabadello> q-
16:58:58 <drummond> ...so we have a problem here. There are people talking past each other.
16:58:59 <dbuc> for ex: you can test against in-mem default values, but allow devs to replace the function with their own DB fetch function to get the same values
16:59:14 <dbuc> that's still a deterministic test
16:59:20 <drummond> ...the solution is to gain clarity around the function signatures for the processes defined in the spec
16:59:23 <markus_sabadello> +1 to Orie that production is too vague right now
16:59:30 <drummond> ...then writing tests will be much easier
16:59:45 <drummond> brent_: This will be continued on the special topic call today. Please come.
16:59:53 <drummond> ivan: I will not be able to be there.
17:00:14 <markus_sabadello> ohhh
17:00:23 <ivan> zakim, end meeting
17:00:23 <Zakim> As of this point the attendees have been ivan, shigeya_, TallTed, justin, dlongley, manu, brent, phila, orie, Geunhyung_Kim, drummond, markus_sabadello, wayne, selfissued, burn,
17:00:24 <drummond> brent_: PR 644 is where we need to focus. Please do come to that call.
17:00:26 <Zakim> ... justin_r, selfissued___, JoeAndrieu, agropper, dbuc, rhiaro, ], jonathan_holt
17:00:26 <Zakim> RRSAgent, please draft minutes
17:00:26 <RRSAgent> I have made the request to generate https://www.w3.org/2021/02/16-did-minutes.html Zakim
17:00:29 <Zakim> I am happy to have been of service, ivan; please remember to excuse RRSAgent.  Goodbye
17:00:33 <Zakim> Zakim has left #did
17:01:55 <shigeya> shigeya has joined #did
17:02:00 <ivan> rrsagent, bye
17:02:00 <RRSAgent> I see no action items