15:05:00 <RRSAgent> RRSAgent has joined #vcwg
15:05:04 <RRSAgent> logging to https://www.w3.org/2023/11/29-vcwg-irc
15:05:04 <Zakim> RRSAgent, make logs Public
15:05:05 <Zakim> please title this meeting ("meeting: ..."), ivan
15:05:29 <ivan> Meeting: Verifiable Credentials Working Group Telco
15:05:29 <ivan> Date: 2023-11-15
15:05:29 <ivan> Agenda: https://www.w3.org/events/meetings/ae05a21b-c065-4e69-8d5e-352a0d391513/20231129T110000/
15:05:29 <ivan> chair: brent
15:05:30 <ivan> ivan has changed the topic to: Meeting Agenda 2023-11-29: https://www.w3.org/events/meetings/ae05a21b-c065-4e69-8d5e-352a0d391513/20231129T110000/
15:06:12 <dmitriz> dmitriz has joined #vcwg
15:19:50 <SintayewGashaw> SintayewGashaw has joined #vcwg
15:20:16 <gkellogg> gkellogg has joined #vcwg
15:47:20 <gkellogg> gkellogg has joined #vcwg
15:57:29 <ivan> present+
15:58:26 <TallTed> present+
15:58:26 <TallTed> RRSAgent, draft minutes
15:58:27 <RRSAgent> I have made the request to generate https://www.w3.org/2023/11/29-vcwg-minutes.html TallTed
15:58:35 <TallTed> RRSAgent, make logs public
15:59:30 <ivan> present+ TallTed
15:59:47 <GregB> GregB has joined #vcwg
15:59:58 <GregB> present+
16:00:04 <brent> brent has joined #vcwg
16:00:10 <brent> present+
16:00:20 <pdl-asu> pdl-asu has joined #vcwg
16:00:25 <pdl-asu> present+
16:00:33 <ivan> present+ dmitriz
16:00:48 <manu> present+
16:00:49 <ivan> present+ pauld
16:01:07 <ivan> present+ selfissued
16:01:24 <ivan> present+ dlongley
16:02:12 <andres> andres has joined #vcwg
16:02:16 <andres> present+
16:02:29 <pdl-asu> scribe +
16:02:48 <ivan> present+ orie
16:02:49 <pauld_gs1> pauld_gs1 has joined #vcwg
16:02:49 <selfissued> selfissued has joined #vcwg
16:02:52 <pauld_gs1> present+
16:02:53 <Orie> Orie has joined #vcwg
16:02:53 <selfissued> present+
16:02:54 <manu> scribe+ pdl-asu
16:02:58 <Orie> present+
16:03:18 <will> will has joined #vcwg
16:03:19 <will> present+
16:03:23 <pdl-asu> ... brief agenda review (Brent) - work item status updates and PRs needing reviews.
16:03:43 <pdl-asu> ... bulk of time on item 1338 to address concerns raised by Google.
16:03:51 <manu> q+
16:03:54 <pdl-asu> ... additions or changes?
16:03:57 <brent> ack manu
16:04:25 <ivan> present+ JoeAndrieu
16:04:27 <pdl-asu> ... Manu - time to discuss Tony's questions to the mailing list to understand what things need to be in for CR?
16:04:32 <ivan> present+ seabass
16:04:37 <ivan> present+ bigbluehat
16:04:51 <pdl-asu> ... intros or re-intros?
16:05:11 <brent> Topic: CR proposal timing
16:05:51 <pdl-asu> ... brent - currently exists a draft of core data model as per CR, only changes anticipated are issues labelled before CR
16:06:09 <pdl-asu> s/cr/pr
16:06:11 <manu> Links to the current documents: https://lists.w3.org/Archives/Public/public-vc-wg/2023Nov/0020.html
16:06:29 <JoeAndrieu> JoeAndrieu has joined #vcwg
16:06:41 <JoeAndrieu> present+
16:07:07 <pdl-asu> ... in a week or so submit proposal to the group saying going into CR with these pull requests.
16:07:28 <selfissued> q+
16:07:30 <pdl-asu> ... an objection was raised saying a final version is ready for review before a proposal is made. What does the group think?
16:07:53 <brent> ack selfissued
16:07:57 <pdl-asu> ... go forward with all things done or with those in modulo and then CR?
16:08:39 <manu> q+ to talk about the repercussions of waiting.
16:08:47 <brent> q+ to talk timing benefits
16:08:51 <brent> ack manu
16:08:51 <Zakim> manu, you wanted to talk about the repercussions of waiting.
16:09:01 <Orie> I think its fine to signal intended timeline, but I agree its better to formally approve CR after changes have landed.
16:09:01 <pdl-asu> ...  selfissued no advantage saying going to CR with changes.  Should get all the changes in before going to CR
16:09:57 <pdl-asu> ... Manu - in the past we've said what we'd go into CR with the remaining items to be resolved. If we await on final version this year we won't be done.
16:10:09 <ivan> q+
16:10:11 <brent> ack brent
16:10:11 <Zakim> brent, you wanted to talk timing benefits
16:10:12 <selfissued> q+
16:10:40 <pdl-asu> ... brent  - the sooner we have a resolution to go to CR that's when we get things rolling.
16:11:07 <pdl-asu> .... are timing benefits to craft the proposal with the timing benefits
16:11:14 <brent> ack ivan
16:11:39 <selfissued> What is W3M?
16:12:09 <pdl-asu> ivan - staff contact hat, we go to W3M with everything done. No one will look at the doc  until things are finalized
16:12:30 <pdl-asu> ... how much time will it take to get to final resolution is the issue. Really no difference in the two approaches
16:12:35 <brent> ack selfissued
16:13:19 <pdl-asu> selfissued - Ivan said what needed to be said. Getting it right is more important. The schedule can be addressed later
16:13:21 <andres> +1 to what Mike said
16:13:42 <brent> Topic: Work Item status updates/PRs
16:13:44 <manu> q+
16:13:44 <selfissued> q+
16:13:50 <pdl-asu> brent - editors jump on the queue for status updates
16:13:57 <brent> ack manu
16:14:08 <pdl-asu> manu - will go through VCDM today
16:14:16 <pdl-asu> brent - only one todya
16:14:28 <ivan> s/todya/today/
16:14:44 <pdl-asu> manu - 1302 and 1320 and 1333 waiting for feedback
16:15:16 <pdl-asu> ... vc bitstring status list has been made. As soon as we go to CR things will go into the bitstring status list
16:15:35 <pdl-asu> * thanks Ivan
16:15:38 <Orie> PRs that need reviews:
16:15:41 <Orie> https://github.com/w3c/vc-data-model/pull/1302
16:15:45 <Orie> https://github.com/w3c/vc-data-model/pull/1320
16:15:48 <Orie> https://github.com/w3c/vc-data-model/pull/1333
16:15:49 <brent> ack selfissued
16:16:13 <selfissued> https://github.com/w3c/vc-jose-cose/pull/186
16:16:42 <pdl-asu> selfissued:  issue 186 about removing uses of multiple suffixes which is more controversial than expected.
16:16:54 <GregB> q+
16:17:16 <Orie> q+ to note that even if it goes through, our use of it could be questionable
16:17:25 <manu> q+
16:17:27 <gkellogg> gkellogg has joined #vcwg
16:17:30 <manu> q+ to agree with selfissued
16:17:31 <pdl-asu> selfissued: fine with waiting for IETF  and flag it at risk for VCDM and VC Jose/Cose best to leave things alone.
16:17:45 <Orie> https://github.com/w3c/vc-jose-cose/pull/186
16:17:49 <brent> ack GregB
16:17:56 <Orie> q-
16:18:30 <pdl-asu> GregB: VC BBS - only a few mods needed. Things in good shape. PR put in for security considerations
16:19:07 <pdl-asu> GregB: working on privacy because it just got updated in IETF and want good advice about data linkage and unlinkability
16:19:25 <pdl-asu> Greg: a lot of this about state of things can make at higher layers
16:19:43 <pdl-asu> s/state of this/mistakes
16:20:02 <pdl-asu> s/Greg/GregB/
16:20:04 <brent> ack manu
16:20:04 <Zakim> manu, you wanted to agree with selfissued
16:20:29 <pdl-asu> manu: agree with Mike, permature to remove multiple suffices. Or should discuss PR in more depth.
16:20:33 <ivan> q+
16:20:34 <identitywoman> identitywoman has joined #vcwg
16:20:40 <identitywoman> present+
16:20:45 <brent> ack ivan
16:21:09 <manu> q+ to note it's not normative.
16:21:27 <pdl-asu> ivan: worth flagging is issue 1338 makes reference which is normative to spec document. If we go to CR that doc should be published as official doc
16:21:27 <manu> q+ to note reference isn't normative (or shouldn't be)
16:21:31 <manu> q-
16:21:46 <brent> q?
16:21:47 <pdl-asu> ivan: should start the procedure to get that published.
16:21:56 <brent> Topic: Addressing Google's concerns
16:22:03 <manu> q+
16:22:11 <brent> https://github.com/w3c/vc-data-model/pull/1338
16:22:13 <manu> q+ to provide some background on this PR.
16:22:35 <pdl-asu> brent: have PR in place w/ sum review with some requested changes. Goal today is consensus to this PR
16:22:37 <brent> ack manu
16:22:37 <Zakim> manu, you wanted to provide some background on this PR.
16:23:20 <pdl-asu> manu: Jeffery A gave a comprehensive reivew. Pointed out things needed to be addressed
16:23:34 <pdl-asu> manu: if we don't define verification algorithm Google will formally object.
16:23:59 <ivan> s/Jeffery A/Jeffery Yasskin/
16:24:28 <pdl-asu> manu: this PR will define that algorithm and how you verify the securing mechanism,and how the doc should be secured to the securing specification
16:24:53 <pdl-asu> manu: at this point Jeffrey is happy with what's going in (no Google objection)
16:25:20 <pdl-asu> manu: some people felt some people we're defining an API, but here we're defining an algorithm
16:25:38 <pauld_gs1> can we add the PR # to the minutes?
16:25:42 <pdl-asu> manu: should use different language so it's clear we're not defining an API
16:25:55 <brent> PR is here: https://github.com/w3c/vc-data-model/pull/1338
16:26:04 <pdl-asu> manu: should address Google's issue, and anyone saying we're going beyond our charter
16:26:07 <selfissued> q+
16:26:18 <brent> ack selfissued
16:26:33 <pdl-asu> selfissued: part of this PR's problem is a layering violation.
16:26:50 <pdl-asu> selfissued: the data model should define the data model; the securing spec how to secure it.
16:27:10 <pdl-asu> selfissued: this PR should address this data model not the securing spec.
16:27:14 <brent> q?
16:27:21 <manu> q+ to request concrete changes
16:27:21 <Orie> +1 it is a layering violation, but its possible to accept it, if the algorithm can be made a pure function of the vocabulary terms, and not refer to the securing specs.
16:27:26 <brent> ack manu
16:27:26 <Zakim> manu, you wanted to request concrete changes
16:27:45 <DavidC> DavidC has joined #vcwg
16:27:48 <pdl-asu> manu: not a layering violation.  But you need to specify what you want to see changed
16:27:50 <selfissued> q+
16:27:51 <DavidC> present+
16:28:16 <pdl-asu> manu: if we move the verification algorithm to the securing spec it will likely deviate.
16:28:37 <JoeAndrieu> q+ to ask about status checks
16:28:39 <pdl-asu> manu: securing mechanism checks are properly layered to put the details of the securing mechanism are pushed off to the securing spec.
16:28:56 <pdl-asu> manu: if there are mistakes in the securing spec we should fix that.
16:29:00 <brent> ack selfissued
16:29:33 <pdl-asu> selfissued: in the midst to doing that. Data integrity references need to be excised. Within my rights to say this needs to be closed .
16:29:52 <Orie> q+
16:29:54 <pdl-asu> brent: are you asking for it to be closed?
16:30:17 <manu> q+ to clarify what's happening in the PR.
16:30:31 <brent> ack JoeAndrieu
16:30:31 <Zakim> JoeAndrieu, you wanted to ask about status checks
16:30:34 <pdl-asu> selfissued: no, I'm asking for some things be excised. How to verify securing should be in the secruing specs, not here.
16:30:42 <manu> q+ to clarify what Mike's asking for is exactly what the PR does -- how to verify securing is in the securing specifications.
16:30:54 <pdl-asu> joeAndreiu: confused about where status checks should be placed.
16:31:00 <Orie> status checks are validation, that happens after verification.
16:31:10 <manu> what Orie said ^
16:31:17 <manu> Status checks are validation, not verification.
16:31:27 <pdl-asu> selfissued: don't know what you mean by status check
16:31:31 <DavidC> status checking is part of verification, not validation
16:31:39 <Orie> `credentialStatus` is the property in the data model.
16:31:54 <andres> ^^
16:31:57 <pdl-asu> JoeAndreiue: we check the authenticity and currency (revocation). That should come back so you know what that is.
16:32:00 <brent> ack Orie
16:32:24 <pdl-asu> Orie: part of the problem, if you're getting a true/false from the verify algorithm.
16:32:48 <pdl-asu> Orie: a version of this text could make it through but layering pieces need to be adjusted.
16:33:15 <pdl-asu> Orie: trying to summarize abstract activity after the verification has succeeded
16:34:00 <JoeAndrieu> q+ to say I think the disconnect is that "verify" is not just checking the securing mechanism. it's also checking status. The semantics are "this issuer said this thing *and still stands by it*"
16:34:10 <pdl-asu> Orie: you might check a number of attributes of statuses, but describing all of that as a verification result we need to restate the terminology to insure the terms are used in the same way.
16:35:15 <pdl-asu> Orie: e.g., the concept of the validity of the credential is ambiguous. The data integrity proof or JWT? Could be both or one or the other but not both.
16:35:20 <dmitriz> q+
16:35:53 <selfissued> q+
16:35:53 <dmitriz> q-
16:35:54 <JoeAndrieu> s/JoeAndreiue/JoeAndrieu
16:35:55 <pdl-asu> Orie: what's a verifiable credential vs just a credential but we didn't resolve that. Likely have to reopen that to clarify it
16:36:17 <dlongley> ... or you just say which securing mechanism you accept before you run the verification check.
16:36:23 <brent> ack manu
16:36:23 <Zakim> manu, you wanted to clarify what's happening in the PR. and to clarify what Mike's asking for is exactly what the PR does -- how to verify securing is in the securing
16:36:26 <Zakim> ... specifications.
16:37:05 <pdl-asu> manu: don't think it's that complicated. Mike asked defer the detail about the securing mechanism. The PR is doing that.
16:37:13 <Orie> is the algorithm to check the status concrete?
16:37:30 <Orie> is the algorithm to check the schema concrete?
16:37:41 <pdl-asu> manu: the only thing where other specs are referenced is that the securing spec properly protects the payloads, and defer to the securing mechanisms for details.
16:37:53 <Orie> is the algorithm to check the validity period concrete?
16:38:22 <DavidC> q+
16:38:34 <pdl-asu> manu: JoeAndreiu's point about status list checking, there are two things we could do. Say that's validation. Status checking is validation
16:38:35 <pauld_gs1> +1 status checking is validation, not verification.
16:38:36 <Orie> checking for "conforming documents" is validation....
16:38:47 <Orie> that is the problem.
16:38:47 <pdl-asu> manu: verification is the integrity of the data, the digital signature check.
16:39:19 <pdl-asu> manu: other options make the verification more complex.
16:39:25 <brent> ack JoeAndrieu
16:39:25 <Zakim> JoeAndrieu, you wanted to say I think the disconnect is that "verify" is not just checking the securing mechanism. it's also checking status. The semantics are "this issuer said
16:39:26 <Orie> data integrity DOES validation during verification... thats part of its design.
16:39:28 <Zakim> ... this thing *and still stands by it*"
16:39:43 <Orie> +1 joeandrieu
16:39:49 <andres> +1 to joeandrieu
16:40:10 <pdl-asu> JoeAnrieu: securing mechanism has become verification. Revocation is about the issuer no longer stands by the statement for many reasons
16:40:11 <pauld_gs1> q+
16:40:35 <brent> ack selfissued
16:40:42 <dmitriz> agree that _Revocation_ specifically is part of verification. But not expiry -- that part should be in validation. (since it's verifier-specific)
16:40:48 <pdl-asu> JoeAndrieu: is this thing what the issuer intended it to be
16:41:07 <pauld_gs1> q-
16:41:11 <pdl-asu> selfissued: failing to distinguish between credential and verified credential is causing us problem.
16:41:34 <pdl-asu> selfissued: all the language about proof should be in data integrity not in the data model.
16:41:39 <manu> q+ to note the PR to clarify what makes a "verifiable credential" went in.
16:41:47 <brent> ack DavidC
16:42:40 <pdl-asu> DavidC: if someone steals a signing key it can't be considered verifiable. It's got to be a part of verification. That has to include status and revocation checking. After that you can check the dates and do validation.
16:42:44 <brent> ack manu
16:42:44 <Zakim> manu, you wanted to note the PR to clarify what makes a "verifiable credential" went in.
16:42:47 <seabass> q+
16:43:11 <Orie> +1 manu, it seems orthogonal.
16:43:12 <DavidC> q+
16:43:24 <pdl-asu> manu: if someone steals a key they can forge the revocation list. Doesn't address the problem.  We have what a verifiable credential is is defined in the document.
16:43:24 <seabass> q-
16:43:25 <Orie> -1 to saying we addressed `proof` fully... we did merge 1 PR.
16:43:32 <seabass> q+
16:43:52 <DavidC> the key for the revocation list should not be the same as the key for the verifiable credential
16:43:55 <JoeAndrieu> q+ to separate securing algorithm from verification algorithm
16:43:58 <pdl-asu> manu: two things to discuss. Is status checking a part of the algorithnm, but manu is -1 to it but won't formally object.
16:44:06 <brent> ack DavidC
16:44:06 <Orie> I am also -1 to doing mixing validation and verification... and I am -1000 to doing expensive validation before verification.
16:44:12 <pdl-asu> manu: the other issue is getting concrete changes adjusted.
16:44:39 <dlongley> if someone steals the revocation list signing key (if it's different) and revokes VCs that the issuer wouldn't have revoked
16:44:41 <manu> q+ to note that revocation lists are often issued by the issuer and use the same key.
16:44:46 <pauld_gs1> q+
16:44:48 <pdl-asu> DavidC: doesn't agree with manu. The key for signing the credential and the revocation list should be separate.
16:44:58 <brent> ack seabass
16:45:18 <pdl-asu> seabass: there are multiple use cases. You want to confirm something is a true statement.
16:45:41 <dmitriz> expired - yes. revoked - no
16:45:47 <pdl-asu> seabass: plenty of cases where people want to use old expired credentials as they still have value.
16:45:51 <brent> ack JoeAndrieu
16:45:51 <Zakim> JoeAndrieu, you wanted to separate securing algorithm from verification algorithm
16:46:03 <brent> q+ to ask next steps
16:46:11 <gkellogg> gkellogg has joined #vcwg
16:46:19 <manu> q+ to note that securing algorithm /is/ separated from verification algorithm.
16:46:22 <pdl-asu> JoeAndrieu: seabass's point can be addressed by making the verification is not just binary.
16:46:44 <pdl-asu> JoeAndrieu: need to define the securing algorithm separately from the verification algorithm.
16:47:06 <seabass> q+
16:47:08 <brent> ack manu
16:47:08 <Zakim> manu, you wanted to note that revocation lists are often issued by the issuer and use the same key. and to note that securing algorithm /is/ separated from verification algorithm.
16:47:49 <pdl-asu> manu: Revocation lists typically use the same key as the revocation lists but it's orthogonal to this discussion.
16:48:53 <JoeAndrieu> q+ to say yes, that precludes checking the credentialStatus
16:49:14 <pdl-asu> manu: the algorithm is broken up as JoeAndreiu has asked. The algorith has a top level verificaiton, to sublevel algorithm to check the securing mechanism and one that checks the conformance of the document
16:49:27 <brent> ack pauld_gs1
16:49:27 <pdl-asu> s/to/two/
16:49:30 <brent> ack pauld_gs
16:49:36 <dlongley> maybe the verification algorithm should just say, after checking conformance and integrity ... that credential status checks and other checks can be run thereafter.
16:49:55 <DavidC> q+
16:49:57 <brent> ack brent
16:49:57 <Zakim> brent, you wanted to ask next steps
16:50:01 <manu> q+ to suggest next steps
16:50:11 <Orie> credential status lists are verifiable credentials, they are constrained by this proposed text.
16:50:13 <pdl-asu> pauld_gsu: credential status has to live in the verification spec
16:50:36 <brent> ack seabass
16:50:43 <pdl-asu> brent: moving in the right direction, but what's beyond concrete change suggestions are the next step
16:50:57 <pauld_gs1> I meant that credential status verification has to be handled by the specification that defines the credential status, NOT the core data mode.
16:51:10 <pdl-asu> seabass: consider an airline flight. You have a ticket that's a VC issued by the airline.
16:51:45 <dmitriz> that's mixing "one time use" with revocation mechanism
16:51:49 <dmitriz> those are separate
16:52:10 <dmitriz> and again, we're talking about revocation, not expiry
16:52:11 <pdl-asu> seabass: the airline has a lounge you can use at the airline. You use the ticket and the destination airport lounge wants to see that you had a valid ticket, but it's no longer valid.
16:52:14 <brent> ack JoeAndrieu
16:52:14 <Zakim> JoeAndrieu, you wanted to say yes, that precludes checking the credentialStatus
16:52:19 <TallTed> +1 dmitriz
16:52:36 <Orie> I meant that the TR track item this WG is developing is VCs, agree joe
16:52:37 <DavidC> the airline ticket case is that the ticket is no longer verifiable, but validation by the lounge overrules this and accepts the expired credential
16:52:54 <pdl-asu> JoeAndreiu: status lists need not be VCs. Appreciate manu's clarificaiton wasn't a part of checking the status list as a part of this algorithm.
16:53:02 <andres> Agree that we should add checking status list in the algorithm. Where the definition is external to the spec.
16:53:04 <brent> ack DavidC
16:53:09 <TallTed> (I would not expect airlines, concert venues, etc., to revoke tickets upon use/redemption.)
16:53:10 <dmitriz> @DavidC -- not quite. the ticket is STILL verifiable. but not reusable
16:53:17 <JoeAndrieu> s/JoeAndreiu/JoeAndrieu
16:53:20 <pdl-asu> JoeAndrieu: should have how you check status list as a part of this algorithm
16:53:43 <manu> q+ to note revocation lists can be provided out of band. :)
16:53:48 <brent> ack manu
16:53:48 <Zakim> manu, you wanted to suggest next steps and to note revocation lists can be provided out of band. :)
16:53:49 <Orie> So verification is external, and status checks are external.... so this "verification algorithm" just combines external calls? seems like it might be possible to land this, if we can clarify how proof is handled.
16:53:52 <pdl-asu> DavidC: The issuer can still issue a revocation list to say everything is revoked from now on.
16:53:54 <pauld_gs1> q+
16:54:13 <pauld_gs1> q-
16:54:20 <pdl-asu> manu: can be provided out of band, again it's orthogonal. Re: next steps. Create a PR as a status check mechanism
16:54:32 <JoeAndrieu> +1 to a separate PR for separate discussion
16:54:35 <pdl-asu> manu: if that goes well it can be merge into the verification PR.
16:54:35 <Orie> -1 to seperate PRs, this is hard enough to understand as is
16:54:42 <Orie> lets address `proof` first
16:54:45 <pdl-asu> manu: waiting for concrete suggestions, as well.
16:55:09 <ivan> q+
16:55:13 <manu> It's not clear what you're asking for, Orie ^
16:55:21 <pdl-asu> brent: hopefully the feedback from today is helpful.
16:55:22 <brent> ack ivan
16:55:36 <Orie> q_+
16:55:40 <Orie> q+
16:55:44 <pdl-asu> ivan: see's Orie's comment that proof should be addressed first.
16:56:20 <pdl-asu> Orie: early days of the working group credential was without a proof and a verifiable credential has a proof
16:57:03 <ivan> q+
16:57:06 <pdl-asu> Orie: the verification algorithm is taking an abstract credential and in the case of data integrity it does not contain a proof. Yes in the case of JOSE/COSE.
16:57:21 <ivan> ack Orie
16:58:07 <pdl-asu> Orie: is the verification done in the spec or not?  If it was only data integrity. If we have other securing spec, the current term defs regarding proofs are problematic, and after this PR worse.
16:58:41 <pdl-asu> s/data integrity/date integrity, yes/
16:58:41 <brent> ack ivan
16:58:52 <manu> It's not clear what Orie wants to have changed w/ `proof` in the spec... I don't have enough to write a PR.
16:59:12 <manu> I can guess, but I don't want to do that.
16:59:52 <Orie> Manu, a PR that removed `proof` from the core data model, and left it defined in data integrity, and referred to it would be acceptable.
16:59:54 <pdl-asu> Ivan: the proof property defines the proof in the data integrity spec and referred to from the DM spec. It's not defined in both places.
16:59:57 <Orie> +1 ivan
17:00:03 <DavidC> We should add a status sub process to the verification algorithm
17:00:29 <ivan> rrsagent, draft minutes
17:00:31 <RRSAgent> I have made the request to generate https://www.w3.org/2023/11/29-vcwg-minutes.html ivan
17:00:37 <gkellogg> gkellogg has joined #vcwg
17:00:37 <manu> Ok, that's clear, thanks Orie -- -1 to raising a PR that does that.. I can try another PR that makes it clear that proof is an extension mechanism.
17:00:39 <pdl-asu>  brent: trying to get to candidate rec by mid-Dec
17:00:43 <manu> and that DI uses that extension mechanism in a specific way.
17:00:57 <ivan> rrsagent, draft minutes
17:00:58 <RRSAgent> I have made the request to generate https://www.w3.org/2023/11/29-vcwg-minutes.html ivan
17:01:05 <pdl-asu> Anything else you need from me (the note taker today)?
17:01:20 <ivan> no, pdl-asu , the rest is my job
17:01:22 <ivan> thanks
17:01:32 <pdl-asu> you're welcome.
17:02:10 <ivan> rrsagent, bye
17:02:10 <RRSAgent> I see no action items
17:02:10 <ivan> zakim, bye
17:02:10 <Zakim> leaving.  As of this point the attendees have been ivan, TallTed, GregB, brent, pdl-asu, dmitriz, manu, pauld, selfissued, dlongley, andres, orie, pauld_gs, will, JoeAndrieu,
17:02:10 <Zakim> Zakim has left #vcwg
17:02:11 <Zakim> ... seabass, bigbluehat, identitywoman, DavidC