14:49:55 <RRSAgent> RRSAgent has joined #did
14:49:55 <RRSAgent> logging to https://www.w3.org/2020/04/14-did-irc
14:49:57 <Zakim> RRSAgent, make logs Public
14:49:58 <Zakim> please title this meeting ("meeting: ..."), ivan
14:50:07 <ivan> Meeting: DID Working Group Telco
14:50:07 <ivan> Chair: burn
14:50:07 <ivan> Date: 2020-04-14
14:50:07 <ivan> Agenda: https://lists.w3.org/Archives/Public/public-did-wg/2020Apr/0005.html
14:50:07 <ivan> ivan has changed the topic to: Meeting Agenda 2020-04-14: https://lists.w3.org/Archives/Public/public-did-wg/2020Apr/0005.html
14:52:28 <burn> present+
14:52:36 <burn> regrets+ Markus_Sabadello
15:00:28 <Rusu_Eugeniu_Jolocom> Rusu_Eugeniu_Jolocom has joined #did
15:00:55 <brent> brent has joined #did
15:01:23 <ivan> present+
15:01:33 <brent> present+
15:01:45 <dlongley> present+
15:01:46 <justin_r> justin_r has joined #did
15:01:52 <Eugeniu_Jolocom> Eugeniu_Jolocom has joined #did
15:02:06 <justin_r> present+
15:02:23 <drummond> drummond has joined #did
15:02:31 <drummond> present+
15:02:31 <manu> present+
15:02:52 <brent> scribe+
15:02:57 <Eugeniu_Jolocom> present+
15:03:09 <burn> Topic: Agenda Review, Introductions, Re-introductions
15:03:14 <timcappalli> timcappalli has joined #did
15:03:20 <brent> Topic: Agenda review and introductions
15:03:51 <joel> joel has joined #did
15:03:53 <brent> burn: we'll get started with a straw poll, plus some other business, then spend most of our time on issues.
15:03:55 <rhiaro> present+
15:04:03 <brent> ... any requested changes?
15:04:06 <ivan> present+ rhiaro, dbuc, orie, timcappalli
15:04:13 <brent> burn: anyone here for the first time?
15:04:15 <Orie> Orie has joined #did
15:04:18 <Orie> present+
15:04:19 <dbuc> dbuc has joined #did
15:04:22 <dbuc> present+
15:04:26 <ivan> present+ drummond
15:04:30 <joel> present+
15:04:40 <brent> ... is there someone who hasn't introduced themselves in a long time and would like to do so?
15:04:58 <brent> drummond: Drummond Reed from Evernym, trustee of the Sovrin Foundation.
15:05:23 <burn> Topic: Next Topic Call
15:05:25 <brent> ... worked on the DID spec from the beginning and really want it to be a standard, I'm one of the editors on the spec
15:05:36 <ivan> present+ yancy
15:06:01 <brent> burn: trying to alternate, but this week will also be Thursday at 12pm ET
15:06:05 <ivan> present+ identitywoman
15:06:18 <brent> ... the topic is the resolution contract, which isblocking a number of other issues.
15:06:29 <brent> ... there are a lot of issues to consider in it.
15:06:33 <ivan> s/isblocking/is blocking/
15:06:38 <brent> ... brent already sent out a reminder
15:07:21 <selfissued> selfissued has joined #did
15:07:21 <ivan> present+ selfissued
15:07:24 <selfissued> present+
15:07:29 <burn> For topic calls, will use #did-topic
15:07:33 <brent> ... for our special topic calls, we will be using a different irc chat room
15:07:49 <brent> ... the #did-topic room
15:08:12 <brent> ... this is so we can cleanly separate the notes for different calls which fall on the same day.
15:08:21 <chriswinc> present+
15:08:33 <burn> q?
15:08:37 <brent> ... this also lets us have aconsistent Topic for each call
15:08:41 <brent> ... in the chat
15:08:47 <burn> Topic: DID Method Registry
15:08:57 <burn> https://github.com/w3c-ccg/did-method-registry/issues/82
15:09:20 <identitywoman> identitywoman has joined #did
15:09:24 <brent> burn: I'm going to ask Manu to give us a summary of this issue.
15:09:43 <brent> ... the chairs are after a straw poll to get some indication of what the group is okay with
15:10:05 <brent> ... we are timeboxing this for 10 minutes and will stop at that time. No discussion today.
15:10:17 <brent> ... Are you willing to to that Manu?
15:10:42 <brent> manu: issue 82 is about moving the DID Method registry into the did-core registries document
15:10:56 <brent> ... we are trying to consolidate where an implementor will have to look for things.
15:11:11 <dmitriz> dmitriz has joined #did
15:11:13 <brent> ... currently we have all extension methods in that repo except the did method registry
15:11:13 <Orie> q+ to note the need to merge updates frequently and review new method conformance.
15:11:25 <dmitriz> present+
15:11:36 <brent> ... the simplest way to look at this is to decide if this is something we want to do.
15:11:44 <brent> ... then we need to decide details.
15:11:58 <brent> ... is that alright with the chairs?
15:12:02 <burn> ack Orie
15:12:02 <Zakim> Orie, you wanted to note the need to merge updates frequently and review new method conformance.
15:12:05 <brent> burn: yes
15:13:08 <Orie> +1
15:13:25 <manu> PROPOSAL: Integrate the DID Method Registry into the DID Core Registries document.
15:13:30 <brent> manu: any objections to putting that proposal?
15:13:31 <rhiaro> +1
15:13:32 <drummond> +1
15:13:33 <Eugeniu_Jolocom> +1
15:13:33 <Orie> +1
15:13:33 <dlongley> +1
15:13:34 <ivan> +1
15:13:35 <manu> +1
15:13:36 <justin_r> +1
15:13:36 <yancy> +1
15:13:37 <dbuc> +1
15:13:44 <burn> +0
15:13:46 <gannan> gannan has joined #did
15:13:48 <brent> 0
15:13:50 <drummond> q+
15:14:29 <burn> ack drummond
15:14:54 <brent> drummond: we still in the spec are going to have a separate discussion about normative statements about specs, which could adjudicate about several did methods that are in there. Maybe DID methods will need to re-qualify
15:14:59 <manu> RESOLVED: Integrate the DID Method Registry into the DID Core Registries document.
15:15:09 <brent> burn: that's getting into details. Let's resolve it
15:15:30 <brent> ... we had fewer people responding than normal. we have double that number on the call
15:15:43 <dmitriz> +1
15:15:48 <selfissued> +1
15:15:49 <brent> ... we just resolved to bring the did method registry into the did-core registry document.
15:15:55 <gannan> +1
15:16:01 <brent> ... that's fair, it holds.
15:16:08 <manu> q+ to outline the potential complexities of integrating DID Method registry in.
15:16:25 <brent> ... this will go next to the CCG, but now we know what the working group would like to do
15:16:35 <brent> ... anything else critical here to spend time on?
15:16:47 <brent> manu: just outline some things we'll need to do.
15:16:53 <Orie> q+
15:16:59 <burn> ack manu
15:16:59 <Zakim> manu, you wanted to outline the potential complexities of integrating DID Method registry in.
15:17:12 <brent> burn: let's do that, the Orie can re-queue himself.
15:17:39 <brent> manu: what the chairs and staff need to contemplate is if there might be IPR issues moving the did method registry into the did-core registires document
15:18:01 <selfissued> q+
15:18:03 <brent> ... usually when we move things from the CCG, we get everyone who contributed to sign an FSA
15:18:19 <brent> ... this one has more than 50 people who contributed, which is alot.
15:18:37 <brent> ... bit there is also an argument that says, there's no IPR, the contributioins are just links
15:18:55 <brent> ... but if there is a concern, the FSA sign-off could delay things fr quite awhile.
15:19:12 <brent> ... and if they don't sign off, they may be removed from the did-method registry.
15:19:15 <burn> q?
15:19:32 <drummond> +1 to dropping DID methods who do not sign FSA
15:19:36 <brent> ... that is a wierd outcome that I am not expecting to happen, but that is the most complex thing that could happen.
15:20:01 <burn> ack Orie
15:20:03 <brent> ... next the Chairs, staff , and editors will decide on the plan and we will begin execuiting it
15:20:49 <brent> Orie: the did method regirty takes a lot of PRs from a lot of people. If the docuemnt is not conformant, the person must make the necessary statements to make it conformant.
15:21:11 <burn> ack selfissued
15:21:12 <brent> ... if this is in did-core regirties, we will get a lot of PRs that will need to be addressed.
15:21:15 <manu> yaay, yes please, we need more volunteers to help w/ DID Method review.
15:21:44 <rhiaro> orie, manu, I can also help with that I think
15:21:45 <brent> selfissued: to the IPR question: certainly, taking notes from IETF, there is never an IPR question for references to things.
15:21:51 <burn> q+
15:21:55 <drummond> +1 to no IPR check needed for registry entries
15:21:55 <manu> thx rhiaro !
15:22:17 <manu> (we'd need to go through the DID WG "special job" process, probably)
15:22:17 <burn> q-
15:22:28 <burn> +1 to likely no IPR check for registry entries
15:22:32 <manu> +1, my read is the same as Mike's
15:22:32 <burn> q?
15:22:34 <brent> ... to Orie's point about timely response, for each registry there is a set of designated experts who look at incoming requests, perhaps Orie and Drummond and others, who can do that without bringing it to the WG.
15:22:46 <burn> q?
15:23:02 <brent> burn: several of us who have been doing this for awhile have an idea how this is going to go.
15:23:20 <ivan> q+
15:23:25 <burn> ack ivan
15:23:35 <brent> ... Amy asked aquestion about whethert this will be a living document. That is essentially what registries are, and the details are still being worked out.
15:23:44 <brent> ivan: it is not a big deal to update a note.
15:23:53 <burn> Topic: Core issue status check
15:24:04 <burn> https://github.com/w3c/did-core/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-asc
15:24:29 <burn> https://github.com/w3c/did-core/issues/105
15:24:33 <manu> q+ to get reviews, even though spec is not ready.
15:24:37 <brent> burn: I believe for these first two the answer will be quick
15:25:22 <brent> ivan: I don't think there's anything we can do before the doc is ready. What we started in Amsterdam should be properly folded in. For the time being let's postpone these until the structure of the docuemtn is ready.
15:25:33 <brent> burn: can you make a comment to that effect in the issues?
15:25:42 <brent> ivan: how could I refuse?
15:25:43 <burn> q?
15:25:45 <burn> ack manu
15:25:45 <Zakim> manu, you wanted to get reviews, even though spec is not ready.
15:26:08 <ivan> q+
15:26:29 <brent> manu: pushing back a bit. I'm concerned we're past the point when the docuemnt should be "done" enough for that review. I'm wondering if it would be best to just send it out for review.
15:26:40 <brent> ... it may have enough in there for people to do a first pass.
15:27:01 <burn> q+
15:27:02 <brent> ... usually for horizontal review they prefer early enough that changes can be made.
15:27:17 <brent> ... I'm concerned it will be pushed back two months an then it will be too late.
15:27:37 <burn> ack ivan
15:27:42 <brent> ... I don't expect a lot to vcome out of the accessibility and internationalization reviews, but the TAG could be tricky.
15:28:20 <manu> q+ on next steps
15:28:21 <burn> ack burn
15:28:37 <brent> ivan: let me be a little more precise. Currently the document starts with a note saying the spec is undergoing a significant structural revision. So as soon as the doc is to the point we can remove thatm,  we will send it off.
15:29:00 <brent> burn: I ahte late reviews, but I agree with ivan here. We're still missing section 6.
15:29:15 <ivan> s/ahte/hate/
15:29:16 <justin_r> s/ahte/hate/
15:29:18 <burn> ack manu
15:29:18 <Zakim> manu, you wanted to comment on next steps
15:29:22 <justin_r> q
15:29:29 <brent> ... There's a lot we don't need to wait for, but there are pices we need in order for the doc to be readable.
15:29:42 <drummond> q+
15:29:57 <brent> manu: The editors can make a big push to get 3 and 6 done sooner than later, we'll make that a priority.
15:30:02 <ivan> +1 to manu
15:30:03 <burn> ack drummond
15:30:08 <burn> +1 to manu
15:30:50 <brent> drummond: sectioin 6 is being revised now after comments from manu. I was waiting on 3 for 6 to be done, but that should be this week.
15:31:08 <burn> https://github.com/w3c/did-core/issues/75
15:31:08 <brent> burn: the chairs are not being unreasonable and we are all in agreement on next steps.
15:31:48 <brent> burn: looks like conversation is still happening
15:32:01 <Orie> I tried a PR for this and failed...
15:32:39 <brent> dbuc: there is some discrepancy whether 75 and 14 are related. seems to be most people  don't want a way to formally mark revoked keys, but some do. not sure how to move this forward.
15:32:43 <manu> https://github.com/w3c/did-core/pull/224
15:33:25 <brent> manu: there was an attempt in PR 224 that did not gain consensus. The conversation was supposed to jump back to the issue, but it didn't. If someone could propose some language.
15:33:44 <Orie> the spec is super weak... and there is no consenus.
15:33:47 <manu> q+
15:33:52 <burn> ack manu
15:33:54 <brent> dbuc: I think is comes down to: some people want this formal in the spec and some people don't. H?ard to write spec language around a binary thing.
15:34:17 <burn> q+
15:34:47 <brent> manu: the third way is to let the spec stay vague, it allows it and doesn't forbid it. This can help us move forward when the positions are so polar. that wat people who want to can, but people who don't, don't have to.
15:34:50 <burn> ack burn
15:35:34 <brent> burn: that may work, if it does, great. The standard one in this case is when there are disagreements, the people involved need to get on a call and talk with the goal of moving the spec forward.
15:36:15 <brent> ... if the people who disagree aren't able to work it out we can have a more moderated call. I hope those individuals will reach out to each other.
15:36:19 <manu> I added this comment: https://github.com/w3c/did-core/issues/14#issuecomment-613514751
15:36:20 <jfishback> jfishback has left #did
15:36:23 <burn> q?
15:36:37 <brent> ... sounds like there's a proposal from manu on possible next steps, let's see if that goes anywhere.
15:36:57 <burn> q?
15:36:59 <brent> burn: next one, smae issue, same status
15:37:01 <dbuc> LOL, Orie already downvoted what we just said in GH
15:37:15 <dbuc> Orrieally?
15:37:29 <burn> https://github.com/w3c/did-core/issues/194
15:37:33 <brent> burn: if you wan't to downvote, please recommend an alternative proposal
15:37:48 <brent> manu: I don't know what to do with this one.
15:38:04 <brent> there is a massive conversation that is hard to boil down to something actionable.
15:38:13 <brent> ... I'd like to close this, but I can'
15:38:26 <brent> t figure out what concrete text needs to be changed.
15:38:43 <burn> https://github.com/w3c/did-core/issues/5
15:38:47 <brent> burn: sometimes you need to get specific.
15:39:04 <brent> burn: a theoretically simple question.
15:39:24 <brent> ... the versioning issue may be keeping this alive.
15:39:30 <Orie> some will live in did-core-registries, others will live on the internet....
15:39:36 <manu> q+ to note there's been progress.
15:39:44 <Orie> NONE will live in did-core.
15:39:45 <burn> ack manu
15:39:45 <Zakim> manu, you wanted to note there's been progress.
15:39:47 <brent> ... it is assigned to chairs and staff, it was assumed we just needed to do it, but that's not the case
15:39:54 <brent> manu: there has been progress.
15:40:07 <brent> ... did-core contexts live here now.
15:40:19 <brent> ... third-party did extension contexts is what remains
15:40:32 <brent> ... then there's the versioning strategy.
15:40:48 <brent> ... that's what is holding this up, we need a concrete proposal.
15:41:04 <brent> burn: is there something other than you that can propose a versioning strategy?
15:41:09 <drummond> Can we be specific about what the "versioning strategy" entails?
15:41:13 <burn> s/something/someone/
15:41:25 <brent> manu: anyone else who is comfortable managing contexts on a 10 year timeline?
15:41:51 <brent> dmitriz: I have a concrete proposal that I linked to in the issue. I'd like to hear counter arguments against.
15:42:02 <Orie> lets take it to the did core registries issue dmitriz...I can help
15:42:32 <brent> ... it would solve a lot of our problems, both while we are rapidly moving during the spec writing, and give stability after we are done.
15:42:50 <burn> q?
15:42:52 <brent> ... where should I put the text?
15:42:57 <Orie> IMO, this issue is where this discussion should be had: https://github.com/w3c/did-core-registries/issues/17
15:43:03 <rhiaro> wouldn't this go in the ... yeah what orie just said ^
15:43:13 <brent> dmitriz: what directory and what file should I make the proposal against?
15:43:45 <brent> manu: did core registries is where we should put this, but maybe something in an issue first
15:44:08 <Orie> See the issue in did core registries
15:44:09 <brent> burn: if he's got text somewhere that may solve this, it should be here somewhere.
15:44:22 <burn> s/be here/be copied here/
15:44:38 <brent> manu: it would be nice to discuss this in the issue in did-core-registries and then go to PR if there isn't violent disagreement.
15:44:51 <burn> https://github.com/w3c/did-core/issues/119
15:45:03 <brent> burn: TAG review, we know the status of this one. still the same.
15:45:12 <burn> https://github.com/w3c/did-core/issues/195
15:45:12 <manu> Added some ideas on what we need to do here dmitriz  -- https://github.com/w3c/did-core/issues/5#issuecomment-613519860
15:45:44 <brent> burn: says blocked by did-core registries. Tobias is not on.
15:45:53 <brent> ... Orie?
15:46:19 <brent> burn: is it still blocked?
15:47:03 <brent> Orie: yeah. We've made progress on this. a lot of these properties have been added to the did-core registry. But I think this may be did method specific. I will add that to the issue.
15:47:04 <burn> https://github.com/w3c/did-core/issues/10
15:47:27 <brent> burn: Mike, can you give us a status on this one?
15:47:57 <brent> selfissued: this is one of the JSON-LD signature identifiers. Have we removed the dependency on the community group's registry for algorithm identifiers?
15:48:02 <manu> q+ to respond
15:48:04 <burn> ack manu
15:48:04 <Zakim> manu, you wanted to respond
15:48:25 <Orie> q+
15:48:32 <brent> manu: I believe that everything we need has been moved into, or is in the process of being moved into the did-core-registries context.
15:49:26 <brent> ... so there's no external dependencies. there is a deeper question aroeund whether the did core spec should say anything about digital signature protection of docuemtns beyond saying there is cryptographic proofing using public keys.
15:49:52 <brent> I think proof should be taken out and made part of the extensions rather than in the core spec. that would remove this issue.
15:50:11 <burn> ack Orie
15:50:15 <brent> selfissued: could you link to the part of the did core registryt where this is?
15:50:54 <brent> Orie: the proofing issue doesn't solve the issue fully, the way these suites define a key representation and signature representation together
15:51:21 <brent> ... I will add soe comments about this. This really affects interoperability, so I will add that to the issue.
15:51:32 <brent> selfissued: I agree with that analysis
15:51:44 <burn> https://github.com/w3c/did-core/issues/8
15:52:23 <brent> burn: I think this is you Mike, oh wait, it says the chairs will schedule a discussion.
15:53:01 <brent> selfissued: to the extent we supposrt JWK key representations, they can have algorithms which come from this registry. I will comment to that effect.
15:53:12 <brent> ... I think that's all we need to do for right now.
15:53:19 <burn> https://github.com/w3c/did-core/issues/92
15:53:36 <brent> burn: CBOR
15:53:46 <justin_r> q+
15:53:50 <brent> manu: we're waiting on Jonathan to give us the CBOR stuff.
15:54:13 <drummond> Should we assign the issue to Jonathan?
15:54:18 <brent> burn: right, this is the one that used to be IPLD. He has responded, and we're not far anought o say there is a deadline.
15:54:47 <burn> q?
15:54:50 <burn> ack justin_r
15:54:50 <brent> ... the only thing that would be good is to ad an update ping in the issue.
15:55:19 <brent> justin_r: I wanted to point out that since this issue has been raised and discussed there is a spot in the spec for it to go.
15:55:45 <burn> q?
15:55:47 <brent> ... along with enough structure to allow them to define how to get into and out of CBOR, whether that uses IPLD or another method.
15:55:48 <burn> https://github.com/w3c/did-core/issues/160
15:56:16 <brent> selfissued: I have to do the PR. I will try to do that soon.
15:56:42 <brent> burn: we are all doing the best we can right now.
15:56:47 <burn> https://github.com/w3c/did-core/issues/85
15:57:04 <justin_r> q+
15:57:05 <brent> burn: this is a metadata one. I don't think there's any new status
15:57:34 <brent> selfissued: that is correct. this depends on the whole metadata discussion. Is there anything else we should link to from this?
15:58:15 <burn> ack justin_r
15:58:16 <brent> burn: and Justin's point is good. If the actions that need to be tracked are elsewhere, we could point to them from this issue and close it.
15:58:26 <brent> selfissued: I'm not seeing this as a duplicate.
15:58:53 <brent> justin_r: The work we are doing on resolution contracts does begin to address this, but the PR hasn't been accepted yet.
15:59:30 <brent> ... the issue at its core is the difference in representing metadata and document data, which the PR addresses.
15:59:41 <brent> burn: It is good to link to the PR even before it is accepted.
16:00:01 <brent> ... we'll err on the side of linking to the PR when it is created.
16:00:30 <brent> justin_r: the link has been added. I request Mike takes a look at the PR.
16:00:47 <gannan> present+
16:00:47 <brent> burn: thanks everyone for joining a great rpoductive discussion.
16:01:02 <ivan> zakim, end meeting
16:01:02 <Zakim> As of this point the attendees have been burn, ivan, brent, dlongley, justin_r, drummond, manu, Eugeniu_Jolocom, rhiaro, dbuc, orie, timcappalli, joel, yancy, identitywoman,
16:01:06 <Zakim> ... selfissued, chriswinc, dmitriz, gannan
16:01:06 <Zakim> RRSAgent, please draft minutes
16:01:06 <RRSAgent> I have made the request to generate https://www.w3.org/2020/04/14-did-minutes.html Zakim
16:01:08 <Zakim> I am happy to have been of service, ivan; please remember to excuse RRSAgent.  Goodbye
16:01:12 <Zakim> Zakim has left #did
16:01:18 <gannan> gannan has joined #did
16:02:04 <ivan> rrsagent, bye
16:02:04 <RRSAgent> I see no action items