18:53:14 <RRSAgent> RRSAgent has joined #vcwg
18:53:18 <RRSAgent> logging to https://www.w3.org/2023/05/24-vcwg-irc
18:53:26 <Zakim> Zakim has joined #vcwg
18:54:42 <brent> brent has changed the topic to: Meeting Agenda 2023-05-24: https://www.w3.org/events/meetings/36ecd2da-2ec3-4012-b74a-72546ab352f4/20230524T150000
18:55:07 <brent> zakim, start the meeting
18:55:07 <Zakim> RRSAgent, make logs Public
18:55:09 <Zakim> please title this meeting ("meeting: ..."), brent
18:55:27 <brent> meeting: Verifiable Credentials Working Group Weekly Telecon
18:55:36 <brent> chair: Kristina Yasuda
18:55:41 <brent> present+
18:59:06 <mprorock> mprorock has joined #vcwg
19:01:03 <kristina> kristina has joined #vcwg
19:01:23 <kristina> kristina has changed the topic to: VCWG Agenda 2023-05-24
19:01:33 <kristina> zakim, start meeting
19:01:33 <Zakim> RRSAgent, make logs Public
19:01:34 <pdl_asu> pdl_asu has joined #vcwg
19:01:35 <Zakim> please title this meeting ("meeting: ..."), kristina
19:01:38 <pdl_asu> present+
19:01:40 <kristina> Meeting: Verifiable Credentials Working Group Telco
19:01:44 <kristina> present+
19:01:47 <kgriffin> kgriffin has joined #vcwg
19:01:49 <kristina> chair: kristina
19:02:11 <mprorock> present+
19:02:15 <dlongley> present+
19:04:17 <dlongley> scribe+
19:04:19 <kgriffin> present+
19:04:27 <manu> manu has joined #vcwg
19:04:41 <oliver> oliver has joined #vcwg
19:04:44 <oliver> present+
19:04:47 <dlongley> kristina: We have PRs and issues for today.
19:04:58 <dlongley> kristina: Anything people want to make sure we cover today?
19:05:58 <dlongley> kristina: Mike Prorock has some PRs to discuss.
19:06:02 <dlongley> kristina: Let's start with those.
19:06:05 <mprorock> q+
19:06:11 <mprorock> https://github.com/w3c/vc-status-list-2021/pull/65
19:06:14 <kristina> ack mprorock
19:06:26 <kristina> subtopic: https://github.com/w3c/vc-status-list-2021/pull/65
19:06:38 <dlongley> mprorock: The first one to put out there for attention is VC status list PR #65. This adds a backwards compatible approach to providing the ability to encode multiple statuses in a single list.
19:06:40 <Will> Will has joined #vcwg
19:07:03 <Orie> Orie has joined #vcwg
19:07:07 <dlongley> mprorock: We have multiple use cases for this, such as US customs that have 3-4 or more statuses at once.
19:07:12 <Orie> present+
19:07:20 <dlongley> mprorock: This is to add this in a backwards compatible way.
19:07:26 <decentralgabe> decentralgabe has joined #vcwg
19:07:30 <decentralgabe> present+
19:07:32 <dlongley> mprorock: Having written an implementation of this and tested it in two different languages, it doesn't seem like a huge list.
19:07:47 <dlongley> mprorock: If you assume a size of 1 for the existing stuff, if the size is expressed you use that as a multiplier instead.
19:07:53 <dlongley> mprorock: It's not a huge lift.
19:07:56 <kristina> q?
19:07:57 <dlongley> q+
19:08:05 <manu> scribe+
19:08:12 <GregB> GregB has joined #vcwg
19:08:12 <kristina> ack dlongley
19:08:17 <GregB> present
19:08:36 <manu> dlongley: This would mean that there were two different ways to express multiple statuses, we should consider if we can get down to one way and which one is better and what the tradeoffs are.
19:08:56 <kristina> present+ GregB
19:09:11 <Orie> This approach would cut down on http overhead, and associated privacy implications when multiple independent lists are used.
19:09:25 <mprorock> q+
19:09:30 <manu> dlongley: I haven't been able to think about privacy considerations approach, bit list, and herd privacy. In terms of complexity, it's not just about having number to multiply by... need to think about this. We had said previously that we could have multiple lists... this is a different approach to that, don't know what the consequences are here.
19:09:32 <kristina> ack mprorock
19:09:39 <dlehn> present+
19:09:57 <dlongley> mprorock: One thing I would note -- Orie noted this in the chat -- this significantly cuts down on network trips if you have multiple things to check, you use one network call instead of N.
19:10:13 <dlongley> mprorock: This cuts down on business rules like having to specify business rules and things like that -- you can avoid that.
19:10:40 <manu> q+
19:10:45 <dlongley> mprorock: In regards to having multiple ways to represent statuses, I'm not sure if that's a bad thing. There are cases that require just suspension or revocation checks and this just provides more flexibility in the ways the use cases can be addressed.
19:10:51 <kristina> ack manu
19:11:34 <dlongley> manu: Real quick. I've been trying to work on the privacy characteristics. People have said that the problem with the bit string starting at zero -- what if we want to hide the number of members in a herd. I think what's being proposed might make some of those approaches not work anymore. I haven't been able to look at the PR can't say positive or negative yet.
19:11:46 <mprorock> q+ to comment back to manu re privacy
19:11:59 <dlongley> manu: Mike, I don't know if you looked into herd privacy, I know in supply chain it's not a super important thing but in the digital ID use cases it's important, these might be in conflict, we'll have to think about it more.
19:11:59 <kristina> ack mprorock
19:11:59 <Zakim> mprorock, you wanted to comment back to manu re privacy
19:12:37 <dlongley> mprorock: Absolutely, well aware and appreciate your reasoning. I think we need to think it through. Sometimes linkability is desirable and sometimes not. We could have a follow-on PR for these considerations.
19:12:40 <Orie> consider the case where you have many statuses on the minimum length... https://w3c.github.io/vc-status-list-2021/#revocation-bitstring-length
19:12:44 <Orie> also consider decoyes
19:13:00 <dlongley> mprorock: I personally think things like fuzzing size and so on could be done and worth considering.
19:13:03 <dlongley> kristina: Thank you Mike.
19:13:15 <dlongley> kristina: Any other PRs to talk about?
19:13:19 <dlongley> mprorock: The other PRs are on VC-JWT.
19:13:24 <mprorock> https://github.com/w3c/vc-jwt/pull/85
19:13:34 <dlongley> mprorock: PR #85 removes 1.1 from the VC-JWT spec.
19:13:35 <kristina> subtopic: https://github.com/w3c/vc-jwt/pull/85
19:13:39 <Orie> This PR should be merged: https://github.com/w3c/vc-status-list-2021/pull/46
19:13:54 <dlongley> mprorock: It has all approvals in -- just want to make sure there are no additional commentaries in there before it goes in.
19:14:07 <dlongley> kristina: I see 6 approvals and 1 week time. Why is it not merged yet?
19:14:42 <dlongley> mprorock: Just hit a week now.
19:14:42 <JoeAndrieu> JoeAndrieu has joined #vcwg
19:14:42 <dlongley> kristina: Any objections on this call now?
19:14:42 <mprorock> https://github.com/w3c/vc-jwt/pull/86
19:14:42 <dlongley> kristina: No one is blocking.
19:15:13 <dlongley> mprorock: Great. PR #86 is also ready for merging, last chance to get adjustments in.
19:15:21 <dlongley> kristina: Any objections to merging this one as well?
19:15:36 <pdl_asu> +1 to #86
19:15:37 <dlongley> kristina: No blockers here either.
19:15:43 <mprorock> https://github.com/w3c/vc-jwt/pull/88
19:15:53 <dlongley> mprorock: We have a valid change request in -- for PR #88 -- but it will need discussion.
19:16:07 <brent> subtopic: https://github.com/w3c/vc-jwt/pull/88
19:16:27 <dlongley> mprorock: This one does something potentially controversial. It removes the securing JSON section. It makes VC-JWT focus only on securing the core data model with no transformations or mappings, nothing else.
19:16:43 <dlongley> mprorock: Kristina has mentioned market interest in vanilla JSON claims in VC-JWT.
19:16:52 <kristina> q?
19:16:55 <dlongley> mprorock: So I've raised that to get comments from the community.
19:16:59 <Orie> q+
19:17:05 <dlongley> kristina: Any comments on that?
19:17:05 <kristina> ack Orie
19:17:43 <dlongley> Orie: Regarding removing VC-JWT media type and securing plain JSON -- I'm in favor of this PR. I'm in favor of this based on the day 3 F2F resolution and the work load for this group.
19:17:55 <kristina> present+ manu
19:18:10 <dlongley> Orie: We have several technical recommendations to work on and it's very unlikely to get consensus on the day 3 resolution in the core data model and without that consensus we will not be able to elevate this item to the point where it will go into CR.
19:18:42 <dlongley> Orie: Without adding normative statements that will be contentious and it won't be able to get merged and I foresee this not going anywhere as long as this section stays in the document. I'm making that assessment based on the rate of engagement and so on.
19:18:44 <kristina> q?
19:18:53 <dlongley> dlongley: +1 to remove the section
19:19:00 <pdl_asu> +1 to remove this section
19:19:06 <dlongley> kristina: Any other PRs?
19:19:13 <Orie> q+
19:19:15 <Orie> https://github.com/w3c/vc-status-list-2021/pull/46
19:19:16 <kristina> ack Orie
19:19:34 <kristina> subtopic: https://github.com/w3c/vc-status-list-2021/pull/46
19:19:49 <manu> q+
19:19:59 <dlongley> Orie: I'd like to circle back to PR #46 on status list. The changes requested are assuming a particular transport protocol and it's possible that additional PRs could come in to improve the quality of the spec and I don't think we should hold up this PR.
19:20:12 <mprorock> q+
19:20:18 <dlongley> Orie: There's nothing in there, this is an improvement and others need to be made and I'd like to merge this so we can make incremental improvements.
19:20:20 <kristina> ack manu
19:20:52 <dlongley> manu: In addition to what Orie said -- I raised issue #64 and that issue's title is "Add a section on expected server HTTP status codes", that's now being tracked. I believe that's what both Kristina and Mike Jones were asking for that.
19:21:07 <dlongley> manu: So I think there's a way to do it -- but doing it in this PR would just make the PR really big and potentially further delay it getting merged in.
19:21:22 <kristina> ack mprorock
19:21:28 <dlongley> manu: The only change request that was blocking this -- I requested a re-review from you, Kristina and Mike Jones.
19:21:38 <dlongley> mprorock: Yeah, if we merge we can build on top of it.
19:21:45 <dlongley> mprorock: Can I add a note that references that issue?
19:21:47 <dlongley> manu: Yes, totally fine.
19:22:02 <dlongley> kristina: Ok, I will re-review and hopefully MikeJ will read the notes.
19:22:06 <dlongley> kristina: Thank you, Orie.
19:22:09 <dlongley> kristina: Anything else?
19:22:10 <kristina> q?
19:22:11 <Orie> https://github.com/w3c/vc-status-list-2021/pull/60
19:22:13 <Orie> q+
19:22:21 <kristina> subtopic: https://github.com/w3c/vc-status-list-2021/pull/60
19:22:22 <kristina> ack Orie
19:22:40 <kristina> present+ Will
19:22:44 <dlongley> Orie: We seem to have a difference of opinion regarding adding examples to the specification. And I would like to merge the examples as-is. I don't agree with the perspective that every example in our spec needs multiple context values.
19:22:47 <dmitriz> dmitriz has joined #vcwg
19:22:57 <dlongley> Orie: I don't agree with that and in light of bundling the Data Integrity context.
19:23:05 <dlongley> Orie: This adds informative examples, can we merge this, please, thank you.
19:23:10 <dmitriz> present+
19:23:36 <GregB> Please!
19:23:37 <dlongley> manu: -1 to merge until the WG discusses it. With all the examples it keeps coming up and we need to have a consistent way that we're doing examples and figure out what it is so the editors can apply that uniformly across all the specs.
19:23:44 <manu> q+
19:23:46 <pdl_asu> is this a special topics call?
19:23:52 <dlongley> kristina: I'm up for spending 5-10 minutes on this call on this.
19:23:54 <kristina> ack manu
19:24:00 <Orie> lets remove the DataIntegrityProof RDF class from the core context... and make the examples include multiple contexts.
19:24:05 <dlongley> manu: I don't know if we'll get through it in 5 minutes. The proposal is to just use the example in the core spec.
19:24:31 <dlongley> manu: Use it as an example across all the specs that need to use an example. That way we're just using an example that we've agreed to use across all the specs and we don't need to do variations of that in every other specification.
19:25:03 <Orie> related PR: https://github.com/w3c/vc-data-model/pull/1091
19:25:17 <dlongley> kristina: Are you fundamentally not ok with the example, Manu?
19:25:18 <dlongley> manu: Yes.
19:25:27 <Orie> q+
19:25:35 <mprorock> q+
19:25:41 <dlongley> kristina: Anyone else who has strong opinions about what examples we use?
19:25:43 <kristina> ack Orie
19:25:48 <dlongley> q+
19:25:55 <kristina> ack mprorock
19:25:56 <dlongley> Orie: Are the examples conformant to the core data model?
19:26:10 <dlongley> mprorock: My question is along the same line... what precisely is wrong with the examples?
19:26:26 <dlongley> mprorock: At least by my read and going and running the example code it all checks out fine.
19:26:27 <kristina> s/Are the examples conformant to the core data model?/All the examples conformant to the core data model.
19:26:37 <dlongley> q?
19:26:40 <manu> q+
19:26:40 <kristina> ack manu
19:27:11 <dlongley> manu: One of the things is that we have a suspension false entry in here, I don't know where that property came from, I think Orie said that's an artifact in the PR and it's not in the data model.
19:27:24 <dlongley> manu: There's a concern over the use of the undefined / issuer-independent context / vocab.
19:27:31 <dlongley> manu: Now we're using the issuer-dependent terms in the example.
19:27:40 <dlongley> manu: There are a number of people that said in the other PR that's not a good practice.
19:27:56 <dlongley> manu: We've had people say that they would rather the examples use the examples context instead of the issuer-defined one.
19:28:06 <dlongley> manu: I don't know why we're doing in status list when core does something else.
19:28:13 <kristina> ack dlongley
19:28:36 <manu> dlongley: A lot of developers will come along and look at examples to get things started, and there are such things as good examples and bad examples.
19:28:55 <Orie> IMO a good example is one that uses the minimal required fields.
19:29:16 <kristina> present+ JoeAndrieu
19:29:47 <Orie> its bad form to include optional stuff in example, and bad form to include DataIntegrityProof in the core v2 context.
19:29:50 <manu> dlongley: You can create examples that are bad examples, which would be conformant, but wouldn't look good. It's not enough to say "We created an example and it validates so it's fine." If we get people started off on he wrong foot, or encouraging market failures, we're making mistakes. We should not be flippant about the examples we put in the spec. They're important, developers will look at these examples and maybe not the text.
19:29:58 <kristina> present+ brent
19:30:14 <manu> dlongley: Saying "this verifies" is not enough, these are entry points into the spec and possibly exit points.
19:30:24 <kristina> q?
19:30:25 <manu> kristina: Sounds like we're leaving this issue open for now.
19:30:30 <mprorock> q+
19:30:39 <dlongley> kristina: Anything on the BBS cryptosuite stuff?
19:30:39 <kristina> ack mprorock
19:30:53 <dlongley> mprorock: Before we go -- I'm seeing a comment here objecting to claim name and value.
19:31:16 <Orie> They are not defined... we added `@vocab` to the spec...
19:31:31 <Orie> the assertion that `@vocab` is not a best practice, is false.
19:32:19 <manu> dlongley: My general objection is creating examples with undefined properties that relies on issuer-dependent properties without there being issuer-dependent properties. That is a bad practice that has plagued the ecosystem for the past 10 years. This is not a best practice, this is something you can fall back on.
19:32:29 <manu> mprorock: So you're going to objecting to anything with @vocab?
19:32:32 <manu> dlongley: That's not what I said.
19:33:16 <Orie> Put another way, want to encourage developers to resolve multiple contexts for any terms not in the core data model, except for DataIntegrityProofs
19:33:25 <manu> dlongley: I said that for anything we're doing, we shouldn't have issuer-dependent vocabularies as a first cut... if you don't have time for it or doing an experiment, you should know full well that doing issuer-dependent isn't the best thing for the ecosystem. Maybe there is a use case that doesn't matter... but it should not be used inf undamental examples to developers on how to use basic features.
19:33:40 <manu> mprorock: Ok, got it.
19:33:41 <dlongley> kristina: Ok, good, thank you.
19:33:55 <dlongley> kristina: We're down to three PRs, very nice.
19:33:58 <Orie> q+
19:34:09 <kristina> ack Orie
19:34:36 <dlongley> Orie: Part of the reason we're down to 3 is that I just closed some PRs. I closed one to come up with language regarding issuer-dependent terms where we weren't getting consensus.
19:34:47 <dlongley> Orie: I encourage Dave and Ivan to make PRs on that to improve the document.
19:35:14 <dlongley> Orie: I opened and closed PRs for predicates that we don't define and I assume we'll get a chance to object to those when we get to CR.
19:35:15 <dlongley> q+
19:35:19 <kristina> ack dlongley
19:35:32 <mprorock> q+
19:36:08 <manu> dlongley: I would recommend, rather than unilaterally closing PRs, people make suggestions to these PRs... we can close thoe PRs, that causes others to create PRs and that's a way forward. We might want to be more efficient by continuing the work inside the PR itself.
19:36:17 <kristina> ack mprorock
19:36:20 <Orie> Is there a process requirement to do as dave suggested?
19:36:49 <dlongley> mprorock: I suspect that an author of a PR in a WG might want to close a PR, simply because this WG is extremely difficult to achieve consensus at all, and the author feels attacked to the point of utter frustration.
19:37:02 <dlongley> mprorock: I don't see any process requirements that say otherwise, I'm happy for the chairs to say otherwise.
19:37:15 <dlongley> kristina: The author of a PR may close the PR.
19:37:26 <dlongley> kristina: If a WG member thinks there was useful information in a PR please feel free to open a new one.
19:37:33 <manu> q+
19:37:42 <kristina> ack manu
19:38:05 <kgriffin> q+ 1100/1101 question
19:38:26 <dlongley> manu: On Mike's comment. Going back, presuming good faith among the WG members, we're all trying to work toward a common goal here. I know it can be incredibly frustrating to raise a PR and have it languish or be constantly whittled at -- I know a number of my PRs have gone through that and at the end we closed them.
19:38:35 <dlongley> manu: I know that can be really frustrating but we should all keep in mind that it's not a personal attack.
19:38:40 <Orie> If it really mattered to me, I would not have closed it
19:38:47 <mprorock> q+
19:38:56 <Orie> I sincerly hope other people will try to raise PRs to improve the spec.
19:39:15 <brent> q+ kgriffen to ask 1100/1101 question
19:39:15 <dlongley> manu: And please try really hard not to take these things personally as frustrating as it may be. I wanted `renderMethod` in there, for example, and tried really hard to get it in, but it didn't get in, everyone has their own motivations and sometimes we just don't get to consensus.
19:39:23 <dlongley> manu: I would be careful with saying that people are attacking you.
19:39:25 <kristina> q?
19:39:27 <brent> ack 1100/1101
19:39:32 <dlongley> manu: I don't think we're dealing with those sorts of people in this WG.
19:39:34 <brent> ack question
19:39:45 <mprorock> q-
19:39:46 <dlongley> kristina: I think Orie addressed that in chat.
19:39:54 <mprorock> +1 kristina
19:40:18 <kristina> ack kgriffin
19:40:28 <kristina> q?
19:40:35 <kristina> ack kgriffin
19:40:41 <dlongley> kgriffin: I assume since we had the special topic call regarding 1100/1101 that we wouldn't be discussing those here, the chairs noticed paths forward, just wanted to make sure that's the case.
19:40:58 <dlongley> kristina: Yes, thanks for bringing it up, we discussed those on the special topic call. It was a good call.
19:41:11 <dlongley> kristina: I think Brent and I will sync and propose something.
19:41:21 <dlongley> kristina: In the meantime do what you can in the PR.
19:41:28 <dlongley> kristina: Let's move to the issues.
19:41:42 <kristina> topic: issues
19:41:46 <kristina> https://github.com/w3c/vc-data-model/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-asc+no%3Aassignee
19:42:17 <dlongley> kristina: Let's stick to the usual policy. If there's no one who can lead an issue we'll put pending close.
19:42:21 <kristina> subtopic: https://github.com/w3c/vc-data-model/issues/1102
19:42:46 <dlongley> kristina: David Chadwick is looking to remove extension points and replace them with another approach.
19:42:53 <dlongley> kristina: I think there are very strong voices against it.
19:43:04 <dlongley> kristina: Anyone willing to lead this issue?
19:43:05 <mprorock> q+
19:43:11 <kristina> ack kgriffin
19:43:19 <kristina> ack kgriffen
19:43:19 <Zakim> kgriffen, you wanted to ask 1100/1101 question
19:43:25 <kristina> ack mprorock
19:43:48 <dlongley> mprorock: Frankly, I'd object to a change of this nature. Unless someone in the WG is willing to write a PR for this we should close it.
19:43:52 <dlongley> dlongley: +1 to close
19:44:00 <Steve_C_> Steve_C_ has joined #vcwg
19:44:23 <kristina> subtopic: https://github.com/w3c/vc-data-model/issues/1095
19:44:32 <dlongley> kristina: Images in the data model.
19:44:55 <dlongley> kristina: Is there anyone who could take the lead on this?
19:45:00 <mprorock> q+
19:45:05 <kristina> ack mprorock
19:45:12 <manu> This is a great idea, we should have it in the spec, there are some possibilities... but starved for time. :(
19:45:25 <brent> q+
19:45:27 <dlongley> mprorock: I pun intended ... think this is a beautiful idea but have no bandwidth to deal with it. If no one else is willing to stand up I'm willing to mark as pending closed.
19:45:39 <kristina> ack brent
19:45:41 <Orie> suggest closing.
19:45:50 <kristina> s/I put/no pun
19:45:55 <mprorock> +1 brent - this is editorial in nature
19:46:12 <dlongley> brent: Another option is to mark this as post CR. This is proposing completely editorial changes. Theoretically we'd have time and bandwidth once we're in CR and going through that process. Now we could say "our diagrams are prettier!" and that's not a substantive change.
19:46:24 <dlongley> kristina: Any objections to post CR label?
19:46:27 <dlongley> kristina: Ok, we'll do that.
19:46:37 <Orie> q+
19:46:45 <kristina> ack Orie
19:46:51 <Orie> https://github.com/digitalbazaar/respec-vc/pull/8
19:47:24 <dlongley> Orie: I do think ... Manu raised a concern regarding the existing SVG assets that we have. Something to the effect that we need semantic annotation so we can align with a11y requirements of W3C.
19:47:38 <dlongley> Orie: I wanted to confirm that W3C requires SVG with web a11y with annotation to provide images in specs.
19:47:48 <dlongley> Orie: I've also updated a plugin for examples and updated that to support the latest VC-JWT spec.
19:47:55 <dlongley> Orie: It contains some visual examples using mermaid.
19:48:11 <dlongley> kristina: I'm keeping post CR for now.
19:48:19 <dlongley> kristina: If later on -- we can close or address.
19:48:32 <kristina> subtopic: https://github.com/digitalbazaar/respec-vc/pull/8
19:48:33 <Orie> q+
19:48:49 <kristina> s/subtopic: https://github.com/digitalbazaar/respec-vc/pull/8/subtopic: https://github.com/w3c/vc-data-model/issues/1116
19:49:01 <kristina> ack Orie
19:49:16 <dlongley> Orie: I don't think we should include `confidenceMethod` or any predicates in the core contexts for which there are no defined RDF types.
19:49:34 <dlongley> Orie: Exceptions to that -- are where we have a formal spec that defines an RDF type for that extension point.
19:49:34 <mprorock> +1 orie
19:50:06 <dlongley> Orie: If there's a CG spec then we can include it, like `renderMethod` ... for any predicates with "a blank check" because they have no RDF types ... should not be in the core context.
19:50:30 <dlongley> kristina: I'll assign this to Oliver for now to have him handle that.
19:50:36 <oliver> q+
19:50:44 <kristina> ack oliver
19:50:57 <dlongley> oliver: The `confidenceMethod` PR is currently stuck.
19:51:05 <mprorock> q+
19:51:12 <dlongley> oliver: And I don't know how to proceed.
19:51:50 <dlongley> oliver: I don't have anything to add today. I encourage everybody, especially those people who raised concerns in the PR to follow up on the latest.
19:52:02 <dlongley> oliver: Just to make it clear that there's a chance to get this PR merged or not.
19:52:11 <dlongley> oliver: If there's a chance to get it merged, what needs to be changed?
19:52:20 <Orie> ideally, define an RDF type for `confidenceMethod` completely, such and interoperability at both the predicate and the type can be achieved.
19:52:32 <Orie> look at the renderMethod PR.
19:52:38 <kristina> ack mprorock
19:53:07 <dlongley> mprorock: I would suggest that there's a path forward but might not be desirable. It is to follow exactly the model that was taken with `renderMethod`, where you take `confidenceMethod` define it in a CCG spec.
19:53:12 <dlongley> mprorock: I don't see people objecting.
19:53:36 <dlongley> mprorock: Point to it -- and at that point the road is clear, make sure it's in there and referencable, etc. It gives a clean path to incubate and polish.
19:53:36 <oliver> q+
19:53:52 <dlongley> mprorock: In the render case, there's a lot of implementers -- it may not be suitable as part of the core data model.
19:53:56 <Orie> q+ to comment on overlap with VPs
19:54:22 <dlongley> mprorock: I was having this conversation in person -- it isn't that a lot of things aren't good ideas, it's just a question of whether it would be better to standardize things in their own documents instead of in the core data model spec.
19:54:22 <kristina> ack oliver
19:54:47 <dlongley> oliver: I'm totally fine with that approach by the way. I can't really speak for the other people -- especially people who created holder binding over the last couple of years.
19:55:11 <dlongley> oliver: I think before closing this PR and moving forward with the way MikeP suggested, we need to reach out to those people and see if they object to moving forward the way he said.
19:55:15 <kristina> ack Orie
19:55:15 <Zakim> Orie, you wanted to comment on overlap with VPs
19:55:23 <dlongley> Orie: I just wanted to say -- a lot of this is related to VPs.
19:55:43 <dlongley> Orie: I find this incredibly poorly defined in the current data model. It's possible that efforts going into this `confidenceMethod` could massively improve the requirements around VPs.
19:56:03 <dlongley> Orie: I don't know, it's hard for me to tell. The requirements for a VP is that it's a JSON-LD object with a context and a type and that's enough rope to build anything.
19:56:13 <dlongley> Orie: It seems weird to me, some of this is related to subject-is-holder flows.
19:56:13 <mprorock> +1 orie - there is good value here - however once again this may be better handled as a separate specification
19:56:22 <dlongley> Orie: That's one reason this is held up -- it's covering a lot of ground.
19:56:34 <dlongley> Orie: VPs remain a weak spot in the spec and they need improvement.
19:56:34 <kristina> q?
19:57:06 <dlongley> kristina: Next week we are canceling both calls because both Brent and I are unavailable.
19:57:12 <dlongley> kristina: So we will see you in two weeks.
19:57:32 <brent> zakim, who is here?
19:57:32 <Zakim> Present: brent, pdl_asu, kristina, mprorock, dlongley, kgriffin, oliver, Orie, decentralgabe, GregB, dlehn, manu, Will, dmitriz, JoeAndrieu
19:57:36 <Zakim> On IRC I see Steve_C_, dmitriz, JoeAndrieu, GregB, decentralgabe, Orie, Will, oliver, manu, kgriffin, pdl_asu, kristina, mprorock, Zakim, RRSAgent, tzviya, brent, shigeya, dlehn,
19:57:36 <Zakim> ... cel[h], ounfacdo, bumblefudge1, Github, npd, saysaywhat, w3c_modbot, cel[m], bumblefudge, csarven, cel, dlongley, rhiaro, stenr, stonematt, Dongwoo, bigbluehat, hadleybeeman
19:58:42 <brent> present+ markus_sabadello
19:59:23 <brent> zakim, end the meeting
19:59:23 <Zakim> As of this point the attendees have been brent, pdl_asu, kristina, mprorock, dlongley, kgriffin, oliver, Orie, decentralgabe, GregB, dlehn, manu, Will, dmitriz, JoeAndrieu,
19:59:26 <Zakim> ... markus_sabadello
19:59:26 <Zakim> RRSAgent, please draft minutes
19:59:27 <RRSAgent> I have made the request to generate https://www.w3.org/2023/05/24-vcwg-minutes.html Zakim
19:59:36 <Zakim> I am happy to have been of service, brent; please remember to excuse RRSAgent.  Goodbye
19:59:36 <Zakim> Zakim has left #vcwg
19:59:36 <brent> rrsagent, bye
19:59:36 <RRSAgent> I see no action items