22:52:40 <RRSAgent> RRSAgent has joined #did
22:52:40 <RRSAgent> logging to https://www.w3.org/2019/09/16-did-irc
22:52:41 <ivan> rrsagent, set log public
22:52:41 <ivan> rrsagent, this meeting spans midnight
22:52:41 <ivan> Meeting: DID Working Group F2F in Fukuoka — Second day
22:52:41 <ivan> Date: 2019-09-17
22:52:41 <ivan> Agenda: https://tinyurl.com/didwg-tpac2019-agenda
22:52:41 <ivan> ivan has changed the topic to: Meeting Agenda 2019-09-19: https://tinyurl.com/didwg-tpac2019-agenda
22:52:42 <ivan> Regrets+
22:52:42 <ivan> Chair: burn, brentzundel
22:52:42 <yoshiaki> yoshiaki has joined #did
22:59:57 <brent> brent has joined #did
23:00:05 <peacekeeper> peacekeeper has joined #did
23:14:05 <yoshiroy> yoshiroy has joined #did
23:16:29 <Chunming> Chunming has joined #did
23:23:38 <peacekeeper> peacekeeper has joined #did
23:23:53 <Chunming_> Chunming_ has joined #did
23:23:56 <peacekeeper> peacekeeper has joined #did
23:30:45 <Kangchan_> Kangchan_ has joined #did
23:31:10 <peacekeeper> peacekeeper has joined #did
23:32:11 <Arnaud> Arnaud has joined #did
23:32:11 <ivan> ivan has joined #did
23:32:26 <gkellogg> gkellogg has joined #did
23:32:37 <ivan> present+
23:33:03 <takuya> takuya has joined #did
23:33:05 <rhiaro> present+
23:34:18 <Kangchan_> present+
23:34:59 <ivan> present+ burn
23:35:11 <ivan> present+ brentzundel
23:35:42 <ivan> scribejs, set gkellogg Gregg Kellogg
23:35:59 <manu> present+
23:35:59 <ivan> guests+ gkellogg
23:36:49 <ivan> scribejs, set pamela Pamela Dingle
23:36:56 <ivan> guests+ pamela
23:37:00 <grantnoble> grantnoble has joined #did
23:37:16 <tplooker> tplooker has joined #did
23:37:18 <jay> jay has joined #did
23:37:25 <ivan> scribejs, set helen Helen Garneau
23:37:30 <ivan> guests+ helen
23:37:43 <ken> ken has joined #did
23:37:52 <ivan> present+ grantnoble
23:37:57 <ivan> present+ peacekeeper
23:38:06 <ivan> present+ ken
23:38:16 <gkellogg> present+
23:38:23 <ken> scribe: ken
23:38:30 <ivan> present+ tplooker
23:38:59 <ivan> present+ phila
23:39:19 <yancy> yancy has joined #did
23:39:20 <ken> brent: Review of agenda for today.
23:39:30 <peacekeeper_> peacekeeper_ has joined #did
23:39:37 <ken> ... We need scribes for later today.
23:39:53 <Dudley> Dudley has joined #did
23:39:56 <hhan8> hhan8 has joined #did
23:39:57 <ken> ... We will review resolution and other groups for joint sessions.
23:40:14 <peacekeeper> peacekeeper has joined #did
23:40:19 <peacekeeper> present+
23:40:22 <ken> ... Webex audio working?
23:40:27 <Dudley> present+ Dudley_Collinson
23:40:32 <ivan> present+ yancy
23:40:35 <drummond> drummond has joined #did
23:40:38 <igarashi> igarashi has joined #DID
23:40:41 <brent> slides url: https://docs.google.com/presentation/d/1ESS_6TuU7iHcAKkSB_py2zY5NJUKggs_uRDfEdl41HE/edit?pli=1#slide=id.g2a8b040676_0_27
23:40:42 <drummond> present+
23:40:53 <igarashi> present+
23:41:05 <phila> phila has joined #did
23:41:51 <ivan> -> https://www.w3.org/2019/did-wg/Meetings/Minutes/2019-09-15-did Yesterday's draft minutes
23:43:06 <ken> ivan: Yesterday's minutes are ready as a draft. Please review the names and WG membership status.
23:43:14 <Masa-JCB> Masa-JCB has joined #did
23:43:15 <mitja> mitja has joined #DID
23:43:45 <ken> ... If you are missing please report errors to Ivan.
23:43:52 <selfissued> selfissued has joined #did
23:44:06 <JoeAndrieu> JoeAndrieu has joined #did
23:44:07 <ivan> Topic: Test suite
23:44:12 <ken> Topic: Test Suite
23:44:32 <ken> brent: What are your thoughts about the test suite?
23:44:41 <ivan> present+ JoeAndrieu
23:44:57 <ivan> guests+ selfissued
23:45:11 <ken> manu: There is an existing test suite.
23:45:21 <ivan> scribejs, set selfissued Mike Jones
23:45:32 <jay> present+
23:45:38 <burn> burn has joined #did
23:45:57 <manu> https://github.com/w3c-ccg/did-test-suite
23:46:00 <ivan> scribejs, set jay Jay Kishigami
23:46:09 <ken> burn: Manu will look up what is ready already.
23:46:23 <ken> ... We need to decide when to do the work on it.
23:46:31 <ivan> guests+ jay
23:46:37 <gkellogg> q+
23:46:44 <ken> ... It can be counter productive when we are still arguing about features.
23:46:59 <manu> example of test suite output: https://w3c.github.io/vc-test-suite/implementations/
23:47:04 <ken> ... When we have set the features, then the test suite becomes critical.
23:47:11 <manu> q+ to provide what we have right now in the W3C CCG.
23:47:12 <JoeAndrieu> q+
23:47:15 <ken> ... Are we at that point?
23:47:17 <peacekeeper> q+
23:47:46 <ivan> ack gkellogg
23:48:08 <ken> gkellogg: I follow Dan's logic. But the biggest danger is that people we be afraid to tread.
23:48:42 <ken> ... Tests take a high degree of effort. At the time changes are made if there is insight as to the implications.
23:48:43 <Fuji> Fuji has joined #did
23:49:11 <ken> ... Perhaps a list of tests could accompany a PR to describe what needs to be tested would help.
23:49:16 <brent> ack gkellogg
23:49:29 <selfissued> q+
23:49:29 <ken> manu: Andrew Jones has implemented a test suite.
23:50:06 <ken> ... In the VCWG we had a data model spec. It is similar to our DID spec. The VCWG test suite seemed to work.
23:50:12 <jserv--> jserv-- has joined #did
23:50:12 <ken> ... Examples:
23:50:23 <brent> q?
23:50:27 <brent> ack manu
23:50:27 <Zakim> manu, you wanted to provide what we have right now in the W3C CCG.
23:50:57 <yoshiaki> yoshiaki has joined #did
23:51:05 <ken> ... You create tests, and ask implementors to test their implementations against the tests.
23:51:21 <ken> ... At the end we collect all the results into an implementation report.
23:51:23 <manu> https://w3c.github.io/vc-test-suite/implementations/
23:51:40 <ken> ... This is what an implementation report can look like.
23:52:18 <ken> ... In the basic document section, "context must be..." and shows the number of implemntations that pass a particular test.
23:52:31 <ken> ... Checks and x's show status.
23:53:03 <ender> ender has joined #did
23:53:08 <manu> https://github.com/w3c-ccg/did-test-suite/tree/add-tests
23:53:17 <ken> ... We have a similar thing for the DID WG already.
23:53:30 <manu> https://github.com/w3c-ccg/did-test-suite/tree/add-tests/test/latest
23:53:31 <ken> ... Andrew Jones added tests for the current DID spec.
23:54:07 <ken> ... There are identifier and doc tests.
23:54:32 <ken> ... Do we want to use this as a baseline?
23:54:43 <brent> ack JoeAndrieu
23:54:47 <ken> JoeAndrieu: Thanks! We should build on it.
23:55:29 <gkellogg> q+
23:55:31 <ken> ... Until the last CR, there is a possibility for changes. There is no single point when we know the spec is done.
23:56:02 <ken> burn: There is a requirement that when we enter CR, we must state the requirement for testing.
23:56:25 <ken> ... A typical guideline is 2 implementors for each feature.
23:56:47 <ken> ... To enter PR you must meet our stated requirements.
23:57:01 <ken> ... We will have a test suite to enter Cr.
23:57:02 <brent> ack peacekeeper
23:57:25 <YangHau> YangHau has joined #did
23:57:42 <ken> peacekeeper: We can expect some small changes, but the overall structure is fairly mature.
23:58:01 <ken> ... Small changes can be made to the test suite as changes are made in the spec.
23:58:02 <brent> ack selfissued
23:58:47 <ken> selfissued: While MS is not an official member yet, I like to make sure that is one clear way to do something.
23:59:17 <ken> ... When I can I like to make things as simple as possible to enhance interoperability.
23:59:50 <ken> ... If we have someone actively changing the suite, the is great.
00:00:16 <Youngsun> Youngsun has joined #did
00:00:22 <ken> ... Markus said resolution is out of scope, so how can we fully test the rules?
00:00:49 <drummond> q+
00:00:50 <ken> ... Although it is not in the scope of the spec, we could decide to include a resolution interop test.
00:01:19 <brent> ack gkellogg
00:01:22 <minami> minami has joined #did
00:01:39 <yoshiaki> yoshiaki has joined #did
00:01:42 <manu> q+ to mention "one common DID method for testing"...
00:01:46 <manu> q+ to respond to Gregg
00:01:48 <ken> gkellogg: I suggest that we have some instructions on how to run the test suite for implementors.
00:02:19 <ken> ... Most implementors are more used to a data driven system.
00:02:23 <brent> q+ to outline decisions the group should consider
00:02:31 <ivan> q?
00:02:43 <ken> ... Data driven is easier than code drive.
00:02:44 <brent> ack drummond
00:03:04 <ken> drummond: I like Mike's suggestion regarding resolution in the test suite.
00:03:26 <ken> ... It is very useful to non-normatively cover this in the test suite.
00:03:29 <brent> ack manu
00:03:29 <Zakim> manu, you wanted to mention "one common DID method for testing"... and to respond to Gregg
00:03:39 <manu> Example of "How to run the test suite": https://w3c.github.io/vc-test-suite/
00:03:51 <ken> manu: Greg, instructions are here in the VC test suite.
00:03:51 <kaz> kaz has joined #did
00:04:05 <ivan> q+
00:04:17 <ken> ... In the 8-10 implementatinos seemed to work.
00:04:50 <ken> ... Input on stdin and output on stdout seemed to be simple enough.
00:05:05 <ken> ... Using RDFA was more complicated.
00:05:41 <ken> ... Mike and Drummond commented on resolution in the test suite.
00:06:10 <ken> ... We excluded it from the spec because of potential objections to the charter if they were included.
00:06:25 <tm> tm has joined #did
00:06:32 <ivan> s/RDFA/RDFa/
00:06:44 <peacekeeper> q+
00:06:45 <ken> ... We added tests for optional tests for signature formats even though they were extentions.
00:07:04 <ken> ... What DID method should we pick for testing?
00:07:18 <ken> ... We wanted to avoid a political fight over it.
00:07:33 <drummond> q?
00:07:47 <ken> ... Since then DID Peer and DID Key could be considered as a simple method type to test with.
00:07:53 <gkellogg> perhaps a “test” method, defined with specific behavior for running tests.
00:07:58 <burn> +1 manu to optional resolution tests, but we must not block group completion on disagreements around those tests
00:08:00 <ken> ... These would be optional tests.
00:08:03 <kaz> present+ Kaz_Ashimura
00:08:06 <JoeAndrieu> q+ to discuss test suites for DID Methods
00:08:09 <drummond> q+ to ask about basic scope of tests and talk about Peer DID and DID Key
00:08:16 <ken> brent: I am pleased with the conversation so far.
00:08:43 <ken> ... The questions we need to document and resolve are in these slides:
00:09:00 <brent> ack brent
00:09:00 <Zakim> brent, you wanted to outline decisions the group should consider
00:09:31 <selfissued> selfissued has joined #did
00:09:34 <yoshiaki> yoshiaki has joined #did
00:09:45 <brent> ack ivan
00:09:54 <selfissued> q+
00:09:55 <ken> ivan: In other groups we had two or three implemenations that accompanied the spec development.
00:10:11 <ken> ... This provided valuable feedback along the way.
00:10:27 <manu> q+ to say we have an implementation
00:10:32 <ken> ... It required acknowledgement of "changes will be required"
00:11:07 <ken> peacekeeper: With DID URLs, there is some functionality regarding selection of material from the DID document.
00:11:22 <brent> ack peacekeeper
00:11:28 <brent> ack JoeAndrieu
00:11:28 <Zakim> JoeAndrieu, you wanted to discuss test suites for DID Methods
00:11:28 <ken> ... This could be tested in a method-independent way.
00:12:08 <ken> JoeAndrieu: I would like to suggest that the method specific implementors should right the tests in an common framework.
00:12:22 <brent> ack drummond
00:12:22 <Zakim> drummond, you wanted to ask about basic scope of tests and talk about Peer DID and DID Key
00:12:23 <manu> q+ to note our charter said that we wouldn't do DID Methods, whatever that means...
00:12:28 <jc> jc has joined #did
00:12:33 <ivan> ack selfissued
00:12:46 <ken> drummond: In many ways it's the method that needs to test things.
00:12:58 <tplooker> tplooker has joined #did
00:13:15 <ken> ... Without resolution, all we can test the conformance to the DID ABNF and the contents of the DID doc.
00:13:31 <Masa-JCB> Masa-JCB has joined #did
00:13:33 <manu> q+ selfissued
00:13:35 <manu> q- later
00:13:49 <ken> ... This would be the only two tests to perform under the charter.
00:14:13 <brent> q?
00:14:14 <ken> ... Peer DID or Key DID would be good alternatives.
00:14:22 <brent> ack selfissued
00:14:31 <manu> q+ to note that Andrew is committed to keeping the test suite up to date
00:14:48 <manu> q+ phila
00:14:49 <ken> selfissued: Test suites seem to succeed when there are committed developers who stay current with the spec.
00:14:55 <manu> ack manu
00:14:55 <Zakim> manu, you wanted to say we have an implementation and to note our charter said that we wouldn't do DID Methods, whatever that means... and to note that Andrew is committed to
00:14:59 <Zakim> ... keeping the test suite up to date
00:15:43 <ken> manu: Reminder that DID methods are out of scope for the charter. These increase scope creep.
00:15:43 <manu> Out of scope: "Specific DID Method specifications or Protocol specifications"
00:15:49 <brent> q?
00:15:52 <gkellogg> q+
00:16:06 <ken> ... We have a little wiggle room.
00:16:21 <ken> ... I agree with Mike regarding test suite developers.
00:16:26 <burn> q+ to remind people that we cannot block group if disagreements on out-of-scope tests
00:16:59 <drummond> q?
00:17:06 <drummond> q+
00:17:06 <ken> ... Digital bazaar is committing a developer to making updates every 6 weeks. It works better when there are other devs involved.
00:17:21 <brent> ack phila
00:17:47 <ken> phila: We can't look at resolution.
00:18:14 <ken> ... The test suite as shown so far links directly to the implementation report.
00:18:51 <ken> ... We need at least some resolution to create an implementation report.
00:19:08 <ken> ... We built this thing that proves that the spec works.
00:19:14 <manu> q+ to note Markus' did resolver and did-io and the way the test suite works
00:19:20 <brent> ack gkellogg
00:19:32 <ken> ... There is a difference between tests and implementations.
00:20:08 <ken> gkellogg: Are there requirements for defining a DID method that state what must be done?
00:20:31 <burn> q+ to point out that we can decide what it means to test a DATA MODEL spec, and that could be done with assertions but no executable suite
00:20:33 <ken> ... Can we specify test runner requirements, such as retrieval?
00:20:42 <brent> q?
00:20:47 <ivan> q+
00:20:51 <burn> ack burn
00:20:51 <Zakim> burn, you wanted to remind people that we cannot block group if disagreements on out-of-scope tests and to point out that we can decide what it means to test a DATA MODEL spec, and
00:20:54 <Zakim> ... that could be done with assertions but no executable suite
00:21:28 <gkellogg> ack phila
00:21:31 <gkellogg> ack gkellogg
00:21:49 <ken> burn: With respect that we include that are optional because they are out of scope, if there is disagreement over them, I will have us take them out.
00:21:59 <ken> ... How do you test a data model?
00:22:10 <ken> ... What does that mean?
00:22:45 <ken> ... All that is required is that producers and consumers stated what elements they are able to generate or consume.
00:23:01 <jc> jc has joined #did
00:23:16 <brent> ack drummond
00:23:32 <dsr> dsr has joined #did
00:23:55 <ken> drummond: Re: manu's commitment regarding resources, Evernym is working on committing resources.
00:24:23 <brent> q?
00:24:32 <ken> ivan: Audio problems are going to be fixed in the break.
00:24:33 <manu> ack manu
00:24:33 <Zakim> manu, you wanted to note Markus' did resolver and did-io and the way the test suite works
00:24:50 <mitja> mitja has joined #did
00:25:13 <ken> manu: Optional tests regarding resolution, we have two independent resolvers.
00:25:39 <ken> ... We can use them to demonstrate DID resolution and interop.
00:26:05 <ken> ... The test suite is architected to callout to an implementation requesting an action with data.
00:26:59 <ken> ... Example: verify that this is a valid DID or DID doc. The implementation performs the action on the data and reports success/failure.
00:27:07 <brent> q?
00:27:15 <brent> q+
00:27:29 <ken> ... The is vague, but allows the implementation to do what it needs.d
00:27:57 <ken> ... We could add other actions to the driver, such as create
00:28:14 <ken> ... DID or verify DID.
00:28:24 <tplooker> q+
00:28:27 <ken> ... The test suite can handle it. Do we want to go there?
00:28:43 <drummond> Can we propose to start with the current CCG test suite?
00:28:49 <brent> ack ivan
00:28:51 <ken> ... As Dan said, disagreement will result in removal of tests.
00:29:08 <peacekeeper> q+
00:29:39 <tung> tung has joined #did
00:30:04 <ken> ivan: With regard to the DID doc, it is a json or json-ld document. It describes the vocabulary, not the actions.
00:30:10 <brent> q-
00:30:13 <brent> q+
00:30:35 <brent> zakim, close the queue
00:30:35 <Zakim> ok, brent, the speaker queue is closed
00:30:55 <ken> ... Some parts are only syntax. We must prove that multiple implementations use these terms.
00:31:19 <ken> ... From a process point of view, we only have to prove this.
00:31:53 <ken> ... It may be simpler from the charter point of view.
00:32:14 <ken> ... Having more than the charter requires is beyond the minimal requirements.
00:32:15 <brent> ack tplooker
00:32:55 <ken> tplooker: I think the tests can be a forcing function to drive compatibility.
00:33:39 <ken> ... I'm concerned about having another spec regarding resolvers, where are the boundaries between the DID spec and DID resolution?
00:33:55 <brent> ack peacekeeper
00:34:19 <burn> q+ to raise scary option of expanding group charter at some point to include resolution, etc.
00:34:39 <jc> jc has joined #did
00:34:48 <brent> DRAFT PROSOSAL: The DID WG will use the existing CCG DID test suite as a starting point for the DID WG test suite.
00:34:48 <ken> peacekeeper: We are finding that the data model can be represented using other than json-ld.
00:35:18 <brent> PROSOSED: The DID WG will use the existing CCG DID test suite as a starting point for the DID WG test suite.
00:35:18 <ken> ... They may be valid but not pass the test suite.
00:35:21 <manu> +1
00:35:22 <burn> +1
00:35:23 <yancy> +1
00:35:25 <JoeAndrieu> +1
00:35:25 <drummond> +1
00:35:28 <Dudley> +1
00:35:28 <grantnoble> +1
00:35:29 <ivan> +1
00:35:30 <peacekeeper> +1
00:35:30 <ken> ken: +1
00:35:31 <brent> +1
00:35:44 <rhiaro> +1
00:35:53 <tplooker_> tplooker_ has joined #did
00:35:57 <tplooker_> +1
00:36:04 <brent> RESOLVED: The DID WG will use the existing CCG DID test suite as a starting point for the DID WG test suite.
00:36:23 <ken> drummond: Thanks to Digital Bazaar for the work on the test suite.
00:36:56 <manu> q+ to be opinionated about the questions raised...
00:37:06 <brent> zakim, open the queue
00:37:06 <Zakim> ok, brent, the speaker queue is open
00:37:08 <manu> q+ to be opinionated about the questions raised...
00:37:09 <ken> brent: We have other questions on the slide to review.
00:37:16 <brent> ack brent
00:37:54 <ken> burn: If it looks like there is continuing and growing support within W3C, we could consider expanding the charter.
00:38:14 <ken> ... We should not focus on this now, but it is a possibility.
00:38:18 <drummond> +1 to this being something the WG should be open to considering.
00:39:02 <ken> manu: Regarding Dan's comment, yes the contention is reducing.
00:39:04 <brent> ack manu
00:39:04 <Zakim> manu, you wanted to be opinionated about the questions raised...
00:39:35 <ken> ... Now is the time to work on the tests in my opinion. Let's start now.
00:40:40 <ken> ... I suggest that any method that is pure key method could be used. Either DID Peer or DID key would work well with low controversy.
00:41:12 <ken> ... +1 to co-development of implementations.
00:41:40 <ken> ... We are expecting each method to support their own tests.
00:41:41 <JoeAndrieu> q+ to clarify suggestion about DID methods
00:41:59 <ken> ... Pulling in all methods would be problematic.
00:42:06 <brent> q?
00:42:11 <brent> ack JoeAndrieu
00:42:11 <Zakim> JoeAndrieu, you wanted to clarify suggestion about DID methods
00:42:13 <gkellogg> +1 to manu’s points
00:42:45 <drummond> -1 to the WG producing tests for DID methods with the possible exception of something like did:peer: or did:key:
00:42:50 <ken> JoeAndrieu: I agree with manu. I imagine that sov, btcr, etc. should write tests for the suite.
00:43:03 <drummond> q?
00:43:07 <ken> ... I don't think they should be included in the master suite.
00:43:20 <ken> brent: I agree with manu's thinking.
00:43:29 <ken> drummond:
00:43:39 <tplooker> tplooker has joined #did
00:43:40 <gkellogg> q+
00:44:12 <manu> q+ to note that we could use the existing test suite framework for doing that
00:44:24 <brent> q?
00:44:27 <brent> ack gkellogg
00:44:37 <dezell> dezell has joined #did
00:44:38 <ken> ... Does it make sense to recommend a method framework for the test suite?
00:45:13 <ken> gkellogg: I think we should have a single method, perhaps Peer DID or a subset of Peer DID.
00:45:21 <tplooker> q+
00:45:34 <brent> q+ to revisit the charter
00:45:35 <ken> ... Also a scaffold for other methods with other plugins.
00:45:52 <drummond> To put it different, I asked if the WG should recommend a test framework that DID method authors should use.
00:45:53 <brent> ack manu
00:45:53 <Zakim> manu, you wanted to note that we could use the existing test suite framework for doing that
00:45:53 <ken> ... An interop fest might be key to demonstrate interop.
00:46:12 <ken> manu: I think the existing test suite can do that.
00:46:24 <ken> ... The driver calls actions.
00:46:54 <ken> ... The actions could request the CRUD operations for the methods.
00:47:17 <ken> ... Or you could call resolve() for the methods.
00:47:32 <brent> q?
00:47:34 <ken> ... The framework exists for Create() and read()
00:47:49 <burn> q+ to agree that this DID method testing framework is in scope for the group
00:47:58 <ken> ... You can also specify optional additional test suites.
00:48:05 <burn> q-
00:48:23 <ken> ... Each community can create its own tests.
00:48:25 <brent> ack tplooker
00:48:54 <selfissued> q+
00:48:55 <ken> tplooker: Are non-normative tests using a specific method?
00:49:08 <drummond> +1 to Manu's description of what a test suite framework for DID methods would work—and even better that the current CCG test suite is already a start on that.
00:49:21 <ken> ... Some methods would be difficult to use in the complete set of tests.
00:49:47 <ken> brent: We can't create a DID method by the charter.
00:49:56 <ken> ... We could use one or more to test.
00:50:04 <brent> q?
00:50:11 <brent> ack brent
00:50:11 <Zakim> brent, you wanted to revisit the charter
00:50:14 <brent> ack selfissued
00:50:27 <ken> selfissued: I second Brent's statement.
00:50:50 <ken> ... We should find a way to test the requirements using some implementations.
00:51:39 <ken> ... I also want to support the idea that we are not creating a method, but it will be necessary to test resolution in order to facilitate the semantics.
00:51:39 <brent> q?
00:52:17 <manu> q+
00:52:37 <ken> brent: Is there any controversy regarding how to pull in the test suite?
00:52:58 <ken> manu: This is easier! Only Andrew has worked on it.
00:53:23 <ken> ... It doesn't matter. Let's just use the W3C tooling to pull it over.
00:53:24 <gkellogg> q+
00:53:33 <ivan> ack manu
00:53:34 <burn> ack manu
00:53:35 <brent> ack manu
00:53:43 <brent> ack gkellogg
00:53:52 <ken> brent: Does any one disagree with manu?
00:54:17 <ken> gkellogg: Are we going to copy it or move the repo?
00:54:49 <ken> manu: There is not an IPR consideration here because only Andrew worked on it.
00:55:09 <ken> ... We don't care about the history as much.
00:55:10 <JoeAndrieu> q+
00:55:25 <ken> gkellogg: The history would remain in the old repo.
00:55:42 <burn> q+
00:55:49 <ken> manu: I prefer transfer of repo, but multiple ways can work.
00:55:58 <ken> ... What happens to the repos.
00:56:06 <ken> ivan: We archive the old repos.
00:56:09 <brent> ack JoeAndrieu
00:56:11 <ivan> ack JoeAndrieu
00:56:24 <ken> JoeAndrieu: If we archive, can we redirect to the new repo.
00:56:30 <manu> q+ to say that people don't read
00:56:49 <ken> ivan: Change the readme that says, "Go to the new repo"
00:57:01 <brent> ack burn
00:57:40 <ken> burn: I don't want to derail success, but in this case we could just move the repo. There is not a history concern here.
00:57:48 <brent> q?
00:57:50 <manu> ack manu
00:57:50 <Zakim> manu, you wanted to say that people don't read
00:57:50 <ken> ... Chairs and editors can work this out.
00:57:52 <ken> manu:
00:58:02 <gkellogg> q+
00:58:23 <ken> ... People don't read. If we transfer the repo, people are automatically redirected.
00:58:58 <ken> ... The archival approach has people not reading or html type links and google searches.
00:59:07 <ken> ... It's messier.
00:59:14 <brent> zzakim, close the queue
00:59:18 <brent> zakim, close the queue
00:59:18 <Zakim> ok, brent, the speaker queue is closed
00:59:25 <brent> ack gkellogg
00:59:51 <ken> gkellogg: In json-ld we had this same problem. We changed the endpoint to autoredirect after a short pause.
00:59:53 <jc> jc has joined #did
00:59:56 <brent> PROPOSED: Ivan will move the existing CCG did spec test suite into the DID WG did spec test suite, preserving the commit history if possible.
00:59:57 <ken> ... This worked well.
01:00:07 <manu> +1
01:00:15 <JoeAndrieu> +1
01:00:16 <drummond> +1
01:00:16 <burn> +1
01:00:18 <tplooker_> tplooker_ has joined #did
01:00:19 <Dudley> +1
01:00:21 <ken> ken: +1
01:00:22 <grantnoble> +1
01:00:25 <rhiaro> +1
01:00:25 <tplooker_> +1
01:00:29 <yancy> +1
01:00:34 <peacekeeper> +1
01:00:35 <brent> PROPOSED: The DID WG will move the existing CCG did spec test suite into the DID WG did spec test suite, preserving the commit history if possible.
01:00:46 <ken> ivan: I am not opposed. I don't know if I have rights.
01:00:52 <JoeAndrieu> +1
01:00:57 <ken> +1
01:00:57 <brent> +1
01:00:58 <rhiaro> +1
01:01:01 <ivan> +1
01:01:02 <burn> +1
01:01:05 <Dudley> +1
01:01:08 <drummond> +1
01:01:10 <tplooker_> +1
01:01:11 <grantnoble> +1
01:01:16 <manu> +0.9
01:01:23 <chaals> chaals has joined #did
01:01:30 <brent> RESOLVED: The DID WG will move the existing CCG did spec test suite into the DID WG did spec test suite, preserving the commit history if possible.
01:01:50 <ken> brent: We are done with this topic.
01:01:57 <brent> zakim, open the queue
01:01:57 <Zakim> ok, brent, the speaker queue is open
01:02:13 <ken> Topic: Logistics of additional meetings
01:02:49 <ken> burn: We live on a globe. The chairs will decide based on contributors and locations.
01:02:49 <PindarHK> PindarHK has joined #did
01:03:16 <ken> ... There are problems with multiple calls. VCWG has an open slot.
01:03:31 <ken> ... The CCG has resolution discussion time slot.
01:03:49 <ken> ... There are times that are poor for everyone.
01:04:30 <ken> ... I put out a doodle poll. I picked one day and put in all 24 hour slots.
01:04:51 <phila> phila has joined #did
01:04:51 <ken> ... I'm only looking for Yes, No, If need be for the time of day.
01:05:21 <ken> ..."if need be" is for occasional calls. Please be generous.
01:05:44 <ken> ... We can collect other input as needed.
01:06:16 <brent> Link to doodle poll: https://doodle.com/poll/mnru35rtik6mtsxx
01:06:43 <ken> JoeAndrieu: This is based on your laptop timezone.
01:09:23 <ken> burn: Please consider your own situation.
01:09:33 <jc> jc has joined #did
01:10:06 <ken> burn: More time?
01:10:15 <inamori_> inamori_ has joined #did
01:11:10 <ken> ... This is just input.
01:12:04 <ken> ... This is biased. We need to consider other who are not here today.
01:12:38 <ken> phila: RE: Daylight savings time, we could adjust the meeting time.
01:13:09 <ken> burn: Grant and I have shifted our meetings times to handle that.
01:13:39 <ken> burn: There appear to be two main times. One is bad for Asia.
01:13:57 <ken> ... I see few participants from Asia in the poll.
01:14:18 <ken> ... The other slots are impossible for Europe.
01:14:30 <mitja> mitja has joined #did
01:15:08 <ken> ... Specific individuals need to be considered.
01:15:29 <ken> ... Who likes the current VCWG time?
01:15:41 <ken> ... Who doesn't like it?
01:16:19 <ken> ... Who likes the DID resolution time?
01:16:38 <ken> ... Who doesn't like it?
01:18:08 <ken> ... Kyle mentioned that he intends to do most of his work via email. We might be able to do 1 of 4 meetings at a time for him and others in NZ.
01:18:24 <ken> ... Thanks for your input.
01:18:34 <ken> ... Comments and suggestions?
01:18:49 <brent> q?
01:18:50 <burn> q?
01:19:38 <ken> burn: We haven't considered which day yet?
01:20:02 <ken> peacekeeper: We need to continue to have a DID resolution call time also.
01:20:33 <ken> burn: I want a tradition of no meeting after F-2-F the week after.
01:20:53 <ken> ... March would be a proposed time for the next F2F.
01:21:01 <ken> ... Is that too soon or late?
01:21:22 <peacekeeper> CCG's DID Resolution call info is here: https://docs.google.com/document/d/1qYBaXQMUoB86Alquu7WBtWOxsS8SMhp1fioYKEGCabE/ (but this can be changed to accommodate DIDWG call if needed)
01:21:26 <drummond> +1 to January
01:21:35 <JoeAndrieu> +1 to too late (January better)
01:21:41 <drummond> q?
01:21:48 <drummond> q+
01:21:49 <ken> selfissued: it is too late. We should try to meet in Jan after most technical issues are resolved by the end of the year.
01:22:11 <ken> burn: I have no objection to January. It is an interesting option.
01:22:12 <burn> ack drummond
01:22:29 <JoeAndrieu> q+
01:22:32 <ivan> q+
01:22:35 <burn> ack JoeAndrieu
01:22:41 <ken> drummond: +1 to January. We should have key issues lined up for resolution then.
01:22:50 <ken> JoeAndrieu: I agree.
01:23:05 <burn> ack ivan
01:23:09 <ken> ... The rubric should be ready for review by then.
01:23:34 <ken> ivan: I prefer February. January is too close to the holidays.
01:23:47 <ken> ... End of Jan is better.
01:24:10 <ken> burn: There is some agreement on end of Jan-Feb.
01:24:30 <ken> phila: No one works in Dec. Can we meet then?
01:24:31 <ivan> scribejs, set arnaud Arnaud Le Hors
01:24:35 <ivan> guests+ arnaud
01:24:51 <ken> burn: That has never worked out for me, but I love your enthusiasm!
01:25:10 <ken> burn: Can we tack on to another event?
01:25:26 <ken> burn: Are there conflicts that you are aware of.
01:25:52 <ken> self-issued: fido is first week of feb 2-8
01:26:06 <ken> ... RSA is FEb 23-28 SFO
01:26:21 <ken> ... FIDO in Hong Kong.
01:26:27 <ken> burn: Hosting?
01:26:32 <ivan> s/self-issued/selfissued/
01:26:37 <burn> q?
01:26:54 <ken> ivan: If it is in Feb-March, I could explore hosting in Amerstdam.
01:27:16 <Arnaud> Arnaud has joined #did
01:27:17 <ken> s/Amerstdam/Amsterdam/
01:27:37 <ken> selfissued: Last week in Jan is clear.
01:28:17 <ken> ... MS can get rooms in Redmond, sFO, or London.
01:28:28 <PindarHK> PindarHK has joined #did
01:28:51 <ken> ivan: Europe would be fair.
01:29:39 <ken> JoeAndrieu: RWOT location is March Beunos Aires.
01:29:47 <ken> ... Not finalized yet.
01:30:32 <ken> burn: Your preference has been noted, Ivan ;)
01:30:56 <ken> brent: Webex may need to change machines.
01:31:12 <ken> ... 1/2 hour break.
01:31:17 <mitja_> mitja_ has joined #did
01:38:14 <dsr> dsr has joined #did
01:38:49 <yoshiaki> yoshiaki has joined #did
01:38:52 <yoshiaki> yoshiaki has joined #did
01:41:25 <tm> tm has joined #did
01:44:26 <yoshiaki> yoshiaki has joined #did
01:53:02 <dezell> dezell has joined #did
01:56:16 <tung> tung has joined #did
02:00:59 <brent> q?
02:01:27 <inamori_> inamori_ has joined #did
02:01:55 <grantnoble> grantnoble has joined #did
02:03:14 <gkellogg> gkellogg has joined #did
02:03:36 <takuya> takuya has joined #did
02:04:30 <Masa_JCB> Masa_JCB has joined #did
02:05:15 <kumekawa> kumekawa has joined #did
02:06:39 <Chunming> Chunming has joined #did
02:06:48 <Kangchan> Kangchan has joined #did
02:06:56 <Dudley> Dudley has joined #did
02:07:05 <codenamedmitri> codenamedmitri has joined #did
02:08:37 <peacekeeper> peacekeeper has joined #did
02:08:47 <ken> ken has joined #did
02:09:10 <JoeAndrieu> JoeAndrieu has joined #did
02:09:24 <jay> jay has joined #did
02:09:43 <ivan> ivan has joined #did
02:09:50 <peacekeeper> scribe: peacekeeper
02:09:59 <inamori_> inamori_ has joined #did
02:10:12 <horiuchi> horiuchi has joined #did
02:10:13 <peacekeeper> pamela: Microsoft joining the DID WG has been approved. myself and Daniel Buchner will be representatives.
02:10:38 <minami> minami has joined #did
02:10:46 <peacekeeper> brent: we have a presentation by JoeAndrieu now
02:10:59 <peacekeeper> brent: ...to talk about Rubric for Decentralization
02:11:10 <yoshiaki> yoshiaki has joined #did
02:11:11 <brent> zakim, open the queue
02:11:11 <Zakim> ok, brent, the speaker queue is open
02:11:19 <peacekeeper> JoeAndrieu: meta-level introduction: this work has happened so far outside of WG so far (and outside W3C)
02:11:30 <peacekeeper> JoeAndrieu: we hope it will flow into this WG
02:11:41 <peacekeeper> JoeAndrieu: Rubric for Decentralized characteristics is in WG charter
02:11:52 <peacekeeper> JoeAndrieu: what's a rubric? why a rubric for decentralization?
02:12:18 <peacekeeper> JoeAndrieu: A rubric is a scoring guide, used to evaluate performance or a product or a project
02:12:35 <peacekeeper> JoeAndrieu: it's also a religious term (but that's not what we're talking about)
02:13:02 <peacekeeper> JoeAndrieu: (showing an example of a Rubric of "Digital Storytelling Assignment")
02:13:11 <peacekeeper> JoeAndrieu: there are categories, ratings, and descriptions what ratings mean
02:13:12 <chaals> chaals has joined #did
02:13:35 <peacekeeper> JoeAndrieu: e.g. ratings includde Excellent, Good, Fair, Poor for a sample category
02:13:53 <peacekeeper> JoeAndrieu: (showing more examples on slides)
02:14:09 <peacekeeper> JoeAndrieu: there are different structures to the possible sets of answers
02:14:17 <peacekeeper> JoeAndrieu: other types of responses can be useful
02:14:29 <peacekeeper> JoeAndrieu: Why a Rubric for Decentralization?
02:14:46 <peacekeeper> JoeAndrieu: this work started after a proposal for a "did:facebook" method
02:14:56 <peacekeeper> JoeAndrieu: we realized there's no good definition of "decentralized"
02:15:06 <peacekeeper> JoeAndrieu: could "did:facebook" ever be decentralized?
02:15:18 <peacekeeper> JoeAndrieu: what if Facebook made a DID method that is actually decentralized?
02:15:30 <peacekeeper> JoeAndrieu: should there be requirements for DID methods to be "decentralized" in some sense?
02:15:42 <peacekeeper> JoeAndrieu: it was frustrating not to have a shared understanding of "decentralized"
02:16:00 <peacekeeper> JoeAndrieu: how can we have a definition we can share
02:16:23 <peacekeeper> JoeAndrieu: we all had a slightly different understanding.
02:16:45 <peacekeeper> JoeAndrieu: so how can we evaluate DID methods. what is it about people in community that got us interested in DIDs?
02:16:56 <peacekeeper> JoeAndrieu: it's a tool for evaluating specifically DID methods
02:17:03 <tplooker> tplooker has joined #did
02:17:16 <peacekeeper> JoeAndrieu: our goal is to be objective and non-judgemental. we want to minimize bias, avoid advocacy
02:17:19 <selfissued> selfissued has joined #did
02:17:35 <peacekeeper> JoeAndrieu: people who make DID methods should be able to differentiate
02:17:54 <peacekeeper> JoeAndrieu: this is relative to an evaluator. different evaluators will arrive at different results.
02:17:56 <ivan> -> https://docs.google.com/presentation/d/1ESS_6TuU7iHcAKkSB_py2zY5NJUKggs_uRDfEdl41HE/edit#slide=id.g477278097e_1_89 starting slide for Joe's presentation
02:18:01 <peacekeeper> JoeAndrieu: example: cost of DID method governance
02:18:25 <peacekeeper> JoeAndrieu: e.g. it costs money to travel to conferences. this is only accessible to some for economic reasons.
02:18:35 <gannan> gannan has joined #did
02:18:37 <peacekeeper> JoeAndrieu:  so in order to evaluate a criterion such as cost, it depends on who evaluates it
02:19:01 <peacekeeper> JoeAndrieu: there is no "summary rating". there is no "i'm 95% compiant with the rubrics". it's more about trade-offs and comparion
02:19:17 <gannan> present+
02:19:57 <peacekeeper> JoeAndrieu: what we are working on is a single "Rubric". it consists of multiple criteria with multiple possibe answers.
02:20:01 <burn> joe, FYI, "criteria" is plural and "criterion" is singular . . . :)
02:20:29 <burn> s/joe, FYI, "criteria" is plural and "criterion" is singular . . . :)//
02:20:40 <peacekeeper> JoeAndrieu: a criterion is important or not depending on the use
02:20:49 <brent> q?
02:20:50 <burn> q+
02:21:08 <peacekeeper> JoeAndrieu: it can be filled out by a specific evaluator for a specific method. and you can add comments/notes while you evaluate it.
02:21:29 <peacekeeper> JoeAndrieu: (showing an example of a Rubrics that's neutral)
02:22:21 <peacekeeper> JoeAndrieu: amusement park ride example: question is "how tall is the rider". answers are "<3", "between 3 and 4", ">4". there is no good or bad, it depends on the situation how a certain answer applies to a certain situation
02:22:43 <peacekeeper> JoeAndrieu: this topic started during a passionate debate in CCG
02:22:58 <peacekeeper> JoeAndrieu: several sessions at IIW28
02:23:13 <peacekeeper> JoeAndrieu: for RWoT9 I wrote a "creative brief"
02:23:45 <peacekeeper> JoeAndrieu: several members of this community have been collaborating at those events
02:23:57 <peacekeeper> JoeAndrieu: we'd like to feed this work into the DID WG
02:24:28 <peacekeeper> JoeAndrieu: (showing Google Doc of initial write-up)
02:24:38 <Fuji> Fuji has joined #did
02:24:42 <yoshiaki> yoshiaki has joined #did
02:24:56 <peacekeeper> JoeAndrieu: example criteria: is it permissioned? how open is the governance of the network?
02:25:31 <peacekeeper> JoeAndrieu: example answers: 1. anyone can participate in consensus fully, 2. all participation is permissioned. etc.
02:26:15 <peacekeeper> JoeAndrieu: example criterion: fiduciary commitments. does a fiduciary put your interest above their own?
02:26:50 <peacekeeper> JoeAndrieu: existence of a fiduciary role in a system is a form of decentralization.
02:27:24 <peacekeeper> JoeAndrieu: (showing DID creative brief in Github)
02:27:56 <peacekeeper> JoeAndrieu: in my experience, doing a "creative brief" is useful before starting to collaborate on the actual document
02:28:25 <peacekeeper> JoeAndrieu: .. in order to get collaborators on the same page. what are you trying to do, who are you trying to reach, what are tactical objectives, etc.
02:28:37 <peacekeeper> JoeAndrieu: we want this to be simple to apply
02:29:01 <peacekeeper> JoeAndrieu: we want to help standards collaborators to make better decisions on what DIDs can be used for.
02:29:39 <peacekeeper> JoeAndrieu: we want to help DID method creators evaluate trade-offs in their DID methods. this can help design better DID methods specifications.
02:30:03 <peacekeeper> JoeAndrieu: this may also help decision makers choose between available DID methods
02:30:33 <peacekeeper> JoeAndrieu: non-goals: no top-level metric ("97% decentralized"). no framework for certification.
02:30:58 <peacekeeper> JoeAndrieu: we want a subjective, qualitative evaluation. some criteria are soft and fuzzy and don't fit into a hard metric.
02:31:16 <peacekeeper> JoeAndrieu: this will not be exhaustive. just capture what drives the work in the community.
02:31:37 <peacekeeper> JoeAndrieu: it will not directly provide guidance beyond DID methods.
02:32:06 <peacekeeper> JoeAndrieu: it will not provide guidance whether or where DID methods should be published (in a registry)
02:32:22 <peacekeeper> JoeAndrieu: however, some registry maintainers may decide to use the rubric
02:33:24 <peacekeeper> JoeAndrieu: source of credibility for this work: involved people are experienced in the DID work. they include editors, chairs, board members etc. of relevant groups and organizations.
02:33:43 <peacekeeper> JoeAndrieu: we want people to collaborate and communicate better. let's avoid non-productive rabbit holes.
02:34:04 <peacekeeper> JoeAndrieu: we encourage people to talk about this, write blog posts about their favorite criteria, etc.
02:34:17 <peacekeeper> JoeAndrieu: we had weekly calls before RWoT9, then met at RWoT9
02:34:52 <peacekeeper> JoeAndrieu: (showing draft paper from RWoT9 on github)
02:35:30 <peacekeeper> JoeAndrieu: our criteria include: network governance, method governance.
02:35:56 <peacekeeper> JoeAndrieu: we found it was hard to fit DID methods into our initial understanding of a spectrum of governance.
02:36:14 <peacekeeper> JoeAndrieu: we realized governance was a more complex topic.
02:36:44 <peacekeeper> JoeAndrieu: example questions: is it governened by a single entity? by a closed set of multiple parties? by an open set of multiple parties?
02:37:06 <peacekeeper> JoeAndrieu: another example question: how privatized is the economic interest of the governing authority?
02:38:15 <peacekeeper> JoeAndrieu: examples answers: 1. governing authority extracts rent, 2. it enhances profits, 3. it is established for the common good for a limited set of parties, 4. it is established for the public good.
02:38:47 <peacekeeper> JoeAndrieu: we are learning new and better ways to think about these questions
02:39:24 <peacekeeper> JoeAndrieu: we talked to Arthur Brock of Holochain. looking at "did:holo" helped us get new perspectives on the criteria.
02:39:42 <peacekeeper> JoeAndrieu: possible next step: propose initial draft for DID WG.
02:40:08 <peacekeeper> JoeAndrieu: solicit criteria, collect, collate, filter. determine relevance.
02:40:14 <brent> q?
02:40:18 <peacekeeper> JoeAndrieu: questions ?
02:40:24 <brent> ack burn
02:40:25 <manu> q+
02:40:25 <peacekeeper> JoeAndrieu: or comments ?
02:40:38 <pamela> q+
02:40:45 <manu> q- later
02:40:47 <peacekeeper> burn: "criteria" is plural. "criterion" is singular.
02:41:07 <phila> phila has joined #did
02:41:28 <peacekeeper> pamela: i expect the roadmap must include a glossary. e.g. define "privatization"
02:41:43 <peacekeeper> pamela: doesn't have to be perfect now, but all words need to be strictly defined at some point
02:41:53 <peacekeeper> JoeAndrieu: yes we already found that in our conversations. words matter.
02:42:22 <peacekeeper> pamela: can we look at section 6.0.4
02:42:48 <drummond> q+
02:42:54 <tplooker> tplooker has joined #did
02:43:13 <peacekeeper> pamela: are we talking about fiduciary commitments of a wallet? what does that mean?
02:43:33 <peacekeeper> JoeAndrieu: e.g. coinbase may or may not have a fiduciary commitment to its users
02:43:43 <peacekeeper> pamela: how is this relevant for DID methods?
02:44:15 <peacekeeper> JoeAndrieu: i think this only makes sense if a DID method specifies a wallet. so this may indeed not be relevant.
02:44:17 <manu> ack manu
02:44:19 <brent> q?
02:44:21 <jc> jc has joined #did
02:44:21 <brent> ack peacekeeper
02:44:24 <brent> ack pamela
02:44:38 <Kangchan> Kangchan has joined #did
02:44:42 <peacekeeper> manu: is this a complete set of categories, are we adding more?
02:44:46 <peacekeeper> JoeAndrieu: yes we're going to add more
02:44:58 <peacekeeper> manu: good that this is happening. this was a point of contention.
02:45:17 <peacekeeper> manu: at some point we need to be "done". when is that going to be? because this could keep going for a very long time.
02:45:28 <peacekeeper> manu: the larger the rubric gets, the less useful it becomes
02:45:57 <peacekeeper> manu: once you have this and people can self-report, would it be useful to compile it for e.g. 10 existing DID methods
02:46:13 <peacekeeper> manu: this could then trigger more criteria to be added, after doing some initial evaluations
02:46:48 <peacekeeper> manu: 1. how long does this go on?, 2. are we compiling a list of evaluations?
02:47:13 <peacekeeper> JoeAndrieu: reg. 1.: not sure about the exact timeline, but at some point we will decide to publish it
02:48:04 <peacekeeper> JoeAndrieu: drummond filled out the initial evaluation for did:sov. this triggered more discussion
02:48:26 <brent> q?
02:48:32 <peacekeeper> JoeAndrieu: others have tried to apply it (e.g. uport, jolocom). so we already have some experience with how it works
02:48:47 <burn> q+ to ask if a specific goal is to distinguish among all did methods
02:48:54 <ken> q+
02:48:55 <peacekeeper> JoeAndrieu: evaluations are subjective
02:49:02 <brent> ack drummond
02:49:21 <peacekeeper> drummond: this is fantastic
02:49:29 <hhan2> hhan2 has joined #did
02:49:58 <JoeAndrieu> google doc: https://docs.google.com/document/d/1rYdWiwawWmLOWtHRvT0GzYcdewW_OS9M2mAkENLFdtY/edit?usp=sharing
02:50:07 <peacekeeper> drummond: reg. pamela 's comments: a wallet can be involved in a DID method. so properties of a DID methods can depend on properties of the wallets that are used (e.g. for key generation)
02:50:50 <peacekeeper> drummond: reg. manu 's comments: we need to engage method authors to evalute their own methods, rather than a core group evaluating every method.
02:51:25 <brent> q?
02:51:25 <peacekeeper> drummond: there is tremendous marketing value in this. it will help to educate a larger audience on what DIDs are about.
02:51:39 <peacekeeper> drummond: other work will happen that will reference this
02:51:40 <JoeAndrieu> q+ to show the examples in the google doc
02:52:02 <peacekeeper> drummond: others (e.g. DID method authors) will use this to describe/promote their work
02:52:45 <burn> ack burn
02:52:45 <Zakim> burn, you wanted to ask if a specific goal is to distinguish among all did methods
02:52:52 <peacekeeper> drummond: neutral parties could evaluate DID methods (e.g. similar to EFF's secure messaging scorecard)
02:53:22 <chaals> chaals has joined #did
02:53:28 <peacekeeper> burn: do you intend methods to be able to distinguish between methods? is this the goal
02:53:39 <peacekeeper> s/methods/the rubric/
02:54:04 <brent> ack ken
02:54:07 <peacekeeper> JoeAndrieu: not necessarily. multiple methods may have very similar evaluations but differentiate in other ways
02:54:19 <pamela> q+
02:54:25 <peacekeeper> ken: is there any outreach to DID methods that are not participating in this meeting?
02:55:04 <peacekeeper> JoeAndrieu: for RWoT paper we won't solicit extended input. but once it's in the WG we will reach out further
02:55:36 <peacekeeper> ken: what will you do with the responses other than publish them? will you check that they are done correctly?
02:56:03 <peacekeeper> JoeAndrieu: no, i'm interested in feedback on whether the rubric is useful for characterizing DID methods
02:56:08 <drummond> q+
02:56:16 <brent> zakim, close the queue
02:56:16 <Zakim> ok, brent, the speaker queue is closed
02:56:21 <brent> q?
02:56:43 <peacekeeper> JoeAndrieu: right now, the input we're interested in is not so much concrete evaluations, but rather defining the rubric / the criteria themselves. the WG should focus on the latter.
02:56:56 <peacekeeper> ken: are we going to publish evaluations? or will others do that?
02:57:08 <peacekeeper> JoeAndrieu: i think we will only publish the rubric
02:57:24 <peacekeeper> JoeAndrieu: since we don't intend to solicit evaluations, there is no intend at the moment to publish them
02:57:50 <gkellogg> q+ “publishing for a handfull” may be a problem
02:58:04 <peacekeeper> JoeAndrieu: however, we are using examples, so we may publish a subset of evaluatios we're doing ourselves. but we won't have a well-defined process for that in the beginning
02:58:16 <peacekeeper> brent: so this would be for illustrative purposed on how to use the rubric
02:58:21 <JoeAndrieu> q?
02:58:24 <brent> ack JoeAndrieu
02:58:24 <Zakim> JoeAndrieu, you wanted to show the examples in the google doc
02:58:25 <peacekeeper> s/purposed/purposes/
02:58:33 <kaz> kaz has joined #did
02:58:38 <brent> ack pamela
02:58:45 <YangHau> YangHau has joined #did
02:59:11 <peacekeeper> pamela: some adjectives may be too relative, e.g. "inexpensive". this could be problematic. another example is "transparent", this is also very subjective
02:59:38 <peacekeeper> pamela: we may need remidation if people disagree
02:59:39 <yoshiaki> yoshiaki has joined #did
02:59:58 <peacekeeper> s/remidation/remediation/
03:00:18 <peacekeeper> JoeAndrieu: this is up to the evaluator. every evaluator will have to decide for themselves what "inexpensive" means
03:01:18 <peacekeeper> brent: the rubric is a set of criteria. it can be used by a method author, but it can also be used by a user of a method, or anyone else. it's a tool.
03:01:44 <peacekeeper> JoeAndrieu: evaluation = what happens when an evaluator applies the rubric to a DID method
03:01:45 <tplooker> tplooker has joined #did
03:03:13 <peacekeeper> drummond: suggestion: i think there could be a way to accelerate this work. the group could invite DID method authors to come up with their own explanations of why they think their method is different, and why their method is needed in addition to all the existing ones.
03:03:21 <didpresenter> didpresenter has joined #did
03:03:34 <peacekeeper> drummond: we can see what they believe is different about their methods
03:03:52 <brent> q?
03:03:54 <tung> tung has joined #did
03:04:02 <peacekeeper> JoeAndrieu: (showing working document in Google Docs)
03:04:10 <brent> ack drummond
03:04:31 <peacekeeper> brent: thanks everybody. moving on to next topic.
03:05:02 <peacekeeper> topic: Concerns and Requirements for adopting work items
03:05:14 <brent> zakim, open the queue
03:05:14 <Zakim> ok, brent, the speaker queue is open
03:05:32 <peacekeeper> manu: (showing slides on how to adopt existing work)
03:05:44 <peacekeeper> manu: we had some disagreement yesterday, some miscommunication
03:05:54 <horiuchi> horiuchi has joined #did
03:06:18 <peacekeeper> manu: what are the concerns when this group decides to adopt work from the CCG or from other groups
03:06:25 <peacekeeper> manu:  those concerns will drive requirements
03:06:34 <peacekeeper> manu: e.g. if concerned about IPR, we must do X....
03:06:55 <peacekeeper> manu: different people may have to be involved on different levels
03:07:44 <peacekeeper> manu: what are the concrete requirements (example discussions: open Github issues must be preserved? what about open PRs? etc.)
03:08:07 <brent> q?
03:08:38 <peacekeeper> manu: there were concerns around intellectual property commitments. this is an important concern.
03:08:40 <st> st has joined #did
03:09:01 <peacekeeper> manu: another concern was that the WG has to have the ability to revisit previous decisions
03:09:20 <peacekeeper> manu: WG is more formal than CG, therefore we may have to go back and question certain decisions
03:09:55 <peacekeeper> manu: another concern was continuity (e.g. should the fine-grained Git commit/issue/PR history be preserved and visible)
03:10:41 <peacekeeper> manu: also concerns about messaging to the broader community (e.g. a feeling that work may be "taken away" from someone)
03:11:02 <brent> q?
03:11:10 <peacekeeper> manu: also concern about amount of efforts that are necessary (e.g. for work required to set up and move Github repos)
03:11:50 <yoshiaki> yoshiaki has joined #did
03:11:53 <peacekeeper> ivan: the last one is not a matter of effort of the W3C staff. rather, what matters is the necessity to fit everything we do into the existing W3C infrastructure. this includes concrete tools to be used.
03:12:38 <PindarHK> PindarHK has joined #did
03:12:40 <peacekeeper> burn: there may be more or less work for W3C staff depending on how we set up things.
03:12:45 <brent> q?
03:12:56 <peacekeeper> ivan: yes but the main requirement is that all tools are available and set up correctly
03:13:00 <gkellogg> q+
03:13:14 <brent> ack gkellogg
03:13:41 <peacekeeper> gkellogg: we had a similar experience in JSON-LD CG transition. we already discussed some pros/cons of moving the Github issues.
03:14:08 <peacekeeper> gkellogg: regarding issues and PRs: what we did was to re-create new PRs in the new repo with references back to the old PRs in the old repository
03:14:29 <peacekeeper> gkellogg: some issues pointed back to old issues. they may be closed in one repo but still open in the other.
03:14:51 <peacekeeper> gkellogg: if you re-create PRs, it's hard to move them in an automatic way
03:15:01 <phila> phila has joined #did
03:15:22 <peacekeeper> gkellogg: in the DID spec, we have 8-9 open PRs. perhaps we should close them and simply ask the authors to open new ones.
03:15:56 <peacekeeper> manu: moving on to concrete requirements.
03:16:18 <peacekeeper> manu: we had consensus that open issues must be preserved. then we can triage and process them.
03:16:43 <peacekeeper> brent: we're talking about moving from the CCG did-spec repo to the WG repo.
03:17:06 <peacekeeper> manu: this discussion is generic to all the work we're doing, including DID spec, rubric, use cases, etc.
03:17:11 <brent> q?
03:17:37 <peacekeeper> manu: 1. preserve open issues, 2. preserve PR, 3. there must be a specific established point in time when the WG took over
03:17:45 <JoeAndrieu> q+ to suggest that PRs from non WG members need special handling
03:18:17 <peacekeeper> manu: open question: do we want to pull in close issues and closed PRs (if it's easy)
03:18:32 <Kangchan_> Kangchan_ has joined #did
03:18:33 <peacekeeper> manu: open question: do we want to preserve commit history (if it's easy). is anyone concerned about that?
03:18:35 <burn> q+ to suggest we stop using the word 'preserve'
03:18:50 <brent> ack JoeAndrieu
03:18:50 <Zakim> JoeAndrieu, you wanted to suggest that PRs from non WG members need special handling
03:19:05 <peacekeeper> JoeAndrieu: i like what the commit history shows us in terms of contributions
03:19:10 <ken> q+
03:19:16 <peacekeeper> JoeAndrieu: one issue with requirements: what do we do with PRs from non-WG-members?
03:19:22 <peacekeeper> manu: we can close them
03:19:58 <peacekeeper> manu: we can trace exactly who contributed what lines to the spec
03:20:04 <mitja> mitja has joined #did
03:20:12 <peacekeeper> manu: from my perspective, preserving the history has no downside and multiple upsides
03:20:17 <tplooker> tplooker has joined #did
03:20:26 <tplooker> q+
03:20:30 <brent> ack burn
03:20:30 <Zakim> burn, you wanted to suggest we stop using the word 'preserve'
03:20:33 <peacekeeper> burn: let's stop using the term "preserve". we never considered "deleting/erasing" any history.
03:20:38 <peacekeeper> burn: we talked about archiving
03:21:05 <tplooker> q-
03:21:13 <peacekeeper> burn: using the term "preserve" sounds like moving th history into the WG. it sounds like if we don't do it, everything is gone
03:21:26 <brent> ack ken
03:21:30 <peacekeeper> burn: but even if we don't move the history to the WG, it's still "preserved", it's not gone
03:21:49 <peacekeeper> ken: let's distinguish between open and closed PRs.
03:22:02 <brent> q?
03:22:12 <peacekeeper> ken: let's be clear on what exactly we're moving/preserving/closing/etc.
03:22:24 <dezell> dezell has joined #did
03:22:34 <peacekeeper> manu: so what should we do with commit history
03:22:53 <peacekeeper> ivan: commit history will be there in any case. the question is where it will be.
03:23:45 <peacekeeper> burn: precise discussion is around "complete commit history must be in WG", rather than "commit history must be preserved".
03:24:18 <peacekeeper> manu: do we agree on having the complete commit history in the WG?
03:24:20 <brent> q+ selfissued
03:24:27 <peacekeeper> ivan: do we need to have it in this particular repo?
03:24:33 <manu> q+ it's easy
03:24:34 <gkellogg> q+
03:24:37 <manu> q- it
03:24:39 <manu> q- easy
03:24:46 <manu> q+ to note its easy
03:24:46 <JoeAndrieu> q+ to say it isn't about need, it is about the tradeoff for the trouble
03:24:55 <peacekeeper> ivan: i don't see the particular need to have it in that repo. i haven't heard a good reason
03:24:57 <yoshiaki> yoshiaki has joined #did
03:25:05 <drummond> q?
03:25:38 <peacekeeper> selfissued: this may be unpopular: this seems like an administrative decision left to chairs and W3C staff. it doesn't matter directly for the work of the WG itself
03:25:42 <drummond> +1 to Mike's point
03:25:50 <brent> q?
03:25:53 <peacekeeper> selfissued: my meta-point: this is not a good use of our time
03:25:58 <brent> ack selfissued
03:26:10 <brent> ack gkellogg
03:26:53 <brent> ack manu
03:26:53 <Zakim> manu, you wanted to note its easy
03:26:55 <peacekeeper> gkellogg: one argument i can see for having the history in the repo is that for editors, git tools can be used to check where/when certain contributions happened. it affects editors, so it should be up to them.
03:27:12 <drummond> Sorry rhiaro
03:27:22 <drummond> Ivan is attending to it again
03:27:34 <brent> q?
03:27:39 <peacekeeper> manu: +1 to that. the editors and chairs and staff can figure it out.
03:27:44 <brent> q+ burn
03:27:51 <selfissued> q+
03:27:57 <brent> q- burn
03:27:57 <peacekeeper> manu: as an editor, it is very important to understand who put something into the spec.
03:28:00 <burn> q-
03:28:35 <peacekeeper> manu: e.g. your view may be that a certain change is editorial, but the original author may disagree. having to jump between multiple repos increases the burder for editors.
03:29:09 <peacekeeper> burn: it is not a waste of time to make sure that everybody's point has been heard
03:29:48 <peacekeeper> burn: articulating all points is a valuable use of time. after that, a decision will be made.
03:29:49 <brent> ack JoeAndrieu
03:29:49 <Zakim> JoeAndrieu, you wanted to say it isn't about need, it is about the tradeoff for the trouble
03:29:52 <brent> ack selfissued
03:30:29 <peacekeeper> selfissued: i haven't heard us talk about editors. there are no editors yet, so they can't be heard.
03:30:54 <peacekeeper> burn: do you want to first select editors or describe the process how editors will be chosen?
03:31:21 <peacekeeper> selfissued: what i said was that "editors + chairs + staff work it out" is not possible since there are no editors yet
03:32:06 <peacekeeper> manu: moving commit history is easy via Git rebase operation
03:32:12 <kazue> kazue has joined #did
03:32:43 <peacekeeper> burn: please raise your hand if you have an opinion on availability of complete Git history in the WG
03:32:57 <rhiaro> I think it should be available
03:33:08 <jay> jay has joined #did
03:33:11 <peacekeeper> (5 people raised hands)
03:33:29 <peacekeeper> burn: now raise hands if you think the full commit history must be available in the WG repo
03:33:40 <peacekeeper> (4 or 5 people raised hands)
03:34:03 <peacekeeper> burn: we will select editors at some point
03:34:08 <igarashi> igarashi has joined #DID
03:34:35 <peacekeeper> manu: last issue: must closed issues/PRs be available in the WG repo? does anyone care?
03:34:39 <brent> q?
03:35:05 <rhiaro> I think closed issues should be available because thoughtful people search existing issues before raising a new one. We might get repeats if theyd on't think to search the old repo
03:35:21 <peacekeeper> manu: if we preserve the full commit history, many commits reference issues or PRs. so if we don't move all of those as well, then the pointers will be wrong. i.e. commits will point to wrong issues/PRs
03:35:30 <mitja> mitja has joined #did
03:35:32 <pamela> q+
03:35:43 <gkellogg> q+
03:35:54 <burn> q+
03:36:04 <peacekeeper> brent: (reading rhiaro 's comment)
03:36:05 <brent> ack pamela
03:36:32 <peacekeeper> pamela: i thought the input to the WG is a document. are you telling me now i have to read years of history as input to the WG?
03:36:40 <brent> ack gkellogg
03:36:50 <ivan> +1 to pamela
03:36:50 <manu> q+ not stating that anyone has to read all that history (and many don't)... but it's important for some folks.
03:36:52 <peacekeeper> pamela: i understand the interest of the community to preserve the history. but the document is the input.
03:36:57 <manu> q+ to say not stating that anyone has to read all that history (and many don't)... but it's important for some folks.
03:37:40 <peacekeeper> gkellogg: yes there is value in history. agree with pamela that the group agreed to start with a snapshot of the document.
03:37:51 <brent> ack burn
03:38:05 <peacekeeper> gkellogg: if an editor changes something in the WG that upsets someone in the CG, then that CG member should join the WG and contribute there
03:38:32 <peacekeeper> burn: it's not a problem to raise old issues again
03:38:45 <peacekeeper> burn: pamela 's point is a good one that the input to the group is a document, not the rest
03:38:52 <brent> ack manu
03:38:53 <Zakim> manu, you wanted to say not stating that anyone has to read all that history (and many don't)... but it's important for some folks.
03:39:25 <peacekeeper> manu: i'm trying to get to something concrete we can do. the simplest thing is to just transfer the repo.
03:39:43 <peacekeeper> manu: since we decided against that, we are having a long discussion on what/how to move manually
03:39:44 <brent> q?
03:40:00 <peacekeeper> manu: nobody is asking anyone to read the whole history, but the editors need that to do their job
03:40:15 <peacekeeper> manu: if we don't move history, it will result in more work for the group
03:41:08 <peacekeeper> manu: the group needs to make a decision that's actionable, we have semi-conflicting requirements
03:41:08 <JoeAndrieu> q+
03:42:06 <peacekeeper> burn: about the repo as a whole. we had reasons why we didn't want to transfer it as a whole;
03:42:19 <peacekeeper> burn: i thought you (manu) told me that there is no problem with transfering
03:42:27 <peacekeeper> manu: no, that was a different conversation
03:42:57 <peacekeeper> ivan: i did talk to ralph during the break, he was not saying "no"
03:43:29 <peacekeeper> ivan: the point is there were yesterday several people who were against moving the repo, because we wanted a clear cut. and there were technical issues about transfering the repo
03:43:58 <drummond> I am beginning to wonder about Pam's suggestion of just taking the CCG Community Final Draft as input to the WG into a clean repo and asking for all issues and PRs to be new ones.
03:44:15 <peacekeeper> JoeAndrieu: i don't think we have consensus on the requirements. a lot of us want to move on and leave the decision to the leadership.
03:44:16 <burn> q?
03:44:19 <burn> ack jo
03:44:22 <burn> ack JoeAndrieu
03:44:35 <ivan> rrsagent, draft minutes
03:44:35 <RRSAgent> I have made the request to generate https://www.w3.org/2019/09/16-did-minutes.html ivan
03:44:42 <peacekeeper> brent: the point of this session was to hear all points and come to consensus. there is no consensus, so the chairs will make a decision.
03:45:10 <peacekeeper> (end of session, group is going to lunch now)
03:53:33 <peacekeeper> peacekeeper has joined #did
03:53:40 <peacekeeper> peacekeeper has joined #did
03:55:50 <phila> phila has joined #did
03:59:21 <PindarHK> PindarHK has joined #did
04:06:42 <kaz> kaz has joined #did
04:07:40 <gannan> gannan has joined #did
04:08:39 <yoshiaki> yoshiaki has joined #did
04:13:09 <mitja> mitja has joined #did
04:14:27 <yoshiaki> yoshiaki has joined #did
04:16:39 <horiuchi> horiuchi has joined #did
04:17:12 <yoshiaki> yoshiaki has joined #did
04:22:31 <gannan> gannan has joined #did
04:24:00 <yoshiaki> yoshiaki has joined #did
04:25:46 <yoshiroy> yoshiroy has joined #did
04:32:44 <yoshiaki> yoshiaki has joined #did
04:33:14 <yoshiaki> yoshiaki has joined #did
04:33:53 <yoshiaki> yoshiaki has joined #did
04:34:42 <Kangchan> Kangchan has joined #DID
04:35:20 <mitja> mitja has joined #did
04:38:17 <Chunming> Chunming has joined #did
04:39:10 <peacekeeper> peacekeeper has joined #did
04:40:17 <igarashi> igarashi has joined #DID
04:44:02 <tung> tung has joined #did
04:44:33 <JoeAndrieu> JoeAndrieu has joined #did
04:44:49 <JoeAndrieu> present+ Joe_Andrieu
04:50:00 <ivan> ivan has joined #did
04:53:18 <jserv--> jserv-- has joined #did
04:59:17 <phila> phila has joined #did
04:59:24 <ken> ken has joined #did
04:59:27 <gkellogg> gkellogg has joined #did
04:59:36 <minami> minami has joined #did
04:59:41 <takuya> takuya has joined #did
05:00:33 <gkellogg> scribe+ gkellogg
05:01:17 <ivan> present+ dezell
05:03:47 <hadleybeeman> hadleybeeman has joined #did
05:03:55 <Masa-JCB> Masa-JCB has joined #did
05:04:03 <grantnoble> grantnoble has joined #did
05:04:09 <gkellogg> topic: DID resolution
05:04:23 <yancy> yancy has joined #did
05:04:38 <mitja> mitja has joined #did
05:05:05 <igarashi> igarashi has joined #DID
05:05:11 <tplooker> tplooker has joined #did
05:05:25 <gkellogg> peacekeeper: DID resolution is getting more interest, becuase once you have DIDs, you need to use them.
05:05:42 <ivan> -> https://docs.google.com/presentation/d/1ESS_6TuU7iHcAKkSB_py2zY5NJUKggs_uRDfEdl41HE/edit#slide=id.g477278097e_1_99 start of presentation slides
05:05:46 <st> st has joined #did
05:05:48 <gkellogg> … There are use cases just for identification, but others are meaninless without resolution.
05:06:12 <gkellogg> … It’s the process of getting from a DID to a DID document. Similar to domain-name resolution
05:06:49 <gkellogg> … It’s not a protocol, which is what people usually expect, such as for HTTP. But, it doesn’t work the same way.
05:06:50 <Fuji> Fuji has joined #did
05:06:51 <jay> jay has joined #did
05:07:17 <gkellogg> … It’s more like an abstact function or algorithm. The process of how this works is method-specific.
05:07:34 <tm> tm has joined #did
05:07:55 <gkellogg> … Some methods may not require any network resolution, such as peer and key DIDs; resolution involvs constructing an ad-hoc document.
05:08:08 <gkellogg> phila: Can you give examples of read DIDs
05:08:40 <gkellogg> peacekeeper: Sovrign, and others define access that requires a block chain. A resolver would need to interact with that ledger to do the resolution.
05:09:20 <gkellogg> … IPFS, or peer-based require very different steps. Peer DIDs require each peer to keep their own log of DIDs, there is not central truth.
05:09:51 <gkellogg> … THis means the DID document is not necessarily an actual document or text stored anywhere. It may be a virtual structure that is constructed dynamically.
05:10:06 <Dudley> Dudley has joined #did
05:10:17 <gkellogg> … Some methods natively store documents, others just store the bits and pieces that make it easy to construct the document.
05:10:36 <gkellogg> … DID resolution is defined to be a process that executes the operations (e.g., read)
05:11:03 <mitja> mitja has joined #did
05:11:17 <gkellogg> … The CCG has been meeting for a year or so which has resulted in different releases. Not neessarily ready for implementaiton, but is a good start.
05:11:31 <gkellogg> … It’s out of scope for the WG to work on resolution (right now).
05:11:43 <gkellogg> … (examples of how resolution works)
05:12:48 <gkellogg> … Verifying a signature may require DID resolution to discover one of the public keys to use that to verify the proof of the document.
05:13:16 <gkellogg> … Several communities are working on DID-Auth, involving a challenge-response, which is also out of scope for this WG.
05:13:38 <gkellogg> … Resolution required to discover PK as well as other attributes of the DID.
05:14:05 <hhan2> hhan2 has joined #did
05:14:06 <gkellogg> … DID documents can contain service endpoints for things like security or agents or other ways to ineract with a subject.
05:14:57 <gkellogg> … The DID spec describes the syntax of a DID and DID URLs, including an information space under the DID.
05:15:41 <gkellogg> … Similear constructs to HTTP paths, including matrix parameters, which is a proposal by TimBL for associating key-value pairs with a URL which are different than a query string.
05:16:22 <gkellogg> … If a path is a way of organizing an information space, the matrix parameters are a way of influencing what a DID URL dereferences.
05:17:00 <gkellogg> … We use the URI spec, so we must be careful to align DIDs with that spec.
05:17:15 <gkellogg> … Resolution means determining an access mehanism through which you can interact with a resource.
05:17:28 <gkellogg> … Dereference means to execute an action on that resource.
05:17:39 <gkellogg> … FIrst resolve to know how to interact.
05:18:00 <yoshiaki> yoshiaki has joined #did
05:18:29 <ivan> q+
05:18:45 <gkellogg> … The DID resolution part is method specific. THe dereferencing is to execute an action on a resource, which typically means to retrieve the resource, which we may want to specify in a method-independent way.
05:19:18 <gkellogg> … Mostly, path, query, and fragment are unspecified, so that method developers are free to make use of these URL parts.
05:19:50 <gkellogg> … THe trivial case is a DID itself, which means to retrieve the DID document.
05:20:37 <gkellogg> … Another use case includes a fragment identifier, which would refer to a part of the DID document.
05:21:59 <gkellogg> … The meaning of the fragment is not based on the URI scheme, but based on the MIME type.
05:22:41 <gkellogg> … These are mostly the same as used in HTML and SemWeb (see Cool URLs)
05:23:24 <gkellogg> … It seems useful to have a URL (vs URI) to get a specific resource from a document.
05:24:22 <yoshiaki> yoshiaki has joined #did
05:24:29 <gkellogg> … Matrix parameters might describe specific versions of documents.
05:24:46 <gkellogg> … (list of matrix parameters)
05:25:36 <gkellogg> … Not a protocol, but an abstract functions which can be realized using different technologies.
05:25:57 <gkellogg> … They way its resolved can influence the results.
05:26:31 <phila> phila has joined #did
05:26:34 <gkellogg> … DIDs may refer to other DIDs or use HTTP-like redirects.
05:26:58 <kaz> kaz has joined #did
05:27:13 <mitja> mitja has joined #did
05:27:37 <JoeAndrieu> q+ to ask if dereferencing should be in scope for the "resolution" spec
05:27:47 <phila> q+
05:27:50 <gkellogg> … Right now, DID resolution is out of scope, and could continue in CCG. The ABNF is in-scope, but how you process them is out-of-scope.
05:28:09 <gkellogg> q?
05:28:25 <burn> zakim, close the queue
05:28:25 <Zakim> ok, burn, the speaker queue is closed
05:28:34 <dbaron> dbaron has joined #did
05:28:38 <horiuchi> horiuchi has joined #did
05:28:40 <dezell> dezell has joined #did
05:28:57 <dezell> present+
05:29:04 <burn> ack ivan
05:29:10 <gannan> gannan has joined #did
05:29:14 <gkellogg> ivan: A flag to ourselves that the DID scheme is currenlty registered provisionally, and this will need to be made official at CR by someone at W3C. It should be part of the final document as well.
05:29:14 <burn> ack JoeAndrieu
05:29:14 <Zakim> JoeAndrieu, you wanted to ask if dereferencing should be in scope for the "resolution" spec
05:29:42 <gkellogg> JoeAndrieu: Perhaps we should be “dereferencing” in the spec title, and it’s confusing for people if its not there.
05:29:43 <drummond> +1 to the DID spec including the registration of the mime type
05:29:44 <burn> ack phila
05:30:11 <danbri> danbri has joined #did
05:30:41 <gkellogg> phila: I might be behind an ISO group on dereferencing, and we may have something closely related. Can’t explain right now, but I would have liked to spend time on it.
05:30:47 <brent> q?
05:31:24 <danbri> regarding DID deferencing, if there is an expectation of using fragment IDs pointing into JSON(-LD) documents, then whatever deref protocol is used will need to provide the appropriate media type information.
05:31:35 <gkellogg> topic: WoT joint session.
05:32:10 <gkellogg> hadleybeeman: TAG introduction. We’re interested in seing how youove come along and how we can help.
05:32:45 <ivan> guests+ Hadley_Beeman
05:33:08 <peacekeeper> peacekeeper has joined #did
05:33:14 <ivan> guests+ Michael_McCool
05:33:38 <gkellogg> mccool: WoT is a WG/CG for around 2 years. THere’s some overlap and potential collaboration.
05:33:59 <ivan> scribejs, set mcool Michael McCool
05:34:05 <gkellogg> … We’re targeting IOT devices applying web architecture to define requirements and supplement IoT for the web.
05:34:41 <gkellogg> … s/mcool/mccool/
05:34:47 <burn> danbri, good point, thanks
05:34:55 <gkellogg> s/mcool/mccool/
05:35:15 <danbri> (there's also an Interest Group since 2019; proposed charter update https://www.w3.org/2019/07/wot-ig-2019.html )
05:35:18 <yoshiaki> yoshiaki has joined #did
05:35:23 <danbri> (er since 2015, sorry)
05:36:39 <gkellogg> mccool: We have two delieverables, the Thing Description (dataschema for payloads) and an abstraction of how to work with a device.
05:36:57 <jay_> jay_ has joined #did
05:36:58 <gkellogg> … There is a binding to a particular protocol, describes in Binding Templates.
05:37:10 <gkellogg> … The main deliverable is a TD, which as a JSON-LD document.
05:37:48 <gkellogg> … The relevant bit is that we need to identify both devices and users.
05:38:20 <gkellogg> … We’re looking at service directories with access control, and need to identify both users and devices, although this becomes an indirect tracking risk.
05:38:33 <gkellogg> … (could use a device to track a person).
05:38:47 <gkellogg> … IDs could be mutable, but this might complicate other use cases.
05:39:02 <gkellogg> … It seems there’s a lot of overlap with DIDs.
05:39:37 <gkellogg> … There are other related things; a TD describes a single device, there’s also a template that describes generic properties of instances of devices.
05:39:57 <gkellogg> … The device might be private, but the template does not need to be.
05:40:32 <gkellogg> … In our new WG charter we have a long list of things to acomplish, but three of them directly relate to DID.
05:40:53 <gkellogg> … Identity management needs to be done in a way to keep track of devices and owners and assign roles.
05:41:19 <manu> q+ to mention that Identity Management may be Verifiable Credentials + DIDs, Discovery sounds like DIDs, Interop profiles might be Verifiable Credentials and/or just plain 'ol JSON-LD?
05:41:20 <gkellogg> … You might be in a smart home use case where access is uniform, but a smart city might have stronger access control requirements.
05:41:32 <burn> zakim, open the queue
05:41:32 <Zakim> ok, burn, the speaker queue is open
05:41:33 <manu> q+ to mention that Identity Management may be Verifiable Credentials + DIDs, Discovery sounds like DIDs, Interop profiles might be Verifiable Credentials and/or just plain 'ol JSON-LD?
05:41:36 <dezell> q+ to ask about slide 12
05:41:50 <gkellogg> … We’d like to have a consistent way of doing things that addresses the different use cases.
05:42:08 <burn> q?
05:42:15 <gkellogg> … In Discovery, we were told by the privacy group that we didn’t have enough pieces together.
05:42:31 <gkellogg> … We don’t have a defined way to get a TD and what its lifecycle is.
05:42:34 <manu> q+ to mention authorization capabilities
05:43:03 <gkellogg> … By discovery, it might a search engine with a set of IPs. both global and local context problems.
05:43:30 <gkellogg> … We’d like to work off of existing work, there may be 2 phases, first contact (opaque and anonymous).
05:43:37 <manu> q+ to ask about authentication and authorization
05:43:44 <gkellogg> … Later, authenticate and look for devices.
05:43:56 <gkellogg> … IETF doesn’t take into account privacy sufficiently.
05:44:10 <gkellogg> … We’d like to work on IETF resource directories.
05:44:39 <gkellogg> … The TD describes what you’ve discovered. When it’s time to change an ID I’d like to notify users that it’s changed (based on authorization).
05:44:55 <brent> q?
05:45:04 <yoshiaki> yoshiaki has joined #did
05:45:10 <gkellogg> … We’re still in the stage of defining requirements and scope of existing standards.
05:45:17 <burn> ack manu
05:45:17 <Zakim> manu, you wanted to mention that Identity Management may be Verifiable Credentials + DIDs, Discovery sounds like DIDs, Interop profiles might be Verifiable Credentials and/or just
05:45:18 <manu> q?
05:45:20 <Zakim> ... plain 'ol JSON-LD? and to mention authorization capabilities and to ask about authentication and authorization
05:45:29 <phila> phila has joined #did
05:45:33 <phila> q?
05:45:34 <drummond> q?
05:45:44 <drummond> q+
05:45:51 <phila> q+
05:45:53 <gkellogg> manu: Looking at these requiremnts, DIDs are a part of it, but VC might be related too.
05:46:08 <gkellogg> … There are things like object capabilities, authorization capabilities that might fit in.
05:46:08 <kazue> kazue has joined #did
05:46:23 <tplooker> tplooker has joined #did
05:46:27 <gkellogg> … Identify management seems like VC+DIDs.
05:46:52 <tplooker> q+
05:46:54 <gkellogg> … A DID registry might find all DIDs, but not specific.
05:47:02 <gkellogg> mccool: might be two directories.
05:47:10 <horiuchi> horiuchi has joined #did
05:47:14 <gkellogg> manu: The interop profiles are confusing.
05:47:40 <gkellogg> mccool: these are things that are new and challenging. Not everything is relevant to DIDs.
05:47:52 <gkellogg> manu: constantly shifting identifier is challenging.
05:47:53 <mitja> mitja has joined #did
05:47:57 <burn> q?
05:48:20 <gkellogg> mccool: real requirement is privacy. Mutable identifiers is a requirement, otherwise a tracking risk.
05:48:39 <gkellogg> manu: Delegation of authority use cases.
05:48:40 <ken> q+
05:49:03 <drummond> +1 to delegation of authority being another DID + verifiable credentials capability
05:49:07 <gkellogg> … People working on object capabilities.
05:49:31 <gkellogg> mccool: I didn’t highlight security issues, but we have somethings OAuth related we’re working on.
05:49:46 <burn> zakim, close the queue
05:49:46 <Zakim> ok, burn, the speaker queue is closed
05:49:53 <gkellogg> … We need to sort how out to handle HTTPS in a local context, and don’t want to define schemes.
05:50:05 <burn> ack dezell
05:50:05 <Zakim> dezell, you wanted to ask about slide 12
05:50:08 <gkellogg> … There are things like ACE and tokens that provide similar capabilities.
05:50:35 <gkellogg> dezell: I’d reather see “identifier management” than “identity mangaement”
05:50:40 <burn> ack drummond
05:50:51 <danbri> +1 re identifier management
05:51:09 <yoshiaki_> yoshiaki_ has joined #did
05:51:13 <JoeAndrieu> +1 for identifier management
05:51:32 <gkellogg> drummond: One of the DID methods is sovrin, which is a public ledger for DIDs with a foundation behind it with 5 different task forces, including SSI and IoT.
05:51:47 <gkellogg> … Those groups would love to talke with you about it.
05:52:05 <gkellogg> … The code-base is at Hyper Ledger.
05:52:11 <burn> ack phila
05:52:12 <gkellogg> mccool: we’re interested in that stuff.
05:52:20 <dsr> dsr has joined #did
05:52:37 <jc> jc has joined #did
05:52:57 <mitja> mitja has joined #did
05:52:59 <gkellogg> phila: THe Barcode people would say you don’t need any of that, you already have it.
05:53:10 <burn> ack tplooker
05:53:27 <burn> zakim, open the queue
05:53:27 <Zakim> ok, burn, the speaker queue is open
05:53:39 <gkellogg> tplooker: Cryptography and self-authenticating identifiers could be useful in a TD.
05:53:39 <yoshiaki> yoshiaki has joined #did
05:53:50 <yofukami> yofukami has joined #did
05:54:00 <gkellogg> mccool: we also have security risks on if people fiddle with a TD to point elsewhere.
05:54:02 <burn> ack ken
05:54:03 <drummond> Can Michael share contact info so we can reach him after this session?
05:54:43 <gkellogg> ken: Some people thing about DIDs as unique identifiers, but you could have multiple DIDs associated with a Thing that are used in different ways.
05:55:00 <gkellogg> mccool: could be pair-wise identifiers.
05:55:26 <gkellogg> burn: (contact info to be sent out)
05:56:20 <gkellogg> topic: work through issues
05:57:03 <yoshiaki> yoshiaki has joined #did
05:58:48 <gkellogg> ivan: Do we have a quarum for making decisions with 7 pro-forma members.
05:59:16 <gkellogg> brent: people can always object.
06:00:15 <gkellogg> subtopic: Use Case issues
06:00:34 <gkellogg> brent: If we want to proceed with an existing issue, we’ll create a new one and point back to the original.
06:00:48 <mitja> mitja has joined #did
06:01:11 <gkellogg> … issue #2.
06:01:16 <gkellogg> manu:  what’s the action?
06:01:38 <gkellogg> JoeAndrieu: I read the issue and link and think we’ve addressed it.
06:02:31 <danbri_> danbri_ has joined #did
06:02:53 <gkellogg> burn: If the CCG thinks ie can be closed, we don’t need to deal with it.
06:03:00 <jc> jc has joined #did
06:03:21 <gkellogg> brent: issue #3 – long term credentials and timestamps.
06:03:54 <drummond> drummond has joined #did
06:04:10 <gkellogg> JoeAndrieu: On Ledger there are timestamp attributes you can take advantage of, but we don’t have a use ase.
06:04:20 <yoshiaki_> yoshiaki_ has joined #did
06:04:38 <mitja_> mitja_ has joined #did
06:05:39 <gkellogg> … We’ll adopt it in the WG, but we’ll leave it open until it’s done.
06:06:01 <ivan> -> https://github.com/w3c/did-use-cases Use cases' repository
06:06:26 <gkellogg> brent: We’ll bring it over.
06:07:02 <gkellogg> … issue #5 – 10 design goals
06:07:34 <gkellogg> JoeAndrieu: Think it’s resolved.
06:07:41 <selfissued> selfissued has joined #did
06:07:56 <gkellogg> brent: issue #6 – differentiate DIDs and DID Documents
06:07:57 <selfissued> Can you post the repository URL again?  I'd lost my IRC connection.
06:09:07 <gkellogg> JoeAndrieu: There is a version of what he’s asked for that was part of the draft, but I ddin’t have time to get concensus. I like the suggestion.
06:09:14 <gkellogg> ivan: Not a use case issue, but a separate document.
06:09:27 <gkellogg> JoeAndrieu: Sometimes the use case document as about identifying gaps.
06:09:50 <gkellogg> manu: It seems vague; I wouldn’t know what to do.
06:10:30 <gkellogg> brent: I think there’s some value here, and if he things we can do something, we should bring it over.
06:10:32 <mitja> mitja has joined #did
06:10:39 <chaals> chaals has joined #did
06:10:59 <gkellogg> JoeAndrieu: This chart (in my head) is going to be a catalyst for controversy. Both good and bad.
06:11:15 <gkellogg> brent: Use cases or another note.
06:12:01 <gkellogg> … We could move the issue over (to WG)
06:12:07 <jc> jc has joined #did
06:12:48 <gkellogg> action: burn to move issue to WG for potential new note.
06:13:27 <selfissued> https://github.com/w3c/did-wg is the overall repository, right?
06:13:38 <selfissued> What are the repository URLs for the deliverables?
06:14:33 <gkellogg> brent: issue #10 – portability/substitutabiliy
06:15:06 <gkellogg> JoeAndrieu: There have been schemes discussed about how you might take a DID from one method and forward to a DID on another method. We should add it.
06:15:18 <gkellogg> brent: We’ll move it over.
06:16:41 <gkellogg> subtopic: spec issues
06:17:42 <gkellogg> brent: issue #82 – Fragment identify semantics
06:18:01 <gkellogg> … We may determine that the CCG triage is not what we’d do.
06:18:52 <gkellogg> manu: We should pull this in. Not editorial.
06:20:28 <gkellogg> manu: We’re trying to say that frag identifiers are associated with the mime type.
06:20:54 <gkellogg> ivan: It may be that the fragment identifier is defined for the JSON-LD type.
06:21:43 <JoeAndrieu> JoeAndrieu has joined #did
06:21:54 <manu> gkellogg: I believe that JSON-LD does describe how MIME types are related ... fragments, look in IANA section. We do heavily make use of fragment identifiers.
06:22:08 <manu> gkellogg: I'd say it's done, if not, it should be an action to refer to JSON-LD group.
06:22:39 <gkellogg> peacekeeper: It sounds like the DID doc is defining fragment semantics for a DID scheme, but it shouldn’t do that.
06:22:53 <burn> q+
06:22:58 <gkellogg> ivan: issue should be brought over.
06:23:15 <Arnaud> Arnaud has joined #did
06:23:22 <peacekeeper> See https://w3c-ccg.github.io/did-spec/#fragment
06:23:36 <mitja> mitja has joined #did
06:23:38 <JoeAndrieu> q+ to ask about CCG did-spec issue management
06:23:52 <gkellogg> burn: danbri had a comment about frag identifiers. If we’re going to allow for them, the documents returned need to have a media type.
06:24:05 <JoeAndrieu> ack burn
06:24:38 <JoeAndrieu> ack JoeAndrieu
06:24:39 <Zakim> JoeAndrieu, you wanted to ask about CCG did-spec issue management
06:24:46 <gkellogg> brent: issue #112 – intro is incorrect
06:25:00 <gkellogg> … Done, close
06:25:14 <rhiaro> brent, hang on, not necessarily addressed maybe just mentioned as 'towards'
06:25:39 <rhiaro> I think most that got 100% addressed were closed
06:27:17 <rhiaro> okay never mind this one was addressed
06:30:56 <gkellogg> brent: at 4:30 people from PING coming to discuss our relationship.
06:31:03 <jc> jc has joined #did
06:31:26 <ivan> q+
06:32:16 <gkellogg> ivan: There has been a lot of discussion on horizontal review that groups get there too late.
06:32:41 <gkellogg> … When we have FPWD, we should let them know it’s there for them to look at.
06:33:06 <gkellogg> … Also, PING, I18N and Accessibility have forms for us to consider.
06:33:36 <gkellogg> … There’s a lot to look at, but much is irrellevant. We should not wait for CRS, but do way before.
06:34:45 <gkellogg> s/CRS/CR/
06:35:00 <ivan> ivan has joined #did
06:40:24 <tm> tm has joined #did
06:50:29 <jc> jc has joined #did
06:50:38 <jc> jc has joined #did
06:50:46 <phila> phila has joined #did
06:50:49 <phila> phila has left #did
06:52:03 <mitja> mitja has joined #did
06:55:13 <gkellogg> gkellogg has joined #did
06:56:53 <gannan> gannan has joined #did
06:57:35 <jc> jc has joined #did
06:58:29 <yoshiaki> yoshiaki has joined #did
07:00:18 <selfissued> present+
07:01:01 <selfissued> It is time
07:01:30 <horiuchi> horiuchi has joined #did
07:02:01 <selfissued> scribe+
07:02:03 <mitja> mitja has joined #did
07:02:18 <yofukami> yofukami has joined #did
07:02:31 <selfissued> Making the homepage more visitor-friendly is one possible topic
07:02:33 <jc> jc has joined #did
07:02:55 <selfissued> We could discuss DID Controller - proposed by Joe
07:03:21 <selfissued> DID Controller is related to DID Authentication
07:04:20 <selfissued> Joe: There was a question on the CCG mailing list about the Controller property and the Authentiation property
07:04:37 <selfissued> ... He didn't make it through understanding the relationships
07:04:58 <hhan> hhan has joined #did
07:05:07 <kazue> kazue has joined #did
07:05:35 <JoeAndrieu> JoeAndrieu has joined #did
07:05:42 <manu> s/Making the/brent: Making the/
07:06:10 <manu> s/We could/brent: We could/
07:06:19 <selfissued> JoeAndrieu: asked Marcus about it
07:06:26 <grantnoble> grantnoble has joined #did
07:06:56 <manu> s/DID Controller/JoeAndrieu: DID Controller/
07:07:08 <selfissued> Marcus: there are multiple ways of seeing it and different views
07:07:40 <selfissued> Marcus: There are many DID methods that don't use the DID document
07:08:07 <selfissued> Marcus: There isn't a method-independent interpretation
07:08:38 <selfissued> JoeAndrieu: There was a discussion between Sethi Shivam and Daniel Hardman
07:08:43 <ivan> ivan has joined #did
07:08:55 <selfissued> JoeAndrieu: The spec text is not aligned with what most people think it should mean
07:09:13 <horiuchi_> horiuchi_ has joined #did
07:09:20 <selfissued> Dan: If it's not in the authentication section of the document, where is it?
07:09:40 <selfissued> manu: Some methods will use the Authentication section to allow you to update the document
07:09:53 <selfissued> manu: Other methods may do something totally different
07:10:05 <selfissued> manu: This is old text that is wrong and needs to be updated
07:10:33 <selfissued> JoeAndrieu: The keys that can be used to update can be used to impersonate
07:11:03 <selfissued> manu: In verus1, DID documents are capabilities
07:11:42 <selfissued> manu: In verus1, different keys are used to update the document
07:11:48 <selfissued> manu: Will open an issue
07:11:51 <ivan> s/verus1/veres1/
07:12:36 <burn> s/verus1/veres1/g
07:13:03 <selfissued> Marcus: The name of the top-level property is Controller, whose value may be another DID
07:13:07 <horiuchi_> horiuchi_ has joined #did
07:13:26 <selfissued> manu: The Controller field tells you what DID controls that document
07:13:34 <takuya> takuya has joined #did
07:14:00 <JoeAndrieu> q?
07:14:20 <selfissued> manu: This could be used by organizations
07:14:46 <selfissued> JoeAndrieu: For BTCR, the Controller would be ignored
07:15:12 <ivan> q-
07:15:46 <selfissued> Dan: It's not clear to me what the difference between Control and Authentication is
07:16:10 <peacekeeper> peacekeeper has joined #did
07:16:19 <selfissued> JoeAndrieu: Whoever controls the document is omnipotent for all content in the DID document
07:17:09 <selfissued> JoeAndrieu: The Authentication section specifies the mechanism for authenticating as the DID - a legitimate claimant to act as a subject of the did
07:17:41 <selfissued> JoeAndrieu: ... so that entities using that Authentication mechanism can use the DID for DID auth, but can't necessarily change the DID
07:18:10 <selfissued> Dan: We talk about who proves control over the did by authenticating to it, not by being the controller
07:18:22 <yoshiaki> yoshiaki has joined #did
07:18:25 <selfissued> JoeAndrieu: We have a limited authorization to authenticate on behalf of the DID
07:18:33 <selfissued> JoeAndrieu: These semantics are confusing
07:18:39 <brent> q?
07:18:48 <brent> q+
07:19:15 <burn> q+
07:19:22 <selfissued> selfissued: Is the terminology in the document currently contradictory and confusing?
07:19:23 <brent> ack brent
07:20:20 <selfissued> brent: Yes
07:20:29 <tung> tung has joined #did
07:20:45 <selfissued> JoeAndrieu: There's a distinction between who can change the DID document and who can authenticate as it
07:20:56 <horiuchi> horiuchi has joined #did
07:21:21 <selfissued> Dan: Asked in one case whether the party is a controller or an authenticator
07:21:34 <selfissued> JoeAndrieu: Related to subject versus holder
07:21:44 <selfissued> JoeAndrieu: Sometimes they are the same - sometimes they are not
07:22:03 <selfissued> brent: In the subject versus holder debates we had two terms
07:22:15 <selfissued> JoeAndrieu: A possible term is governor
07:22:29 <selfissued> Dan: The term DID Subject makes sense to me
07:22:53 <brent> q?
07:23:40 <selfissued> Drummond: If the DID Subject is the entity identified by the DID, then we could separate the DID Controller from the DID Document Controller
07:24:02 <selfissued> ivan: I don't like the term DID Document Controller
07:25:06 <brent> q+
07:25:17 <drummond> drummond has joined #did
07:25:19 <brent> ack burn
07:25:20 <drummond> q+
07:25:21 <selfissued> selfissued: What are the next steps to resolve this?
07:25:37 <selfissued> Brent: Wanted to ask the same thing
07:25:51 <peacekeeper> q+
07:25:54 <brent> ack brent
07:25:54 <selfissued> Brent: We've created several issues. Manu, can you point us to them?
07:25:56 <brent> q?
07:26:14 <selfissued> manu: They are issues #2 and #3
07:26:14 <manu> Created two new issues: https://github.com/w3c/did-spec/issues/2
07:26:21 <JoeAndrieu> q+
07:26:25 <manu> ... and https://github.com/w3c/did-spec/issues/3
07:27:07 <selfissued> Drummond: If we use DID subject as the entity identified by the DID, the other two roles have to be named
07:27:33 <selfissued> Drummond: The entity the proves control of the DID document
07:27:33 <manu> q+
07:27:54 <selfissued> Drummond: The entity that can authenticate that it has control of the DID
07:28:02 <horiuchi_> horiuchi_ has joined #did
07:28:12 <selfissued> Drummond: The entity that controls the document could be one of the parents - the other could be the other parent
07:28:24 <selfissued> Drummond: I'm not suggesting terms for the other two
07:28:25 <brent> q?
07:28:29 <brent> ack drummond
07:28:55 <burn> q+ to give guardianship or prison example
07:28:58 <selfissued> Marcus: My assumption in the DID spec is that we are mostly defining things that are method independent
07:29:05 <brent> ack peacekeeper
07:29:17 <selfissued> Marcus: The controller construct doesn't make sense for BTCR
07:29:43 <selfissued> Marcus: ... how to log into a Web Site with a DID
07:30:10 <selfissued> brent: We're going to pause that conversation now for the PING discussion
07:30:35 <selfissued> brent: I've been working in the PING for a while
07:30:54 <selfissued> brent: A difficulty of the work is connecting with the working groups to provide timely, actionable feedback
07:31:16 <selfissued> brent: We want to know who you are and how to best work with you
07:32:03 <selfissued> Christine Runnenger: It would be useful to have an overview of what you're trying to accomplish in this group
07:32:03 <burn> Tara Whalen, PING co-chair
07:32:35 <ivan> guests+ Tara Whalen
07:32:44 <manu> q+ to elaborate on privacy elephants in the room. :)
07:32:46 <ivan> guests+ Christine Runnenger
07:32:46 <selfissued> brent: Our primary recommendation is to define Decentralized Identifier
07:33:08 <selfissued> brent: Identifiers that don't require association with a centralized party
07:33:15 <drummond> Identity, security, and privacy are the holy trinity of the Web.
07:33:28 <selfissued> brent: You can prove control of them independent of third parties
07:33:47 <selfissued> brent: There's the DID, the DID Document, and DID Methods
07:34:33 <selfissued> drummond: I work in one of the companies in the space
07:34:52 <selfissued> drummond: DIDs are foundational technology for privacy by design at Web scale
07:35:38 <selfissued> drummond: Architecture supports the range from public to pairwise
07:36:13 <selfissued> drummond: It's useful talking about the relationship between DIDs and Verifiable Credentials
07:36:26 <selfissued> manu: PING came into Verifiable Credentials late
07:36:43 <selfissued> manu: The larger ecosystem is Verifiable Credentials
07:37:15 <selfissued> manu: We want people to be able to go organizations and get credentials from them and share them where they choose
07:37:31 <selfissued> manu: Correlation is an issue
07:37:53 <selfissued> manu: Question is how correlatable is the identifier
07:38:04 <selfissued> manu: There are currently 30 types of DIDs
07:38:12 <jc> jc has joined #did
07:38:22 <brent> q?
07:38:38 <selfissued> manu: These are about the identifier
07:38:57 <selfissued> manu: Cryptography lets you do authentication and know who you are talking to
07:39:02 <JoeAndrieu> q+
07:39:11 <selfissued> manu: We all care deeply about privacy
07:39:21 <gkellogg> ack: manu
07:39:34 <gkellogg> ack manu
07:39:34 <Zakim> manu, you wanted to elaborate on privacy elephants in the room. :)
07:39:45 <selfissued> manu: Is there a way to shift where your information is stored, putting the individual in charge?
07:40:01 <selfissued> manu: With their software helping them make better privacy decisions
07:40:11 <selfissued> manu: DIDs can be like super tracking cookies
07:40:35 <selfissued> manu: Over their lifetime, the people they share them with can do correlation behind the person's back
07:40:56 <selfissued> manu: There are zero-knowledge proofs being used with Soveriegn
07:41:15 <yoshiaki> yoshiaki has joined #did
07:41:31 <yofukami> yofukami has joined #did
07:41:36 <selfissued> manu: The feedback that the WG would like from the PING is what privacy issues they see
07:41:53 <gkellogg> q?
07:42:08 <selfissued> Dan: We had an intention that these identifiers would be reasonably cheap and easy to create
07:42:21 <selfissued> Dan: There are use cases where you'd use different identifiers
07:42:28 <gkellogg> s/Dan:/burn:/g
07:42:42 <chaals> chaals has joined #did
07:42:45 <selfissued> Dan: If to sign in, I have to demonstrate that I'm over 18...
07:43:13 <gkellogg> ack burn
07:43:13 <Zakim> burn, you wanted to give guardianship or prison example
07:43:26 <selfissued> Tara: It's good to hear that there are many security and privacy engineers working on this
07:43:55 <ivan> q+
07:44:09 <Chunming> Chunming has joined #did
07:44:10 <drummond> q+
07:44:21 <selfissued> Tara: It's good to give us information early
07:44:43 <jc> jc has joined #did
07:44:45 <selfissued> Tara: You seem to be miles ahead of some of the other groups
07:44:58 <selfissued> Tara: Where are you in the process?
07:45:37 <selfissued> Dan: We are not yet at first public working draft
07:45:51 <Kangchan_> Kangchan_ has joined #DID
07:45:52 <selfissued> Brent: We selected what will become our first editor's draft yesterday
07:45:57 <drummond> q?
07:46:07 <selfissued> Christine: It's apparent to me that you're early in the process
07:46:14 <selfissued> Christine: Thank you for reaching out early
07:46:35 <selfissued> Christine: Look at the updated security and privacy questionairre
07:47:00 <selfissued> Christine: You're in the best position to decide when you need input from us
07:47:19 <manu> q+
07:47:25 <selfissued> Christine: For instance, ask us to look at specific issues in GitHub
07:47:45 <ivan> ack JoeAndrieu
07:48:02 <selfissued> JoeAndrieu: There are specifications for DIDs and method specifications
07:48:09 <selfissued> JoeAndrieu: We'll be enabling self-tests
07:48:50 <selfissued> Christine: Is what Joes was describing like a profile?
07:49:02 <selfissued> selfissued: (the question wasn't answered)
07:50:01 <selfissued> ivan: Many of our use cases are different than others you may be familiar with
07:50:01 <brent> ack ivan
07:50:01 <JoeAndrieu> ack ivan
07:50:05 <JoeAndrieu> ack drummond
07:50:07 <brent> ack ivan
07:50:22 <manu> q+ to note that the mistake we've made before is treating the spec/feedback as an isolated thing... it's not, it's part of a larger ecosystem and we need to figure out how to talk about that.
07:50:30 <selfissued> drummond: The specification we're chartered to do creates a new kind of URI - a DID
07:50:57 <selfissued> drummond: Explained the syntax of a DID URI
07:51:22 <selfissued> drummond: There's an informal registry that the Credentials Community Group maintains of DID types
07:51:51 <selfissued> Every DID method can define its own protocol
07:52:31 <selfissued> selfissued: What are the privacy implications of each DID method defining its own protocol
07:52:48 <selfissued> drummond: Every DID method will have to have its own privacy analysis
07:52:53 <manu> q+ to ask if there is anything we can tag our issues w/ wrt. privacy that would help you understand what privacy topics we've covered.
07:53:10 <selfissued> drummond: The spec is already the result of three years of work
07:53:41 <selfissued> drummond: It's a requirement on DID method specifications that they have a Privacy Considerations section and that they address certain things
07:53:42 <burn> q?
07:53:53 <selfissued> drummond: It would be good to have PING review these guidelines
07:53:57 <manu> ack manyu
07:54:00 <manu> ack manu
07:54:00 <Zakim> manu, you wanted to note that the mistake we've made before is treating the spec/feedback as an isolated thing... it's not, it's part of a larger ecosystem and we need to figure
07:54:03 <Zakim> ... out how to talk about that. and to ask if there is anything we can tag our issues w/ wrt. privacy that would help you understand what privacy topics we've covered.
07:54:36 <selfissued> manu: A mistake we've made in the past interacting with PING is isolating the conversation to the spec we're working on
07:54:45 <jc> jc has joined #did
07:55:02 <selfissued> manu: Data models don't have the same privacy implications as protocols
07:55:27 <selfissued> manu: We need to discuss the ecosystems wholistically
07:56:18 <selfissued> manu: We could say "it's just an identifier" but there's a larger usage context with privacy implications
07:56:54 <drummond> q+ to ask PING about their scope and what they might be able to help us with
07:57:17 <selfissued> manu: Can we tag our issues with a privacy tag to help you when you use our GitHub issue tracker?
07:57:28 <selfissued> manu: Or is there a more effective way to work?
07:57:40 <selfissued> Christine: Tagging issues would be fantastic
07:57:45 <ivan> q+
07:58:18 <selfissued> Christine: The W3C staff need to use some machinery to create the tag
07:58:30 <selfissued> Christine: You could appoint Brent as your PING liaison
07:58:45 <selfissued> ivan: Is this mechanism already operational?
07:59:24 <selfissued> ivan: There are special labels that you can add that will ping PING
07:59:38 <brent> ack ivan
07:59:41 <brent> ack drummond
07:59:41 <Zakim> drummond, you wanted to ask PING about their scope and what they might be able to help us with
08:00:03 <selfissued> drummond: Soveriegn spends a lot of time on privacy
08:00:51 <selfissued> drummond: DIDs and Verifiable Credentials used well are the basis of Privacy by Design at Internet scale
08:01:11 <ivan> s/Soveriegn/Sovereign/
08:01:17 <selfissued> drummond: We'd like to examine separately from our spec the use of DIDs to create an ecosystem
08:01:56 <brent> q?
08:01:58 <selfissued> drummond: Used wrong, DIDs can be the greatest tracking cookie ever
08:02:17 <selfissued> drummond: Used right, they can be a solution to surveilance capitalism
08:02:42 <selfissued> Christine: I worry that DIDs could be used for evil
08:03:04 <selfissued> Christine: You appear to be catering for the use case of a globally unique persistent identifier
08:03:26 <selfissued> Christine: It might be worthwhile having a chat with the Security working group
08:04:03 <selfissued> drummond: Security, privacy, and identity are a triangle
08:04:27 <selfissued> drummond: The Security Considerations section is also quite long
08:04:34 <selfissued> Brent: Thank you very much for coming!
08:05:12 <selfissued> Christine: Did the community group produce a Use Cases document?
08:05:20 <selfissued> drummond: Yes - and it's a good one
08:05:29 <selfissued> JoeAndrieu: Feel free to reach out to me about it
08:06:01 <ivan> Topic: Open topics
08:06:13 <selfissued> Brent: We can switch back to open topics now
08:06:18 <manu> q+ to raise larger issues?
08:06:24 <burn> q+
08:07:23 <selfissued> JoeAndrieu: I think that third role may be acting on behalf of the DID:  A term could be DID Actor
08:07:25 <drummond> +1 to DID actor
08:07:32 <drummond> q+
08:07:32 <selfissued> JoeAndrieu: Or it could be DID User
08:07:33 <deiu> q+ to talk about actor and delegation
08:07:38 <manu> q+ to work mode
08:07:53 <manu> q+ to work mode for editors
08:07:57 <brent> ack burn
08:08:02 <selfissued> Dan: Drummond used an example of a child and two parents. I care a lot about the guardian use case.
08:08:03 <manu> q+ for umm, who are the editors :P
08:08:22 <dezell> dezell has joined #did
08:08:23 <selfissued> Dan: There are cases where someone else has some of the rights of a person on their behalf
08:08:39 <selfissued> Can: There are also the courts, which can change those relationships
08:08:42 <brent> q?
08:08:48 <burn> ack manu
08:08:48 <Zakim> manu, you wanted to raise larger issues? and to work mode and to work mode for editors and to discuss umm, who are the editors :P
08:08:53 <selfissued> Dan: We should have an example illustrating these use cases
08:09:02 <drummond> Reminder to talk about several examples of the 3 roles
08:09:29 <selfissued> Brent: Andre, is your comment related to the DID Controller, etc. conversation?
08:09:31 <manu> q+ to who are the editors :P, work mode for editors, and to raise larger issues.
08:09:33 <brent> ack deiu
08:09:33 <Zakim> deiu, you wanted to talk about actor and delegation
08:09:57 <manu> q+ to note that we're bikeshedding names now
08:10:03 <selfissued> Andre: We speak of delegator and delegate.  Actor would be confusing to many people.
08:10:13 <selfissued> selfissued: +1 that "Actor" is overused and confusing
08:10:22 <selfissued> drummond: There's agreement that three terms are needed
08:10:35 <JoeAndrieu> s/Andre:/deiu:/
08:10:46 <selfissued> drummond: We should all take the action item to think about this and possibly take it to the list
08:11:04 <JoeAndrieu> +1 delegate
08:11:14 <selfissued> Brent: We have two issues about this - #2 and #3
08:11:52 <ivan> present+ deiu
08:11:58 <selfissued> Brent: Should the issues be updated to talk about the three roles?
08:12:02 <selfissued> manu: Yes
08:12:09 <yoshiaki_> yoshiaki_ has joined #did
08:12:22 <ivan> q?
08:12:27 <ivan> q+
08:12:48 <selfissued> Brent: With these issues, do we have enough recorded that we can move to a different topic?
08:13:07 <manu> q?
08:13:30 <selfissued> Dan: Let's get other possible topics out on the table
08:13:37 <selfissued> Dan: One is external communications
08:13:46 <selfissued> Dan: Such as who are the editors
08:13:59 <jc> jc has joined #did
08:14:13 <manu> ack manu
08:14:13 <Zakim> manu, you wanted to who are the editors :P, work mode for editors, and to raise larger issues. and to note that we're bikeshedding names now
08:14:23 <burn> ack drummond
08:14:24 <burn> ack ivan
08:14:46 <selfissued> Manu: It would be good if the editor's were given free reign to clean up the spec
08:15:06 <selfissued> manu: There are larger issues that might help the editors work faster
08:15:22 <selfissued> manu: Some things could be ripped out
08:15:44 <selfissued> manu: What do we think we can rip out before we start adding stuff?
08:15:48 <drummond> +1 to the editors being assigned to do a cleanup pass
08:16:35 <selfissued> Brent: The three CCG members who have edited the CCG spec are Manu, Drummond, and Marcus
08:16:44 <manu> q?
08:16:49 <manu> q+
08:16:55 <selfissued> Brent: Do you all want to continue editing and do even more work than before?
08:17:00 <drummond> Yes, I am indeed married to this spec :-)
08:17:12 <selfissued> Brent: All three will continue as editors
08:17:14 <drummond> q+
08:17:42 <selfissued> Dan: We are lookign for people who will do the work
08:17:56 <selfissued> Dan: We may adjust the editors as we see other people contributing
08:18:20 <selfissued> Dan: We have new people and organizaitons that weren't involved in the CCG
08:18:34 <selfissued> Dan: Please come talk to us if you want to be considered as an editor
08:18:42 <selfissued> Dan: We're paying attention to who's doing the work]
08:18:44 <brent> q?
08:19:17 <selfissued> ivan: All the repositories have separate teams that have write and administrator access
08:19:36 <selfissued> ivan: Editors could directly commit
08:20:23 <peacekeeper> q+
08:20:33 <brent> ack manu
08:20:47 <selfissued> selfissued: We should always use PRs to enable working group review
08:20:55 <JoeAndrieu> q+
08:21:06 <brent> ack drummond
08:21:08 <selfissued> manu: We should add Amy as an editor.  She'll be doing the work anyway and should get credit for it.
08:21:11 <ivan> ack drummond
08:21:24 <selfissued> drummond: Amy did outstanding editorial work
08:21:39 <selfissued> Brent: The chairs will have a conversation about that
08:21:48 <brent> q?
08:22:22 <selfissued> Dan: If the editorial team gets large, there's an interesting question about editorial decisions are made
08:22:41 <selfissued> Dan: Four is a really large group for active editors of a spec
08:22:48 <brent> ack peacekeeper
08:23:10 <selfissued> Marcus: I would have also proposed Amy
08:23:15 <brent> q?
08:23:28 <brent> ack JoeAndrieu
08:23:34 <selfissued> Marcus: In the CCG, we always created PRs and had editors approve it
08:23:46 <selfissued> JoeAndrieu: I also want to endorse Amy
08:23:54 <brent> q?
08:24:00 <gkellogg> q+
08:24:14 <brent> ack gkellogg
08:24:15 <selfissued> Joe: If four are too many, you should consider which of you are willing to give up your spot for Amy
08:24:42 <selfissued> Gregg: It's typical to also list Authors as well as Editors
08:25:04 <drummond> And that means Amy is the Red Queen, right? ;-)
08:25:25 <selfissued> Dan: Are all the editors expecting to do editing work or just contributing content?
08:26:06 <selfissued> ivan: What about editors for the Use Cases document?
08:26:17 <selfissued> Brent: Joe, will you continue?
08:26:26 <selfissued> JoeAndrieu: Yes
08:26:28 <deiu> q+ to point out PhilA volunteered to be editor of the UCR doc
08:26:35 <selfissued> JoeAndrieu: And I'd like a partner in crime
08:26:42 <drummond> +1
08:27:07 <selfissued> ivan: Phil Archer may want to be a Use Case editor
08:27:18 <deiu> q-
08:27:48 <selfissued> Brent: Editors for the Rubric
08:28:29 <selfissued> JoeAndrieu: Point of order: We do not yet have a Rubric work item.  We should defer until we do.
08:29:06 <manu> q+
08:29:19 <deiu> ack manu
08:29:27 <drummond> q+
08:29:30 <selfissued> manu: A lot of the CCG work lately has been workign on the charter
08:29:46 <ivan> s/workign/working/
08:29:52 <selfissued> manu: Over the past two years things have changed in implementations that have not been tracked by the specification
08:30:10 <selfissued> manu: An editorial pass seems necessary
08:30:34 <selfissued> manu: For instance, the conversations about did:web put off editorial work
08:30:37 <brent> q?
08:30:41 <brent> q+
08:31:34 <selfissued> manu: It's mostly to remove things that no longer apply
08:31:34 <burn> q+
08:31:49 <brent> ack drummond
08:31:56 <selfissued> selfissued: Changing spec features and normative behaviors is not editorial
08:32:17 <rhiaro> q+ to say there are still a lot of editorial issues, mostly around the overview and introductory sections (https://github.com/w3c-ccg/did-spec/issues?q=is%3Aissue+is%3Aopen+label%3Aeditorial) but we just didn't have time to get to them
08:32:33 <selfissued> drummond: We deprioritized some of the change requests that were coming in
08:32:57 <selfissued> Brent: I would want to know very explicitly what the scope of the work is that the editors propose
08:32:58 <selfissued> q+
08:33:12 <ivan> ack brent
08:33:12 <manu> q+ sounds like we're going to go into "slow painful PR mode" :) -- which is fine, but was hoping to move faster.
08:33:22 <manu> q+ to say sounds like we're going to go into "slow painful PR mode" :) -- which is fine, but was hoping to move faster.
08:33:29 <peacekeeper> q+
08:33:31 <selfissued> Brent: Our first act with the document shouldn't be to cut massive sections out
08:33:38 <drummond> q?
08:33:39 <brent> ack burn
08:33:59 <selfissued> Dan: Minor cleanup that's actually editorial is fine
08:34:31 <selfissued> Dan: It doesn't matter that people in the CCG said that changes should happen.  They didn't appear in the document that they produced.
08:34:52 <jc> jc has joined #did
08:35:19 <selfissued> Dan: One of the biggest risks for groups is editors making changes that people don't feel were agreed to
08:35:49 <drummond> q?
08:36:10 <rhiaro> There are still a lot of editorial issues, mostly around the overview and introductory sections (https://github.com/w3c-ccg/did-spec/issues?q=is%3Aissue+is%3Aopen+label%3Aeditorial) but we just didn't have time to get to them (largely because of other backed up PRs making it difficult I think)
08:36:26 <selfissued> Dan: Not all the people who are editors are experienced W3C Recommendation Track spec issues
08:36:28 <rhiaro> (in answer to the question why weren't these done already)
08:36:32 <Dudley_> Dudley_ has joined #did
08:36:35 <drummond> +1 to Amy's point
08:36:46 <burn> s/Track spec issues/Track spec editors/
08:36:47 <selfissued> Amy: There are a number of editorial cleanups that we didn't have time to get to
08:37:05 <selfissued> Brent: One of the first "editorial" issues we looked at today wasn't actually editorial
08:37:07 <brent> q?
08:37:08 <drummond> q+ to talk about roadmap and terminology
08:37:12 <ivan> q?
08:37:15 <burn> ack rhiaro
08:37:15 <Zakim> rhiaro, you wanted to say there are still a lot of editorial issues, mostly around the overview and introductory sections
08:37:16 <brent> ack rhiaro
08:37:18 <Zakim> ... (https://github.com/w3c-ccg/did-spec/issues?q=is%3Aissue+is%3Aopen+label%3Aeditorial) but we just didn't have time to get to them
08:37:18 <ken> ken has joined #did
08:37:21 <burn> ack selfissued
08:37:26 <selfissued> Dan: We need to be careful
08:37:51 <ken> present+ Ken_Ebert
08:38:04 <brent> selfissued: one of the best practices we instituted was making sure each PR has an issue
08:38:25 <brent> ... I would propose we adopt that working mode
08:38:29 <brent> q?
08:38:34 <burn> ack manu
08:38:34 <Zakim> manu, you wanted to say sounds like we're going to go into "slow painful PR mode" :) -- which is fine, but was hoping to move faster.
08:38:35 <ivan> scribe+ brent
08:38:39 <drummond> +1 to Mike's point
08:38:50 <brent> +1 to mike's point
08:39:16 <selfissued> selfissued: WebAuthn and FIDO2 require that issues be created before PRs are created.  I request that we adopt that working mode.
08:39:31 <chaals> chaals has joined #did
08:40:04 <selfissued> manu: PRs can describe themselves without having an accompanying issue
08:40:04 <brent> q?
08:40:30 <selfissued> Dan: Going into Manu editorial mode may not be the right way to start off the working group
08:40:33 <burn> q+
08:40:38 <brent> ack peacekeeper
08:40:45 <burn> q+ to talk about working mode
08:40:59 <selfissued> Marcus: There are several events in the near future that we could use for editing and triaging - such as IIW
08:41:05 <brent> ack drummond
08:41:05 <Zakim> drummond, you wanted to talk about roadmap and terminology
08:41:21 <manu> q+ to be careful about IIW -- non-WG members contributing/participating...
08:41:24 <selfissued> Drummond: +1 to what Marcus said
08:41:32 <selfissued> Drummond: I agree with what Mike said
08:42:11 <gkellogg> q+
08:42:18 <selfissued> drummond: We should develop a working-group wide ethic of raising issues, discussing them asynchronously, with an eye towards coming to closure
08:42:46 <selfissued> drummond: Terminology is not purely editorial
08:43:04 <selfissued> drummond: We should discuss terminology early to avoid having it slow us down later
08:43:22 <brent> q?
08:43:26 <selfissued> drummond: We should start talking about a roadmap and plan of attack for the next few months. We're not starting from scratch.
08:43:39 <selfissued> drummond: We should try to understand early what the real issues are
08:43:52 <brent> ack burn
08:43:52 <Zakim> burn, you wanted to talk about working mode
08:44:11 <gkellogg> q-
08:44:13 <selfissued> Dan: We haven't talked about what the process is for deciding when something's ready to go in
08:44:44 <selfissued> Dan: One of the strengths of W3C is that we don't have a formal process for making changes
08:45:01 <selfissued> Dan: There's a principle that there's always a double-check
08:45:38 <selfissued> Dan: The editors have a special responsibility to make sure that they only agree to truly editorial changes without working group review
08:46:23 <manu> ack manu
08:46:23 <Zakim> manu, you wanted to be careful about IIW -- non-WG members contributing/participating...
08:46:30 <selfissued> Dan: Call time is valuable.  Some can be used for triaging and assigning issues.  Some can be used for discussions.  The work also needs to happen outside the calls if we're going to finish in two years.
08:46:38 <manu> q+ to say be careful about IIW / non-member participation
08:46:46 <selfissued> Dan: We can also schedule ad hoc calls, if necessary
08:47:18 <selfissued> Dan: We want the minimum amount of process that will result in good results
08:47:20 <jc> jc has joined #did
08:48:00 <selfissued> Dan: We had a spec document that had to get out in the DCWG.  I discovered that Amy was editing the spec without being an editor.  That's not OK.
08:48:01 <brent> q?
08:48:18 <selfissued> Dan: There are things we need to be aware of
08:48:36 <manu> ack manu
08:48:36 <Zakim> manu, you wanted to say be careful about IIW / non-member participation
08:48:54 <selfissued> Dan: We want to make sure that things like that don't happen
08:49:25 <peacekeeper> q+
08:49:37 <brent> ack peacekeeper
08:49:46 <burn> s/was editing the spec/was editing the spec, at Manu's direction,/
08:50:01 <selfissued> selfissued: I assume that IIW what we'd do is create issues and PRs - not do editing
08:50:25 <brent> q?
08:50:30 <selfissued> Dan: Ad hoc F2F meetings are generally frowned upon
08:50:51 <selfissued> Dan: But people in the same space are clearly free to talk about things
08:51:01 <jc> jc has joined #did
08:51:10 <selfissued> Dan: W3C requires 8 weeks notice before a F2F meeting
08:51:18 <deiu> q+ to mention transparency
08:51:18 <brent> q?
08:51:25 <brent> ack deiu
08:51:25 <Zakim> deiu, you wanted to mention transparency
08:51:31 <selfissued> Dan: Talking as individuals is always fine - it's just not a working group meeting
08:51:55 <drummond> q+
08:52:00 <selfissued> Dan: Individuals can always create issues and PRs
08:52:24 <selfissued> drummond: I think that's what Marcus meant
08:52:25 <brent> ack drummond
08:53:15 <selfissued> ivan: It would good if this group had a regular outreach to the outside world
08:53:19 <peacekeeper> q+
08:53:29 <drummond> q+
08:53:30 <selfissued> ivan: Twitter, Facebook, blogs, etc.
08:53:43 <selfissued> ivan: W3C's blog is open to WG chairs
08:53:45 <JoeAndrieu> q+ to mention IDPro article
08:53:54 <burn> I would *love* to delegate blog summaries to someone else :)
08:54:05 <selfissued> ivan: At least once a month it would be good to have communication
08:54:43 <brent> q?
08:54:55 <brent> ack peacekeeper
08:55:10 <selfissued> Marcus: There are several of us who go to many events and can publicize our work
08:55:11 <brent> ack drummond
08:55:28 <selfissued> Drummond: We have two sessions tomorrow
08:55:41 <selfissued> Drummond: Helen is here to do the non-technical version of DIDs
08:56:10 <selfissued> drummond: SSI Meetup is asking for a report
08:56:18 <selfissued> drummond: Is doing a Webinar on Friday
08:56:59 <yoshiroy> yoshiroy has joined #did
08:57:00 <brent> q?
08:57:14 <selfissued> drummond: They want to do a "DID Report" on a regular basis
08:57:25 <ken> q+
08:57:34 <brent> zakim, close the queue
08:57:34 <Zakim> ok, brent, the speaker queue is closed
08:57:40 <yoshiroy> yoshiroy has left #did
08:58:08 <selfissued> Helen is at 11:00
08:58:29 <selfissued> drummond: The second is DID Q&A at 4:30
08:59:15 <selfissued> drummond: It's a Q&A with us as WG members
08:59:24 <brent> ack JoeAndrieu
08:59:24 <Zakim> JoeAndrieu, you wanted to mention IDPro article
08:59:47 <selfissued> JoeAndrieu: I'm on the hook for an article for IDPro
08:59:53 <selfissued> JoeAndrieu: I'd love to have some help
08:59:53 <brent> ack ken
09:00:14 <selfissued> Ken: In the AC meeting we had a report from the Web of Things on their interactions with us
09:00:32 <selfissued> pamela: How long will it take for the editorial triage to happen?
09:00:47 <selfissued> pamela: Do I wait to review the spec until after that or do it it now?
09:00:56 <selfissued> drummond: Go for it - read it now
09:01:19 <selfissued> Brent: Thank you for two days of hard work!
09:01:25 <selfissued> manu: Thank you to the chairs
09:01:36 <ivan> rrsagent, draft minutes
09:01:36 <RRSAgent> I have made the request to generate https://www.w3.org/2019/09/16-did-minutes.html ivan
09:01:36 <ivan> zakim, bye
09:01:36 <ivan> rrsagent, bye
09:01:36 <RRSAgent> I see 1 open action item saved in https://www.w3.org/2019/09/17-did-actions.rdf :
09:01:36 <RRSAgent> ACTION: burn to move issue to WG for potential new note. [1]
09:01:36 <RRSAgent>   recorded in https://www.w3.org/2019/09/16-did-irc#T06-12-48
09:01:36 <Zakim> leaving.  As of this point the attendees have been ivan, rhiaro, Kangchan_, burn, brentzundel, manu, grantnoble, peacekeeper, ken, gkellogg, tplooker, phila, Dudley_Collinson,
09:01:36 <Zakim> Zakim has left #did
09:01:39 <manu> And thank you Ivan!
09:01:40 <Zakim> ... yancy, drummond, igarashi, JoeAndrieu, jay, Kaz_Ashimura, gannan, Joe_Andrieu, dezell, selfissued, deiu, Ken_Ebert