07:18:36 <RRSAgent> RRSAgent has joined #did
07:18:36 <RRSAgent> logging to https://www.w3.org/2019/10/29-did-irc
07:18:37 <ivan> rrsagent, set log public
07:18:37 <ivan> Meeting: DID Working Group Telco
07:18:37 <ivan> Chair: burn
07:18:37 <ivan> Date: 2019-10-29
07:18:37 <ivan> Agenda: https://lists.w3.org/Archives/Public/public-did-wg/2019Oct/0018.html
07:18:37 <ivan> ivan has changed the topic to: Meeting Agenda 2019-10-15: https://lists.w3.org/Archives/Public/public-did-wg/2019Oct/0018.html
07:36:25 <YUE> YUE has joined #did
07:39:11 <YUE> YUE has left #did
07:49:25 <Yue> Yue has joined #did
07:50:04 <burn> burn has joined #did
07:51:09 <burn> burn has changed the topic to: 29 October 2019 DID WG Agenda: https://lists.w3.org/Archives/Public/public-did-wg/2019Oct/0018.html
07:51:25 <burn> Present+
07:53:02 <ivan> present+
07:55:37 <Yue> present+
07:56:48 <David_Trang> David_Trang has joined #did
07:57:49 <brent> brent has joined #did
07:58:03 <brent> present+
07:58:21 <David_Trang> present+
07:59:28 <TallTed> TallTed has joined #did
07:59:54 <Dudley> Dudley has joined #did
07:59:57 <selfissued> selfissued has joined #did
07:59:58 <ivan> present+ dudley
08:00:06 <Dudley> present+
08:00:07 <selfissued> present+
08:00:33 <manu> present+
08:01:05 <markus_sabadello> markus_sabadello has joined #did
08:01:08 <ivan> present+ TallTed
08:01:16 <ivan> present+ markus_sabadello
08:03:29 <ivan> scribe+ markus_sabadello
08:03:31 <agropper> agropper has joined #did
08:04:03 <markus_sabadello_> markus_sabadello_ has joined #did
08:04:12 <burn> Topic: Agenda Review, Introductions, Re-introductions
08:04:50 <markus_sabadello_> burn: Today we will give notification of the winning specification short name, then we will talk about FPWD of main spec
08:05:03 <markus_sabadello_> burn: We might also talk about the Use Cases doc
08:05:11 <markus_sabadello_> burn: Then main topic will be key representation
08:05:22 <markus_sabadello_> burn: (We won't make any decisions about this)
08:05:32 <markus_sabadello_> burn: If there's more time, we can go over PRs
08:05:35 <selfissued> FYI, I read the entire Use Cases doc and filed some issues at https://github.com/w3c/did-use-cases/issues/
08:05:41 <selfissued> q+
08:05:48 <markus_sabadello_> burn: Any change suggestions for agenda?
08:05:53 <burn> ack selfissued
08:06:16 <markus_sabadello_> selfissued: I read the whole Use Cases doc and raised a number of issues; we could assign owners if there is time
08:06:37 <markus_sabadello_> burn: Let's see, we want to keep enough time for the main topic
08:06:45 <markus_sabadello_> burn: Other suggestions for agenda?
08:07:03 <ivan> Subtopic: Introduction
08:07:05 <markus_sabadello_> burn: Yue, would you like to introduce yourself?
08:07:33 <markus_sabadello_> Yue: We're working on different identifiers and Internet of Things
08:07:44 <agropper> present+
08:07:46 <markus_sabadello_> Yue: It's my first time in a W3C WG, thank you
08:08:07 <markus_sabadello_> burn: Anyone else joining for the first time? I think not
08:08:18 <ivan> Subtopic: Reintroduction
08:08:29 <markus_sabadello> burn: Manu, want to reintroduce yourself?
08:08:57 <markus_sabadello> manu: I'm CEO of Digital Bazaar, we're working on standardization of payment processes and identity technologies. I'm co-editor of DID, VC, and other specs.
08:09:00 <burn> Topic: Specification shortname
08:09:12 <burn> https://github.com/w3c/did-spec/issues/76
08:09:29 <markus_sabadello> burn: Regarding DID spec short name, the winner is "did-core"
08:09:52 <ivan> actually, the issue is now https://github.com/w3c/did-core/issues/76 :-)
08:10:07 <Yue> p+ yue jing
08:10:11 <markus_sabadello> burn: This short name will appear in the URL to the permanent published document (the primary specification)
08:11:07 <markus_sabadello> burn: We should use the name everywhere now (web, Github, etc)
08:11:24 <markus_sabadello> ivan: On Github there's also a redirect from the old name to the new
08:11:33 <markus_sabadello> burn: Any other comments?
08:11:36 <burn> Topic: FPWD
08:11:49 <burn> https://github.com/w3c/did-spec/issues/68
08:12:43 <markus_sabadello> burn: In this issue, we're discussing publishing an official "working draft" .. We currently have an "editor's draft"
08:12:59 <markus_sabadello> burn: Working draft does not imply group consensus.
08:13:16 <markus_sabadello> burn: Publishing the first working draft (FPWG) is important since it starts some IPR processes
08:13:47 <markus_sabadello> burn: To do this, we won't have an official "vote", but try to get consensus from the group
08:14:12 <markus_sabadello> burn: The editors put together a document that would become the FPWD (asides from minor editorial fixes)
08:14:17 <ivan> -> https://github.com/w3c/did-core/issues/76 for the FPWD text
08:14:31 <markus_sabadello> burn: We received one comment with concerns about the document, by selfissued (Mike Jones), do you want to speak about it?
08:14:41 <manu> Current FPWD proposal -- https://pr-preview.s3.amazonaws.com/w3c/did-spec/pull/87.html
08:15:02 <markus_sabadello> selfissued: I raised a concern because since our last call I read the charter. The charter says we will create a Use Cases document with req's for the technical specification.
08:15:23 <markus_sabadello> selfissued: It's important to have the Use Cases first that explain why we're doing what we doing
08:15:53 <markus_sabadello> selfissued: At TPAC I heard a reference about the Use Cases document, but no time has been spent on the WG to go over UC issues.
08:16:10 <markus_sabadello> selfissued: UC document should not be an afterthought. It should inform the technical specification.
08:16:25 <markus_sabadello> selfissued: Otherwise we may be condoning neglect of use cases.
08:16:47 <manu> q+ to note that I wouldn't read too much into WG focus to date - use cases have been worked on over the past few years... pretty mature already... we should publish.
08:16:49 <markus_sabadello> burn: "Neglect" may be too strong, but you are right that UC are important and that we haven't spent time on it yet.
08:17:10 <markus_sabadello> burn: It's reasonable to expect that we spend more time on UC upfront before focusing only on the main spec
08:17:20 <markus_sabadello> burn: The group does need to begin to work on it.
08:17:43 <markus_sabadello> burn: Topic today is, can we agree to publish FPWD of the core spec.
08:17:47 <burn> q?
08:17:54 <markus_sabadello> burn: We should consider FPWD of UC doc as well.
08:18:04 <burn> ack manu
08:18:04 <Zakim> manu, you wanted to note that I wouldn't read too much into WG focus to date - use cases have been worked on over the past few years... pretty mature already... we should publish.
08:18:06 <markus_sabadello> selfissued: See issue #8 in UC repository
08:18:21 <selfissued> https://github.com/w3c/did-use-cases/issues/8
08:18:33 <markus_sabadello> manu: I agree UC document is important. I think so far the WG had higher priority items to address.
08:18:49 <selfissued> q+
08:18:52 <markus_sabadello> manu: Some time has been spent on UC. The current version reflects that. It's one of the better UC documents out there compared to other groups.
08:19:09 <manu> https://pr-preview.s3.amazonaws.com/w3c/did-spec/pull/87.html#sotd
08:19:41 <markus_sabadello> manu: I don't think it should be a gating factor. It's easy to link from core spec to UC document, so readers are aware of it. This is fine for FPWD to point to documents that are in-process.
08:20:34 <markus_sabadello> manu: I think people won't get confused if FPWD of core spec points to in-progress UC document.
08:21:03 <ivan> q?
08:21:12 <markus_sabadello> manu: Let's not gate FPWD by this.
08:21:21 <burn> ack selfissued
08:21:40 <markus_sabadello> selfissued: I disagree with manu's assertion that UC document is relatively mature.
08:21:50 <manu> I said "mature for a FPWD"
08:21:55 <markus_sabadello> selfissued: I'm reading this with fresh eyes.
08:22:12 <ivan> q+
08:22:25 <burn> q?
08:22:28 <markus_sabadello> selfissued: There is a lot of tribal knowledge that is assumed. New readers of the UC document may be confused by not knowing certain things.
08:22:48 <markus_sabadello> selfissued: Therefore I raised several issues about things that are not clear to new readers.
08:22:55 <burn> q+
08:23:07 <burn> ack ivan
08:23:11 <markus_sabadello> selfissued: Can we get an agreement to get to FPWD also for the UC document.
08:23:51 <burn> s/an agreement/a gentleman's agreement/
08:24:00 <markus_sabadello> ivan: I'm also a new reader without the tribal knowledge. I still think we should publish FPWD of the core spec, but FPWD of UC should also be prepared soon (e.g. by end of November)
08:24:18 <burn> ack burn
08:25:14 <brent> +1 to publishing use cases during November
08:25:15 <markus_sabadello> burn: What I'm hearing is selfissued would be okay with publishing FPWD of core spec, if the group has a gentleman's agreement to publish FPWD within November and work toward that.
08:25:23 <markus_sabadello> selfissued: Agreed
08:25:38 <kdenhartog> kdenhartog has joined #did
08:26:20 <markus_sabadello> burn: Does anyone object to the intent of the group being publishing FPWD of UC document within November, and working toward that goal (working on Github issues, allocating time on WG calls for this)?
08:26:26 <Dudley> +1 and also happy to participate in use case review
08:27:02 <ivan> q+
08:27:28 <burn> ack ivan
08:27:30 <burn> q+
08:27:35 <markus_sabadello> manu: I'm trying to formulate a single proposal that addresses both FPWD of core spec and selfissued 's requests about UC document.
08:28:06 <markus_sabadello> ivan: I would prefer three separate, crisp proposals, rather than having everything in a single proposal/resolution.
08:28:52 <burn> ack burn
08:28:54 <markus_sabadello> ivan: We can have them now and vote for them, that's easier from an admin perspective
08:29:20 <ivan> +1
08:29:44 <markus_sabadello> burn: We already agreed to work on UC document, and we already on Echidna.
08:30:10 <markus_sabadello> burn: So we should only have to vote on publishing the DID core spec as FPWD
08:30:22 <manu> PROPOSAL: Publish the DID Core specification as a FPWD with a short name of did-core within the month of November.
08:30:26 <ivan> +1
08:30:26 <David_Trang> +1
08:30:35 <TallTed> +1
08:30:38 <brent> +1
08:30:41 <manu> +1
08:30:41 <agropper> +1
08:30:42 <Dudley> +1
08:30:43 <burn> +1
08:30:45 <kdenhartog> +1
08:30:49 <Yue> +1
08:30:49 <markus_sabadello> burn: Any suggestions to modify the proposal? Not hearing any. Please respond.
08:30:50 <markus_sabadello> +1
08:30:59 <selfissued> +1 to trigger the IPR process
08:31:17 <ivan> q+
08:31:20 <markus_sabadello> burn: Seeing no objections. This is resolved.
08:31:31 <burn> RESOLVED: Publish the DID Core specification as a FPWD with a short name of did-core within the month of November.
08:31:56 <markus_sabadello> burn: Is there anyone who believes that we must do one of the other two proposals today?
08:32:44 <markus_sabadello> manu: We'll merge and create a static copy for FPWD
08:33:02 <markus_sabadello> ivan: Formally speaking, we have to wait 1 week before a resolution is accepted.
08:33:17 <markus_sabadello> ivan: I'm aiming for doing this by Thursday 7th of November.
08:33:45 <markus_sabadello> burn: If there are objections, we encourage people to raise them within 48 hours.
08:33:57 <markus_sabadello> ivan: As soon as I have the static version, I will start the admin process.
08:34:07 <markus_sabadello> manu: Will try to create the static copy today.
08:34:10 <burn> Topic: Key representation
08:34:12 <burn> https://github.com/w3c/did-spec/issues/67
08:34:36 <markus_sabadello> burn: This is the primary issue; other issues are related to it.
08:35:08 <manu> https://github.com/w3c/did-core/issues/67#issuecomment-542480584
08:35:11 <markus_sabadello> manu: We've had the discussion about key representation before and coming back to it with new information.
08:35:21 <markus_sabadello> manu: I made an attempt to summarize what this is about.
08:35:42 <markus_sabadello> manu: We have some use cases and requirements that hadn't really been summarized before, so this is what my comment is trying to do.
08:35:45 <burn> zakim, who is on the phone?
08:35:45 <Zakim> Present: burn, ivan, Yue, brent, David_Trang, dudley, selfissued, manu, TallTed, markus_sabadello, agropper
08:36:02 <markus_sabadello> manu: We're trying to represent cryptographic information (together with other information) in DID documents, so it can be consumed by applications.
08:36:38 <burn> q+ selfissued
08:36:43 <ivan> q-
08:36:54 <markus_sabadello> manu: Three categories of applications: 1. Outside our scope (not our business to define key formats, but we still want to encourage interop)
08:37:04 <markus_sabadello> manu: 2. Keys used by the DID registry (internally e.g. to control the DID document). This also includes things other than keys
08:37:36 <markus_sabadello> manu: 3. Applications that are somehow in the middle. E.g. authentication. These same mechanisms may be used by the DID registry and also outside.
08:38:17 <markus_sabadello> manu: I think there's a lot of the back and forth with different objectives.
08:38:25 <markus_sabadello> manu:  One argument: Everybody standardizes on one key format, this simplifies implementations.
08:38:56 <markus_sabadello> manu: Other argument: It would be nice to have one represenation, but the reality is that we don't. There are existing implementations that have considered this but decided not to pick a single format.
08:39:27 <markus_sabadello> manu: So today we have multiple different representations of keys and we have to acknowledge that, and transformations between formats are happening
08:39:35 <selfissued> q+
08:39:52 <burn> ack selfissued
08:39:52 <kdenhartog> q+
08:40:51 <markus_sabadello> selfissued: A friend in the industry said.. Making choices that don't matter. To get interoperability you have to make a choice. It doesn't matter so much what you choose, but it's important that you do choose.
08:41:27 <burn> ack kdenhartog
08:41:39 <markus_sabadello> selfissued: I look at what's been happening so far, and I think nobody makes any choices. Everything seems loose, the union of what everyone wants, but in the end this doesn't serve anyone
08:41:45 <ivan> present+ kdenhartog
08:41:53 <markus_sabadello> kdenhartog: Question for markus_sabadello about your comment in the Github issue.
08:42:00 <manu> q+ to note this is not an "either or" or a "yes and" discussion... get more specific wrt. why it would complicate things if we forced JWK on everyone.
08:42:02 <markus_sabadello> q+
08:42:08 <burn> ack markus_sabadello
08:42:15 <burn> scribe+ manu
08:42:26 <markus_sabadello> https://github.com/w3c/did-core/issues/67#issuecomment-547300231
08:43:22 <selfissued> q+
08:43:37 <manu> markus_sabadello: The question you're asking about the comment in IRC... I was trying to argue... size of different key representations, issue for certain did methods, registries, size of representation too large... whatever representation or format we use, is not necessarily what is stored in the registry. The way a lot of DID Methods work, they don't store DID Document internally... it is a result of resolution process.
08:44:12 <manu> markus_sabadello: Bitcoin, Ethereum, they don't actually store DID Document on the ledger, whatever we agree on, doesn't mean, doesn't impact how DID Documents get implemented internally. DID Document may or may not use DID Document internally.
08:44:14 <burn> ack manu
08:44:14 <Zakim> manu, you wanted to note this is not an "either or" or a "yes and" discussion... get more specific wrt. why it would complicate things if we forced JWK on everyone.
08:44:54 <markus_sabadello> manu: I wanted to focus on real-world repercussions of this discussion. I agree with selfissued that DID spec writers are not forcing one way of doing it
08:45:13 <markus_sabadello> manu: There was a heated discussion on forcing one key format vs. allowing multiple formats
08:45:13 <burn> q+ to note that standards is actually about writing down agreement that you have
08:45:19 <kdenhartog> Thanks Markus, that makes me feel like my point is more a moot point and is resolved from the registry perspective. At the application layer this has larger implications.
08:45:53 <markus_sabadello> manu: Both choices could result in more complexity for implementors
08:46:39 <markus_sabadello> manu: Many implementations don't use JWK today and have chosen not to use it. They use e.g. binary encodings of keys. I think that's terrible, but that's how it is.
08:47:07 <markus_sabadello> manu: E.g. openssl is not going to support JWK, therefore if DID document requires JWK, transformations have to be implemented.
08:47:32 <markus_sabadello> manu: Example of Ed25519: Most people just use raw binary encoding
08:47:46 <burn> q+ to ask whether we want to schedule adhoc call focused just on this topic
08:47:50 <markus_sabadello> manu: In Bitcoin and Ethereum communities, people use different formats even though the key types are the same
08:48:11 <markus_sabadello> manu: This is how the ecosystem has developed. Attempts for people to agree on a single format have failed
08:48:33 <burn> ack selfissued
08:48:35 <markus_sabadello> manu: Let's support JWK and keep trying to get people to use the same format. But also recognize that this will increase, not decrease, implementation burden
08:49:03 <markus_sabadello> selfissued: Clarification question: We're only taking about PUBLIC key representations, right?
08:49:21 <markus_sabadello> manu: Yes
08:49:56 <markus_sabadello> selfissued: About your complexity argument: If you force a single format, translation has only ever to happen once (between other format, and the single support format)
08:50:20 <markus_sabadello> selfissued: In the current ecosystem however, transformation is more complex since every format has to be transformed to every other. This gets worse with additional formats
08:50:32 <markus_sabadello> selfissued: Therefore, making one choice, the overall translation problem gets easier
08:51:03 <markus_sabadello> selfissued: We could say that for known key types (RSA, EC) we could choose JWK and one or two other common formats, but also state that we will accept no other
08:51:05 <manu> q+ to agree about "no growing X"...
08:51:13 <burn> ack burn
08:51:13 <Zakim> burn, you wanted to note that standards is actually about writing down agreement that you have and to ask whether we want to schedule adhoc call focused just on this topic
08:51:15 <markus_sabadello> selfissued: I don't like that, but it's better than being completely open-ended
08:51:31 <manu> q+ to agree about "no growing N"... we have too many.
08:51:36 <manu> q+ to agree about "no growing N"... we have too many as it is.
08:51:39 <manu> q-
08:51:40 <manu> q+ to agree about "no growing N"... we have too many as it is.
08:51:45 <selfissued> q+
08:51:47 <markus_sabadello> burn: I think standards is about writing down where you can get agreement. Let other things wait
08:51:56 <kdenhartog> q+
08:52:01 <burn> ack manu
08:52:01 <Zakim> manu, you wanted to agree about "no growing N"... we have too many as it is.
08:52:04 <markus_sabadello> burn: Even if you have to leave some things open (they may become clearer over time)
08:52:41 <markus_sabadello> manu: Agree with selfissued , trying to push JWK isn't going to result in end state selfissued wants. I also want everyone to use the same key format. But in reality I don't think we will be able to change that.
08:52:54 <burn> q+ to ask whether we want to schedule adhoc call focused just on this topic
08:53:17 <markus_sabadello> manu: Agree with selfissued to do the next-best things: E.g. accept 2 most popular formats but then don't allow others. Aggressively narrow the list, stop proliferation
08:53:18 <burn> ack selfissued
08:53:38 <burn> ack kdenhartog
08:54:09 <markus_sabadello> kdenhartog: I was confused by selfissued 's comments about RSA and EC key types. But I thought we're talking about different serialization formats, not key types.
08:54:13 <selfissued> q+
08:54:17 <markus_sabadello> kdenhartog: +1 to manu (which was +1 to selfissued)
08:54:29 <burn> ack burn
08:54:29 <Zakim> burn, you wanted to ask whether we want to schedule adhoc call focused just on this topic
08:54:38 <markus_sabadello> kdenhartog: I think we should restrict formats, not key types (e.g. quantum crypto will become important)
08:54:51 <burn> ack selfissued
08:55:01 <markus_sabadello> burn: Perhaps we schedule an additional dedicated call for this topic
08:55:20 <kdenhartog> +1 to that
08:55:25 <markus_sabadello> selfissued: My point was that for a given key type (e.g. RSA) we should choose 1 (or maybe 2) supported representations for this key type.
08:55:28 <burn> q?
08:55:45 <manu> q+ to note another wrinkle... which is assuming that the encoding is JSON.
08:55:51 <burn> ack manu
08:55:51 <Zakim> manu, you wanted to note another wrinkle... which is assuming that the encoding is JSON.
08:56:11 <selfissued> q+
08:56:32 <markus_sabadello> manu: Agreeing more and more with selfissued . Another wrinkle is something markus_sabadello highlighted on the last call: Don't assume that DID documents will always be encoded as JSON.
08:56:32 <burn> zakim, close the queue
08:56:32 <Zakim> ok, burn, the speaker queue is closed
08:57:02 <markus_sabadello> manu: Like in the VC spec, we separate the abstract data model from the concrete format. E.g. you could represent a DID document in a binary format like CBOR.
08:57:17 <selfissued> q+
08:57:19 <markus_sabadello> manu: Therefore we should keep this in mind when talking about public key formats.
08:57:30 <burn> ack selfissued
08:57:31 <markus_sabadello> manu: I think JWK can also be represented in CBOR, but let's keep this in mind
08:57:33 <burn> q?
08:58:04 <markus_sabadello> selfissued: This is a fine point. I find multibase particularly offensive, since that format itself refuses to make a choice;
08:58:57 <markus_sabadello> burn: We don't have enough time to resolve this, but I feel we're getting to something. It may be best to have a dedicated call with those who are interested.
08:59:00 <manu> You can do multibase, but force ONE encoding... you do that because you can't predict 10 years in the future... who thought that base58 would be a thing... but it is
08:59:05 <markus_sabadello> kdenhartog: I'd be interested to join this
08:59:55 <markus_sabadello> manu: We need more than selfissued and kdenhartog and the editors to resolve this. We have to make sure we get consensus of the whole WG.
09:00:14 <markus_sabadello> ivan: Can you write a one or two summary for the minutes of where you think we are.
09:00:16 <markus_sabadello> manu: Will do
09:00:20 <markus_sabadello> burn: Thanks all, bye
09:00:32 <manu> Summary of where we are right now...
09:00:47 <markus_sabadello> s/one or two summary/one or two sentence summary/
09:01:02 <Yue> Yue has left #did
09:01:25 <manu> It sounds like we're closing in on a path forward, which is to allow multiple types, but limit to perhaps 2 mechanisms for each key type... for example, for RSA, PEM encoding and JWK encoding...
09:01:51 <manu> While this doesn't get us down to one key format, it does limit an explosion of key formats.
09:02:29 <manu> We will need to have further calls to ensure that we're taking all use cases and requirements into account, and those calls will be scheduled by the Chairs and Staff.
09:02:41 <manu> We need to make sure that we have more than a handful of people providing input
09:03:18 <ivan> rrsagent, draft minutes
09:03:18 <RRSAgent> I have made the request to generate https://www.w3.org/2019/10/29-did-minutes.html ivan
09:03:19 <ivan> zakim, bye
09:03:19 <ivan> rrsagent, bye
09:03:19 <RRSAgent> I see no action items