19:01:34 <RRSAgent> RRSAgent has joined #vcwg
19:01:39 <RRSAgent> logging to https://www.w3.org/2023/09/27-vcwg-irc
19:01:39 <Zakim> Zakim has joined #vcwg
19:01:51 <TallTed> present+
19:02:08 <kristina> kristina has joined #vcwg
19:02:11 <kristina> present+
19:02:37 <kristina> kristina has changed the topic to: VCWG Agenda 2023-09-27
19:02:51 <kristina> zakim, start meeting
19:02:51 <Zakim> RRSAgent, make logs Public
19:02:53 <Zakim> please title this meeting ("meeting: ..."), kristina
19:02:54 <kristina> Meeting: Verifiable Credentials Working Group Telco
19:03:03 <pdl_asu> pdl_asu has joined #vcwg
19:03:17 <kristina> Agenda: https://www.w3.org/events/meetings/36ecd2da-2ec3-4012-b74a-72546ab352f4/20230927T150000/
19:03:20 <TallTed> RRSAgent, draft minutes
19:03:21 <RRSAgent> I have made the request to generate https://www.w3.org/2023/09/27-vcwg-minutes.html TallTed
19:03:28 <pdl_asu> present+
19:03:28 <seabass> present+
19:03:30 <TallTed> RRSAgent, make logs public
19:03:32 <dlongley> present+
19:03:51 <TallTed> TallTed has changed the topic to: VCWG 2023-09-27 Agenda: https://www.w3.org/events/meetings/36ecd2da-2ec3-4012-b74a-72546ab352f4/20230927T150000/
19:04:20 <andres> scribe+
19:04:26 <bigbluehat> present+
19:04:48 <decentralgabe> decentralgabe has joined #vcwg
19:04:51 <decentralgabe> present+
19:04:58 <JoeAndrieu> JoeAndrieu has joined #vcwg
19:05:00 <BrianR> BrianR has joined #vcwg
19:05:02 <selfissued> selfissued has joined #vcwg
19:05:18 <andres> kristina: Our agenda today is focusing on a PR in vc-jose-cose.
19:05:33 <Orie> Orie has joined #vcwg
19:05:35 <Orie> present+
19:05:47 <andres> ... Then we'll cover 3 issues.
19:05:55 <andres> ... Time permitting, we'll continue with vc-data-model issues.
19:06:08 <andres> ... Any other topics?
19:06:14 <seabass> q+
19:06:19 <kristina> ack seabass
19:06:35 <andres> seabass: Will brent be able to attend? If not, when will he be back?
19:06:47 <andres> kristina: Back next week. Out on vacation. Why?
19:06:55 <andres> seabass: Related to GSMA.
19:07:17 <manu> present+
19:07:26 <andres> kristina: We talked about this. We can keep forming the liaison. That's orthogonal to CR.
19:07:46 <andres> ... Let's start with vc-jose-cose.
19:07:52 <kristina> topic: controller documents
19:07:53 <DavidC> present+
19:07:54 <kristina> subtopic: https://github.com/w3c/vc-jose-cose/pull/144
19:08:16 <andres> ... We discussed at TPAC.
19:08:24 <Orie> q+ to discuss controller docs vs did docs
19:08:44 <andres> ... vc-jose-cose and vc-di are adding text on how to retrieve the controller verification documents when a credential is being signed using DIDs.
19:09:13 <andres> ... We've seen discrepancies. As a chair, I'd like to see both specifications citing directly did-core, and clarifying what additional requirements are needed on top of it.
19:09:39 <kristina> q?
19:09:42 <kristina> ack Orie
19:09:42 <Zakim> Orie, you wanted to discuss controller docs vs did docs
19:09:43 <andres> ... If editors can agree, cool, let's move on. If not, let's discuss
19:10:30 <andres> orie: I wasn't in TPAC. Got an update. If the WG consensus is to have DI and vc-jose-cose controller defined documents, then they both say the same things or not.
19:10:47 <andres> ... You can't simply cite did-core.
19:11:08 <andres> ... A controller document is different than a did document.
19:11:20 <andres> ... The former has URLs in it. The latter has DIDs.
19:11:32 <andres> ... Let's make sure we don't miss that distinction.
19:11:45 <andres> ... Our specs have URLs, not DIDs with fragments.
19:12:14 <andres> ... Let's ensure that securing specifications are capable of specifying examples in the spec.
19:12:26 <andres> ... We need to extend did-core if we're allowing URLs.
19:12:42 <andres> kristina: Alternative path forward - don't cite did-core.
19:12:48 <Orie> dlongley noted (via emote): a DID document is essentially a subclass of a controller document -- we just had to define these things in reverse order in standards space for a variety of reasons
19:13:00 <andres> ... Make it clear it's URLs. I think that's what DI does.
19:13:07 <andres> ... Then vc-jose-cose should do the same.
19:13:13 <andres> ... manu are you ok with that?
19:13:31 <andres> manu: Agree with any direction that doesn't bifurcate what controller documents are.
19:14:01 <Orie> manu that sounds good, afaik we have only removed text from data integrity.
19:14:02 <andres> ... If vc-jose-cose subclasses more what DI does, that's fine.
19:14:39 <Orie> we are already duplicating text.. because URLs are not DID URLs.
19:14:56 <andres> ... ONe way is to say which bits are on top of did-core. Another is to repeat a lot of text with specific deviations. We would need to be very careful.
19:15:11 <Orie> data integrity duplicated text first, vc-jose-cose just copied it, and removed data integrity specific language.
19:15:32 <Orie> +1 manu
19:15:38 <andres> ... Summary, fine with the concept. Want to make sure that the message is that both definitions are compatible with one another, just profiling did-core differently.
19:16:05 <Orie> q+ to comment on DID Docs being a subclass of data integrity controller documents
19:16:15 <andres> kristina: Base controller doc definition, before any profiling, are there disagreements there?
19:16:16 <kristina> ack Orie
19:16:16 <Zakim> Orie, you wanted to comment on DID Docs being a subclass of data integrity controller documents
19:16:25 <andres> orie: I think I agree
19:16:31 <selfissued> present+
19:16:44 <andres> ... It's weird to say that VCWG is defining the controller document.
19:16:54 <andres> ... But as long as everyone's clear, this is an improvement.
19:17:04 <andres> ... I'm supporting of that framing in language.
19:17:15 <andres> ... But unsure if we can, or if there's consensus.
19:17:45 <andres> ... To be clear, I think the section that DI defined is better than what's in did-core. Wouldn't like to see it taken out.
19:18:30 <andres> ... Are we allowed to do it in the DI spec? If so, and we do it as well in vc-jose-cose, should we move it do VCDM?
19:18:50 <dlongley> +1 it's weird, yes, but it's an artifact of history and standards process stuff, not technology ... and it was expected to happen.
19:18:58 <selfissued> "Better than DID Core" :-)
19:19:06 <andres> kristina: I'll take an AI to confirm that it's in scope for this WG to be able to define the base controller document.
19:19:14 <Orie> turns out that being better than DID Core is a pretty low bar : ?
19:19:55 <Orie> +1 to moving the section to the core data model.... if we can.
19:19:57 <dlongley> DID core and the work in this ecosystem had some pretty big constraints put onto it that had some adverse outcomes :)
19:19:58 <manu> q+
19:19:59 <andres> ... Assuming it's true, any concerns for general controller document definition going to vcdm? And then DI and vc-jose-cose adding on top of it?
19:20:04 <kristina> ack manu
19:20:22 <selfissued> q+
19:20:27 <andres> manu: I don't think it belongs in the VCDM. This is about the securing mechanisms, and doesn't feel like the right place to put it.
19:20:49 <dlongley> +1 "controller documents" has always been part of the data integrity / LD proofs work -- it makes sense to have it be there.
19:20:59 <andres> ... Agreed with everything except that one piece.
19:21:14 <Orie> Google folks mentioned wanting to see verification in scope, and i thought i saw possible FO if we don't address it... seems like keeping controller documents in data integrity and duplicating text will open us up to some risk of FO.
19:21:20 <andres> ... I think it would be ok to duplicate.
19:21:33 <andres> ... As background, these concepts used to be part of linked data signature.
19:21:38 <dlongley> some of this "let's put it in kinda the wrong place" arguments ... are how DID core got to be the way it is :)
19:21:45 <andres> ... Just so happened that they were also in did-core.
19:21:57 <andres> ... But because of chartering reasons, we couldn't do it at the time.
19:22:04 <Orie> yeah, i agree dlongley, but sometimes you have to break legs to fix them.
19:22:11 <andres> ... So +1 to everything except putting in the VCDM.
19:22:14 <kristina> ack selfissued
19:22:22 <dlongley> i'm saying DID core got its legs broken to begin with by this sort of thing.
19:22:32 <dmitriz> @Orie - Google folks mentioned they'd be fine with it if verification was described in /parallel/ specs that would go to CR at the same time as VC DM 2.0. Which they are
19:22:36 <andres> selfissued: Generic comment. If we want something common, it should be in one place. We can create a key discovery spec.
19:22:50 <manu> q+
19:22:51 <andres> ... That's probably better than duplicating the text, which will likely get out of sync.
19:22:55 <kristina> ack manu
19:23:21 <selfissued> q+
19:23:32 <seabass> q+
19:23:35 <andres> manu: If everyone can agree that we lift the text from DI and put it in a different spec, this would lead into a long drawn out debate.
19:23:35 <Orie> q+ to say that controller documents are clearly used by more than just data integrity proofs or jsonld signatures
19:23:38 <kristina> ack selfissued
19:23:42 <andres> ... And it would put us in a worst position.
19:23:58 <andres> selfissue: I hear you, procedurally.
19:24:16 <dlongley> Orie: it's fine if other things want to use controller docs that DI defines, those things should refer to that text -- or if those things don't want to just refer for some reason, they can copy the exact same text.
19:24:31 <andres> ... I was thinking of possible ways of doing so (in the base common doc). And then each spec defined how they're securing it.
19:24:44 <kristina> ack seabass
19:25:12 <Orie> dlongley yeah, i guess it seems like people don't like refering to data integrity to use controller documents... that seems to be the problem.
19:25:36 <andres> seabass: If there is going to be objection in a separate spec, is there going to be disagreement between implementers?
19:25:41 <kristina> ack Orie
19:25:41 <Zakim> Orie, you wanted to say that controller documents are clearly used by more than just data integrity proofs or jsonld signatures
19:25:42 <Orie> if the definitions are shared, it makes sense to decouple imo
19:25:44 <dlongley> Orie: yeah, one resolution to that would be to compromise and let that go so we can proceed
19:25:51 <andres> ... Are we kicking the can down the road and doing a disservice to others?
19:26:42 <andres> Orie: Json ld signatures were used in a couple of places.
19:27:05 <andres> ... Still used in many places. It's valuable to put things where they can be shared without bias.
19:27:29 <andres> ... Controller documents are the grandfathers of dids. We should make it clear that people can refer to that.
19:27:49 <andres> ... If we can give that to the community, potentially a better outcome.
19:27:57 <andres> ... More work for us, but a better outcome.
19:28:32 <andres> kristina: For now, let's have vc-jose-cose duplicate the text from DI with it's own requirements. That should be the starting point.
19:28:44 <andres> ... Then I'll consult if we're willing to entertain an additional doc.
19:28:52 <manu> +1 on kristina's current proposal.
19:28:54 <andres> ... I'll come back to the WG after.
19:29:00 <andres> ... Any objections?
19:29:00 <Orie> +1
19:29:07 <selfissued> +1
19:29:10 <andres> +1
19:29:13 <pdl_asu> +1
19:29:14 <dmitriz> +1
19:29:18 <dlongley> +1 sounds like an ok way to proceed
19:29:34 <dwaite> dwaite has joined #vcwg
19:29:36 <dwaite> present+
19:29:45 <selfissued> q+
19:29:50 <andres> kristina: PR unblocked. Let's move to work item updates.
19:29:52 <kristina> topic: work item update/PRs
19:30:18 <andres> selfissued: Does that mean we can merge 144?
19:30:50 <andres> manu: It's not just a copy/paste. It doesn't clarify what's being subclassed.
19:30:51 <Orie> sounds like the PR is still blocked
19:31:14 <Orie> and there is no consensus on how to proceed, pending discussion on controller documents in the abstract
19:31:15 <Orie> q+
19:31:20 <andres> kristina: Orie can you comment on the modified parts from DI?
19:31:27 <kristina> ack selfissued
19:31:27 <kristina> ack Orie
19:31:32 <kristina> ack Orie
19:31:59 <andres> Orie: The PR started with a copy. Then there were many sections that were removed related to DI.
19:32:24 <andres> ... After several rounds of suggestions, seems like the PR is irrecoverable. It will not achieve consensus.
19:32:58 <andres> ... That's fine. Best path forward is giving us a single place that both specs can refer to.
19:33:07 <manu> q+ on easier path forward.
19:34:27 <andres> ... Not sure how to resolve. But the PR is blocked.
19:34:57 <andres> kristina: manu, What are the normative changes that were made that you are concerned about?
19:35:10 <kristina> ack manu
19:35:10 <Zakim> manu, you wanted to comment on easier path forward.
19:35:32 <selfissued> +1
19:35:39 <Orie> I can put in an issue marker
19:35:43 <andres> manu: That's not the concern. I would suggest to put an issue marker explaining that the WG is attempting to align the definitions between DI and vc-jose-cose.
19:35:55 <andres> kristina: Sounds like a way forward.
19:36:22 <selfissued> Thanks all
19:36:36 <andres> ... manu, if you can open an issue where you explain what text you'd like to be better aligned, that would be helpful.
19:36:38 <Orie> sounds good!
19:36:50 <Orie> PR will be unblocked after issue marker is added.
19:37:06 <andres> ... Sorry, ivan, some cleanup will need to be done :-)
19:37:06 <kristina> topic: work item updates/PRs.
19:37:39 <andres> kristina: Any PRs that need attention?
19:37:47 <manu> I'd like to move forward to the DI issues... (as that is PRs/updates that need to be discussed)
19:38:21 <andres> ... On VCDM, there were a handful of PRs that were merged. If you missed those, PTAL.
19:38:48 <andres> ... Otherwise, there are a few PRs addressing horizontal review. Thanks decentralgabe.
19:39:22 <andres> ... We marked PR 1271 as do not merge
19:39:34 <andres> ... And we'll invite the i18n group to have a discussion.
19:39:34 <kristina> topic: https://github.com/w3c/vc-jose-cose/pull/144
19:39:48 <kristina> subtopic: https://github.com/w3c/vc-di-ecdsa/issues/39
19:40:34 <manu> q+
19:40:38 <andres> kristina: tldr; there was an issue coming in about normative references about multibase and multicodec. We agreed to fix that in the vcdm. Now there are issues about addressing them in the cryptosuite spec docs.
19:40:47 <kristina> ack manu
19:40:52 <andres> ... manu did a PR in which selfissued is asking for changes.
19:40:55 <manu> subtopic: https://github.com/w3c/vc-data-integrity/pull/196
19:41:23 <andres> manu: selfissued suggested we removed normative dependencies on any multiformats specifications, because they aren't standards.
19:41:40 <andres> ... I heard consensus during f2f where we agree to make those references non-normative.
19:41:46 <selfissued> q+
19:41:50 <andres> ... This is what the PRs I raised are doing.
19:42:24 <andres> ... I think what selfissued is asking for is the complete removal to any reference. Even if they are non-normative.
19:43:32 <andres> ... As for the other issues raised with other cryptosuites, they say what the normative values should be.
19:43:37 <kristina> ack selfissued
19:44:10 <andres> selfissued: The core of the discussion wasn't about normative vs non-normative references. It was about required features needing to be normatively defined.
19:44:11 <manu> q+ to note required features ARE normatively defined. Show us where it isn't.
19:44:23 <shigeya> present+
19:44:26 <andres> ... They have to be defined before going to CR.
19:44:42 <manu> https://pr-preview.s3.amazonaws.com/w3c/vc-data-integrity/pull/196.html#dfn-proofvalue
19:44:51 <manu> ^ normatively defined right there
19:44:56 <andres> ... I'm still seeing that the value is defined, which cannot be defined since multiformats isn't a standard.
19:45:38 <andres> ... I think we should be able to normatively defined the contents of every spec without referring to the multiformats spec.
19:45:50 <seabass> q+
19:45:50 <andres> ... Adding a note stating that it's compatible is ok.
19:45:52 <dmitriz> present+
19:45:54 <dmitriz> q?
19:46:17 <andres> kristina: To clarify, you are asking the DI document to redefine multibase/multicodec instead of referring to the internet draft?
19:46:31 <andres> selfissued: Yes, with the subset that actually matters.
19:46:38 <kristina> ack manu
19:46:38 <Zakim> manu, you wanted to note required features ARE normatively defined. Show us where it isn't.
19:46:54 <andres> manu: That's exactly what it does.
19:47:37 <andres> ... <manu reads the pr preview>
19:47:48 <seabass> q-
19:47:52 <selfissued> "The contents of the value MUST be a [MULTIBASE]-encoded binary value with a header and encoding as described in 2.4 Multibase." retains normative use
19:47:59 <selfissued> q+
19:48:04 <seabass> q+
19:48:10 <andres> kristina: Why do you need a reference to multibase?
19:48:26 <andres> manu: Because it's useful for implementers. Explains the background.
19:48:37 <andres> ... Useful as pointing to any non-normative document.
19:48:55 <manu> "[MULTIBASE]-encoded"
19:49:06 <kristina> ack selfissued
19:49:07 <andres> ... I'm confused what's being objected to.
19:49:26 <andres> selfissued: quoted the sentence that's objected to.
19:49:34 <seabass> q-
19:49:57 <andres> manu: I'll make the changes to remove the multibase bit.
19:50:14 <andres> ... The other PRs point to the section that will be fixed.
19:50:23 <andres> ... That's how they refer to it normatively.
19:50:57 <selfissued> https://github.com/w3c/vc-di-eddsa/pull/63/files
19:51:20 <andres> ... I'll makesure that all similarly worded phrases refer to the normative spec (i.e. DI).
19:51:28 <seabass> q+
19:51:49 <kristina> same for https://github.com/w3c/vc-di-eddsa/issues/62 and https://github.com/w3c/vc-di-bbs/issues/92.
19:51:51 <andres> selfissued: That also has a sentence.
19:51:58 <andres> manu: I can remove that as well.
19:52:04 <andres> ... we have a path forward.
19:52:06 <kristina> ack seabass
19:52:22 <andres> seabass: Pointing out the multibase isn't a protected trademark.
19:52:33 <andres> ... We should be specific and define everything that we need.
19:52:49 <andres> ... We can still call it multibase.
19:52:53 <Orie> https://twitter.com/multibase_co is a YC company, doing web3 analytics.... which i get ads from constantly.
19:53:02 <andres> kristina: might be confusing, but that's fine
19:53:11 <andres> ... got 3 minutes, any issue/PR?
19:53:58 <selfissued> q+
19:54:19 <kristina> ack selfissued
19:54:36 <kristina> rrsagent, draft minutes
19:54:37 <RRSAgent> I have made the request to generate https://www.w3.org/2023/09/27-vcwg-minutes.html kristina
19:55:33 <kristina> zakim, end meeting
19:55:33 <Zakim> As of this point the attendees have been TallTed, kristina, pdl_asu, seabass, dlongley, bigbluehat, decentralgabe, Orie, manu, DavidC, selfissued, dwaite, shigeya, dmitriz
19:55:36 <Zakim> RRSAgent, please draft minutes
19:55:37 <RRSAgent> I have made the request to generate https://www.w3.org/2023/09/27-vcwg-minutes.html Zakim
19:55:42 <Zakim> I am happy to have been of service, kristina; please remember to excuse RRSAgent.  Goodbye
19:55:43 <Zakim> Zakim has left #vcwg
19:55:46 <kristina> rrsagent, bye
19:55:46 <RRSAgent> I see no action items