21:51:45 <RRSAgent> RRSAgent has joined #did
21:51:45 <RRSAgent> logging to https://www.w3.org/2019/10/22-did-irc
21:51:51 <Zakim> Zakim has joined #did
21:52:03 <burn> rrsagent, draft minutes
21:52:03 <RRSAgent> I have made the request to generate https://www.w3.org/2019/10/22-did-minutes.html burn
21:52:31 <burn> rrsagent, make logs public
21:53:17 <brent> brent has joined #did
21:53:24 <brent> present+
21:53:51 <TallTed> TallTed has joined #did
21:54:29 <burn> present+
21:54:46 <burn> Meeting: Decentralized Identifier Working Group
21:54:50 <burn> Chair: Dan_Burnett
21:55:16 <burn> Agenda: https://lists.w3.org/Archives/Public/public-did-wg/2019Oct/0011.html
21:59:13 <manu> present+
21:59:38 <TallTed> present+
22:00:11 <markus_sabadello> markus_sabadello has joined #did
22:00:15 <rhiaro> present+
22:00:30 <dlongley> present+
22:00:31 <David_Trang> present+
22:00:46 <markus_sabadello> present+
22:00:54 <agropper> agropper has joined #did
22:01:01 <Did-we-call> Did-we-call has joined #did
22:01:38 <Dudley> Dudley has joined #did
22:02:02 <selfissued> selfissued has joined #did
22:02:10 <selfissued> present+
22:02:17 <daniel> daniel has joined #did
22:02:38 <Dudley> present+
22:02:46 <agropper> present+
22:03:25 <kdenhartog> kdenhartog has joined #did
22:03:42 <manu> scribe+ TallTed
22:03:45 <manu> scribe+ rhiaro
22:03:54 <kdenhartog_> kdenhartog_ has joined #did
22:03:54 <tplooker> tplooker has joined #did
22:03:55 <burn> Topic: Agenda Review, Introductions, Re-introductions
22:04:20 <dmitriz> dmitriz has joined #did
22:04:27 <grantnoble> grantnoble has joined #did
22:04:28 <dmitriz> present+
22:04:32 <burn> Agenda: https://lists.w3.org/Archives/Public/public-did-wg/2019Oct/0011.html
22:06:27 <gannan> gannan has joined #did
22:06:45 <gannan> present+
22:07:17 <TallTed> mike_jones: potential agenda addition of new issue #85, related to issue #67 (key representation)
22:08:02 <selfissued> #85 about differentiating between DID and application data is related to #67 - key representation
22:09:09 <Dudley_> Dudley_ has joined #did
22:09:13 <drummond> drummond has joined #did
22:09:18 <drummond> present+
22:09:22 <TallTed> grantnoble: technical writer in standards group at Pegasys within Consensys
22:09:57 <burn> Topic: New issue assignment process
22:10:49 <TallTed> burn: Editorial team has a good idea of interest in issues, so has been making initial issue assignments outside of calls
22:11:31 <TallTed> ... using github systems.  Assignment means "keep discussion moving" not "solve it" or other specifics.
22:11:51 <TallTed> ... If things stall, reach out to Chairs or Editors, to get time scheduled on a concall.
22:12:40 <TallTed> ... Participation is welcome whether you're assigned or not; if you *want* to be assigned, you can request it.
22:13:11 <burn> Topic: FPWD
22:13:25 <manu> https://github.com/w3c/did-spec/issues
22:13:26 <burn> s/Topic: FPWD//
22:14:12 <TallTed> ( manu reviews issue raisers and assignees )
22:14:37 <drummond> Another way to put it: if you raise an issue and you DON'T want it assigned to you, best to stay that explicitly when you raise the issue.
22:14:57 <TallTed> s/stay that/say that/
22:15:02 <drummond> stay/s/state
22:15:11 <drummond> :-)
22:15:36 <burn> Topic: FPWD
22:15:38 <burn> https://github.com/w3c/did-spec/issues/68
22:16:39 <TallTed> burn: key points...  No Working Draft is meant to imply consensus, and this is explicitly stated in the Status Of The Document.
22:17:53 <TallTed> ... No group agreement is required for most WD publications.  FPWD starts some IPR disclosure clocks which are important to Rec Track.
22:18:38 <TallTed> s/disclosure/commitment/
22:19:53 <burn> q?
22:19:55 <TallTed> ... WG could agree that FPWD happens when Editors think it's ready.  WG could agree on a specific date for FPWD.
22:20:03 <selfissued> q+
22:20:08 <burn> ack selfissued
22:20:30 <TallTed> s/mike_jones/selfissued/
22:20:49 <kyle_denhartog_> kyle_denhartog_ has joined #did
22:21:04 <TallTed> selfissued: thinks the chairs should decide whether FPWD is ready to publish
22:21:17 <manu> q+ to provide a status update to group on readiness of document (as an individual editor).
22:22:19 <TallTed> burn: sure. WG could also decide to publish today, with doc as-is.
22:23:12 <TallTed> ... WG members are expected to speak up if Editors make changes that don't seem to match group decisions, or seriously conflict with their own positions.
22:23:29 <burn> q?
22:24:00 <rhiaro> q+ to mention that after the fpwd we can have echidna set up which makes it super easy to churn out updated WDs so it's not like we need to be stuck with this FPWD for a long time
22:25:02 <burn> ack manu
22:25:02 <Zakim> manu, you wanted to provide a status update to group on readiness of document (as an individual editor).
22:25:03 <rhiaro> q-
22:25:18 <manu> https://github.com/w3c/did-spec/issues/68
22:26:54 <TallTed> manu: this doc has been "in process" for months/years, and all low-hanging fruit / easy issues have already been dealt with; the remaining issues are fairly meaty, and may take some time.
22:27:10 <drummond> q?
22:27:15 <drummond> q+
22:27:26 <burn> ack drummond
22:27:40 <TallTed> ... opinion as editor is that doc could easily go out today
22:28:03 <rhiaro> +1 publishing soon, we can release new WDs when things change. FPWDs don't need to be at all polished
22:28:10 <TallTed> drummond: today would be fine; end-of-month cutoff would also be fine.
22:28:12 <markus_sabadello> +1 agree with manu and drummond, we can publish now or very soon
22:29:05 <drummond> +1 to giving us one week, then publish after next week's call
22:29:22 <drummond> I love it—Halloween Edition!
22:30:00 <TallTed> burn: let's set a one-week deadline for raising anything that someone feels MUST be changed before FPWD
22:30:10 <TallTed> ... objections?
22:30:24 <TallTed> [ crickets ]
22:30:54 <drummond> Let's sneak in a Boris joke somewhere ;-)
22:31:03 <burn> Topic: Specification shortname
22:31:13 <burn> https://github.com/w3c/did-spec/issues/76
22:32:13 <TallTed> burn: Please visit the issue and +1 or -1 on the options listed.  These are non-binding, but helpful.
22:32:17 <daniel> It should though
22:33:00 <burn> Topic: Echidna publishing process
22:33:16 <daniel> Much like shitcoin is now on the Congressional record, so too is Didy McDidface on official W3C WG minutes
22:33:56 <TallTed> burn: Echidna is an automated tool that makes document publishing faster and easier for Chairs & Editors & W3 staff.
22:35:47 <burn> q?
22:35:48 <manu> q+ to suggest a specific publishing mode.
22:35:51 <TallTed> ... Can be set up to do things (like publish a new Working Draft) upon given activity (e.g., every PR merge, or every day, or anytime designated people say so)
22:35:52 <burn> ack manu
22:35:52 <Zakim> manu, you wanted to suggest a specific publishing mode.
22:37:12 <burn> q+ to channel ivan
22:37:32 <TallTed> manu: PRs go through stringent process, so live github preview is generally pretty solid.  Echidna auto-publish on every PR, or daily, seems a good idea to avoid stall on drafts.
22:37:33 <burn> ack burn
22:37:33 <Zakim> burn, you wanted to channel ivan
22:38:37 <manu> I'm fine w/ delaying up to 7 days... publishing every Sunday... but let's please at least use Echidna.
22:38:51 <TallTed> burn: There are different camps on this, disagreeing on the optimal map between Editors' Drafts, Working Drafts, etc.
22:39:02 <rhiaro> +1 rapidfire working drafts to minimise group time deciding
22:39:30 <drummond> +1 to rhiaro
22:39:32 <TallTed> +1 quick WD publication, on whatever basis...
22:39:44 <dlongley> +1
22:39:47 <TallTed> burn: any objections to fast publications?
22:39:49 <manu> +1 quick WD publication ... let Chairs/Staff/Editors decide on frequency....
22:39:58 <burn> I did not ask for fast publication
22:40:12 <dlongley> +1 for the editors to try something out and we'll tweak it :)
22:40:36 <rhiaro> +1 letting editors try something and see how it goes
22:40:40 <burn> I asked for the working group to let the editors start with a working mode they choose with team contact and chair approval and modify if necessary
22:40:44 <drummond> +1
22:40:44 <manu> +1 to that!
22:40:46 <dlongley> +1
22:40:47 <tplooker> +1
22:40:48 <gannan> +1
22:40:54 <grantnoble> +1
22:42:06 <burn> Topic: Key representation
22:42:12 <TallTed> RESOLVED: WG will let the editors start with a working mode they choose with team contact and chair approval and modify if necessary
22:42:26 <burn> https://github.com/w3c/did-spec/issues/67
22:43:14 <manu> https://github.com/w3c/did-spec/issues/85
22:44:11 <TallTed> manu: #85 gets into whether data is about the DID Document, or about the DID Subject, or ...
22:44:16 <selfissued> q+
22:44:24 <burn> ack selfissued
22:44:33 <markus_sabadello> q+
22:45:17 <TallTed> selfissued: logged #85 based on discussion with dlongley, that application data may be formatted however the app likes, while DID data should be formatted according to the standard(s) we set
22:45:23 <burn> ack markus_sabadello
22:46:15 <manu> q+
22:46:15 <TallTed> s/data is about the DID Document, or about the DID Subject/data is application data or DID data /
22:46:35 <burn> ack manu
22:47:03 <selfissued> q+
22:47:32 <TallTed> manu: #85 is a bit of a meta-discussion, which is hard to resolve in a concall, and will make it harder to resolve #67 which is fairly focused
22:47:55 <burn> ack selfissued
22:48:07 <TallTed> ... #85 is still important, just less tangible and harder to grasp
22:48:31 <markus_sabadello> there's a separate issue for "data about the DID subject" vs "data about the DID document": https://github.com/w3c/did-spec/issues/65. this is different from issue 85
22:49:06 <kyle_denhartog_> q+
22:49:16 <TallTed> selfissued: focusing on #67 for now is fine. hope is that folks will keep #85 in mind while doing so.
22:49:17 <manu> https://github.com/w3c/did-spec/issues/67
22:49:40 <manu> https://github.com/w3c/did-spec/issues/67#issuecomment-542480584
22:50:13 <selfissued> q+
22:50:21 <burn> ack kyle_denhartog_
22:50:46 <TallTed> manu: [ summarizes #67 ] ...
22:51:05 <burn> ack selfissued
22:51:15 <TallTed> kyle_denhartog_: one concern is that data size will continue to grow, and that may pose a problem
22:52:01 <TallTed> selfissued: base* encoding does expand the size of things; that's a valid concern.
22:52:19 <burn> q?
22:52:29 <TallTed> ... most important thing is raised as Requirement 11, about future proofing
22:52:41 <dlongley> q+
22:52:56 <TallTed> ... secondarily, JWK proponent (and author, so somewhat biased)
22:52:58 <burn> ack dlongley
22:53:21 <TallTed> dlongley: regretful counter is that we have no control over formats used in the wild
22:54:03 <manu> q+ to put a finer point on the question that's being asked of the group -- only JWK, or JWK and other things.
22:54:10 <TallTed> ... point of expressing your key is to let apps in the wild use your key, and many apps don't consume JWK, so requiring that all keys are expressed in JWK imposes burden on apps now using openssl or nodejs or others
22:54:11 <kyle_denhartog_> q+
22:54:13 <selfissued> q+
22:54:13 <tplooker> q+
22:54:18 <markus_sabadello> q+
22:54:20 <manu> q- later
22:54:35 <burn> zakim, close the queue
22:54:35 <Zakim> ok, burn, the speaker queue is closed
22:55:04 <drummond> Mike, what's your thoughts on Dave's point?
22:55:05 <TallTed> ... would be fantastic if a single representation worked for all, but there are many tools already using multiple representations, so this is hard to force after-that-fact
22:55:30 <TallTed> ... forcing JWK would slow adoption of DIDs and DID Methods
22:55:39 <burn> ack kyle_denhartog_
22:56:03 <Dudley> Dudley has joined #did
22:56:12 <burn> ack selfissued
22:56:14 <TallTed> kyle_denhartog_: to clarify about size -- it's not about encoding; it's about the characters required to express the base mathematics
22:56:36 <kyle_denhartog_> yeah, I can add them
22:56:49 <TallTed> selfissued: [ citation/example requested ]
22:57:55 <burn> ack tplooker
22:57:58 <TallTed> ... dlongley is right that any chosen format would require translation be implemented (once).  idea is that once that translation is written, it's done
22:58:46 <burn> ack markus_sabadello
22:58:50 <TallTed> tplooker: DID resolver is going to be required in any case, let this handle the heavy lifting (the representation translation) for the app
22:59:13 <burn> ack manu
22:59:13 <Zakim> manu, you wanted to put a finer point on the question that's being asked of the group -- only JWK, or JWK and other things.
22:59:15 <TallTed> markus_sabadello: remember that we're separating abstract content from concrete syntax
23:00:19 <TallTed> manu: we'll certainly talk about this again next time.  the question is not "JWK or something-else", it's "something and JWK" -- what is the something, that is capable of handling PEM or PEM in CBOR or ....?
23:01:00 <kyle_denhartog_> @manu thank you for that clarification. In that point, I'm less opinionated about this.
23:01:02 <burn> Thanks all.  Will continue this discussion next week
23:01:02 <dlongley> options: 1. support ONLY JWK, 2. support JWK and other popular formats
23:01:30 <burn> rrsagent, draft minutes
23:01:30 <RRSAgent> I have made the request to generate https://www.w3.org/2019/10/22-did-minutes.html burn
23:01:35 <TallTed> ... question is whether to support *only* JWK, or JWK-plus-others
23:01:43 <manu> +1
23:01:48 <manu> That's what the group has to decide.
23:01:49 <TallTed> rrsagent, draft minutes
23:01:49 <RRSAgent> I have made the request to generate https://www.w3.org/2019/10/22-did-minutes.html TallTed
23:03:21 <TallTed> fifth time's the charm!
23:03:47 <gannan> gannan has joined #did
23:13:27 <gannan> gannan has joined #did
23:59:21 <gkellogg_> gkellogg_ has joined #did