15:44:27 <RRSAgent> RRSAgent has joined #vcwg
15:44:31 <RRSAgent> logging to https://www.w3.org/2024/03/06-vcwg-irc
15:44:31 <Zakim> RRSAgent, make logs Public
15:44:32 <Zakim> please title this meeting ("meeting: ..."), ivan
15:45:15 <ivan> Meeting: Verifiable Credentials Working Group Telco
15:45:15 <ivan> Date: 2024-03-06
15:45:15 <ivan> Agenda: https://www.w3.org/events/meetings/3c7f5c66-5e34-468a-837e-2c2bf12de748/20240306T110000/
15:45:15 <ivan> chair: brent
15:45:15 <ivan> ivan has changed the topic to: Meeting Agenda 2024-03-06: https://www.w3.org/events/meetings/3c7f5c66-5e34-468a-837e-2c2bf12de748/20240306T110000/
15:54:42 <brent> brent has joined #vcwg
15:58:28 <ivan> present+
15:59:56 <ivan> present+ brent
16:00:13 <ivan> present+ TallTed
16:01:47 <ivan> present+ jennie, pauld, bigbluehat, dlongley
16:01:57 <gkellogg> gkellogg has joined #vcwg
16:01:59 <ivan> present+ manu
16:02:20 <ivan> present+ dmitriz
16:02:27 <bigbluehat> bigbluehat has joined #vcwg
16:03:31 <pauld_gs1> pauld_gs1 has joined #vcwg
16:03:33 <bigbluehat> present+
16:03:46 <manu> present+
16:03:51 <bigbluehat> scribe: bigbluehat
16:03:58 <JoeAndrieu> JoeAndrieu has joined #vcwg
16:04:02 <JoeAndrieu> present+
16:04:08 <ivan> present+ jandrieu
16:04:33 <bigbluehat> brent: Welccome. The agenda is straightforward. Status updates, pull requests, and then issues on the core data model.
16:04:35 <manu> q+
16:04:42 <brent> ack manu
16:04:44 <bigbluehat> ... anyone have changes or additions?
16:05:03 <bigbluehat> manu: just 2 announcements about upcoming maintenance deadlines
16:05:17 <bigbluehat> ... as folks know, we made a call for DID and VC registries
16:05:18 <manu> Volunteer list is here: https://lists.w3.org/Archives/Public/public-vc-wg/2024Mar/0005.html
16:05:42 <bigbluehat> ... we need volunteers, and did a training video, collected github handles, etc.
16:05:44 <ivan> present+ selfissued
16:05:55 <bigbluehat> ... these folks are all more than qualified to maintain the registries
16:06:02 <bigbluehat> ... and they've mostly signed up for both
16:06:16 <bigbluehat> ... we sent an email out to get confirmation from the group on the list of volunteers
16:06:24 <ivan> s/Welccome/Welcome/
16:06:28 <bigbluehat> ... next Tuesday is the deadline to object
16:06:46 <brent> Topic: Work Item Status Updates/PRs
16:06:50 <bigbluehat> brent: any comments on volunteering?
16:06:52 <manu> q+
16:06:57 <decentralgabe> decentralgabe has joined #vcwg
16:07:02 <bigbluehat> ... k. status updates. Please queue up if you have updates
16:07:03 <brent> ack manu
16:07:25 <decentralgabe> present+
16:07:33 <bigbluehat> manu: for Data Integrity, all the specs are aligned with Jeffrey Yaskins cryptosuite interface proposal
16:07:44 <bigbluehat> ... it was a major change, so we need to go through another CR
16:07:51 <bigbluehat> ... no negative feedback from implementers
16:08:18 <ivan> s/Yaskins/Yaskin's/
16:08:20 <bigbluehat> ... for BBS, we can go into CR by next week (in theory)
16:08:22 <manu> https://github.com/w3c/vc-di-bbs/
16:08:32 <bigbluehat> ... Greg still has some pending PRs
16:08:46 <bigbluehat> ... once those are in we'll cut a pre-CR and do a call for consensus
16:09:10 <bigbluehat> ... ivan, I don't know what the timing would be. This is just a heads up that this is nearly ready for a vote.
16:09:17 <manu> https://github.com/w3c/vc-bitstring-status-list/issues?q=is%3Aissue+is%3Aopen+label%3Abefore-CR
16:09:26 <ivan> q+ to talk about CR timing
16:09:34 <przemek> przemek has joined #vcwg
16:09:39 <bigbluehat> ... Bitstring Status List can be ready for a vote to got into CR early next month
16:09:53 <ivan> present+ przemek
16:09:54 <bigbluehat> ... we have asked PING to review prior to CR...still waiting on confirmation
16:10:12 <bigbluehat> ... we have had reviews done and other reviews will timeout in mid-April
16:10:25 <bigbluehat> ... the big thing we need is what the Traceability group is doing with status list
16:10:40 <bigbluehat> ... but we need more engagement specifically from Transmute and Mesur
16:11:02 <bigbluehat> ... we have a plan for what we can do with it, but we need implementer feedback from the Traceability cohort
16:11:27 <bigbluehat> ... the VCDM has a few changes related to requests from the Activity Pub folks
16:11:35 <bigbluehat> ... but the standing issues seem to be nearly resolved
16:11:51 <bigbluehat> ... there's a normative change about "enveloped" Verifiable Presentations
16:12:15 <bigbluehat> ... just to be clear, the VCDM can now carry _any_ payload of _any_ media type
16:12:30 <bigbluehat> ... which means it could hold other forms of credentials, mDoc, etc.
16:12:43 <bigbluehat> ... there's a clear story around how this can be done
16:13:02 <bigbluehat> ... I think this achieves the "big tent" approach we've been aiming at
16:13:12 <bigbluehat> ... the rest of everything seems to be editorial
16:13:13 <selfissued> selfissued has joined #vcwg
16:13:15 <selfissued> present+
16:13:23 <bigbluehat> ... what we're targeting is a May timeframe for VCDM
16:13:30 <bigbluehat> ... and we may be able to push it up a bit
16:13:33 <brent> ack ivan
16:13:33 <Zakim> ivan, you wanted to talk about CR timing
16:13:37 <bigbluehat> brent: ivan?
16:13:47 <bigbluehat> ivan: do we want to talk about CR timing now?
16:13:51 <bigbluehat> brent: now's good
16:14:24 <bigbluehat> ivan: for the March date, we have to take into consideration that the timing lines up with Good Friday, which means one of our reviewers will be on vacation
16:14:45 <bigbluehat> ... and the 5th of April is a publication moratorium due to the AC meeting in Japan
16:15:09 <manu> q+ to discuss CR timing windows... shoot for beginning of week of 18th.
16:15:15 <bigbluehat> ... so if we can't get this request in by next week or the beginning of the week of the  18th, then it won't happen in March
16:15:37 <bigbluehat> ... additional difficulty is that from March 22-?? I will be out of town
16:15:40 <brent> ack manu
16:15:40 <Zakim> manu, you wanted to discuss CR timing windows... shoot for beginning of week of 18th.
16:15:50 <ivan> s/??/26/
16:15:56 <bigbluehat> manu: sounds like we should shoot for the 18th of March
16:16:11 <bigbluehat> ivan: when would the WG get together? the 13th? next week?
16:16:34 <bigbluehat> manu: I can check with Greg to see if he has anything else that needs to go in
16:16:34 <gkellogg> gkellogg has joined #vcwg
16:16:43 <bigbluehat> ... otherwise, I think we can do it by next week
16:16:57 <bigbluehat> ... it's all stuff that's already in the spec, just some of it will become normative
16:17:07 <bigbluehat> ... most of it has been there for weeks or even months
16:17:16 <bigbluehat> ... we can set the publication for the 21st
16:17:54 <bigbluehat> ivan: I admire your optimism. If we vote on the 13th, we'd need an approval by the 15th--2 days later--and that seems unlikely
16:18:00 <bigbluehat> manu: when's the better day?
16:18:07 <bigbluehat> ivan: the 26th or the 28th
16:18:16 <bigbluehat> manu: 28th? would that work?
16:18:29 <bigbluehat> ... that would be for BBS or JOSE/COSE? or both?
16:18:46 <bigbluehat> ivan: the difference between one or two is marginal, so having both together would be best
16:18:59 <bigbluehat> manu: I'll work with Greg to prep for a vote on the 13th
16:19:07 <bigbluehat> ... we'll target a publication date of the 28th
16:19:27 <bigbluehat> brent: Gabe or Mike Jones, any updates on JOSE/COSE
16:19:33 <bigbluehat> selfissued: we have no open PRs
16:19:35 <selfissued> https://github.com/w3c/vc-jose-cose/issues/206
16:19:38 <bigbluehat> ... but we do have some issues
16:19:53 <brent> subtopic: https://github.com/w3c/vc-jose-cose/issues/206
16:19:57 <bigbluehat> ... 206 is about the verification algorithm
16:20:01 <manu> q+
16:20:11 <brent> ack manu
16:20:19 <bigbluehat> ... but manu's already mentioned that all the specs are doing the right thing in terms of algorithm
16:20:35 <bigbluehat> manu: I wasn't referring to JOSE/COSE, just the Data Integrity specs
16:20:50 <ivan> q+
16:20:56 <bigbluehat> ... I think the editors of JOSE/COSE should figure out if the new interfaces apply for create and verify
16:21:13 <bigbluehat> ... I'm checking to see what Jeffrey wrote about this earlier
16:21:22 <manu> https://w3c.github.io/vc-data-model/#securing-mechanism-specifications
16:21:33 <bigbluehat> ... section 5.13 securing mechanism specifications
16:21:46 <ivan> q-
16:21:55 <bigbluehat> ... I don't know if the VC JOSE/COSE spec does the things that section requires
16:22:08 <decentralgabe> q+
16:22:14 <bigbluehat> ... it must provide a verification method that only contains the data in the document
16:22:40 <bigbluehat> ... there are a bunch of other requirements for embedded proofs
16:22:51 <bigbluehat> ... but no real requirements for enveloping proofs
16:23:02 <bigbluehat> ... it's up to the editors to decide if they've hit that bar
16:23:10 <bigbluehat> ... and the group to agree or not
16:23:17 <brent> ack decentralgabe
16:23:18 <bigbluehat> selfissued: brent, this is assigned to you, do you want to keep it
16:23:28 <bigbluehat> brent: yes. I'll keep it
16:23:39 <bigbluehat> decentralgabe: we have a section on this, but the rendering is broken
16:23:43 <manu> q+
16:23:45 <bigbluehat> brent: I'll look at that as welll
16:23:52 <brent> ack manu
16:24:14 <bigbluehat> manu: there's a bulleted list in the issue I made. I've not seen responses
16:24:39 <bigbluehat> ... I'll not block this going into CR, but without these changes it's likely to get formally rejected
16:25:17 <bigbluehat> ... so, going through the list and explaining how they're addressed should help avoid the formal objection and close that issue
16:25:26 <bigbluehat> selfissued: you mean the one from December?
16:25:28 <bigbluehat> manu: yes.
16:25:33 <bigbluehat> brent: I'll tackle this
16:25:50 <bigbluehat> ... anything else about JOSE/COSE?
16:25:57 <bigbluehat> selfissued: decentralgabe has the other issues
16:26:02 <bigbluehat> decentralgabe: I plan to do both this week
16:26:20 <selfissued> The three vc-jose-cose before-CR issues are https://github.com/w3c/vc-jose-cose/issues?q=is%3Aissue+is%3Aopen+label%3Abefore-CR
16:26:29 <bigbluehat> brent: if all three of these are addressed with PRs, it's theoretically possible we could vote next week...but that seems really tight
16:26:45 <bigbluehat> selfissued: no opinion on timing, ivan's the expert
16:26:52 <brent> Topic: VCDM Issue Processing
16:27:00 <brent> https://github.com/w3c/vc-data-model/issues?q=is%3Aissue+is%3Aopen+-label%3Afuture+sort%3Aupdated-asc
16:27:16 <bigbluehat> brent: 1437 is our first one
16:27:34 <brent> subtopic: https://github.com/w3c/vc-data-model/issues/1442
16:27:41 <bigbluehat> ... oh, this is before TR, so we'll skip it for now
16:27:52 <bigbluehat> brent: 1442 is assigned to ivan
16:27:53 <brent> s/TR/PR/
16:28:09 <manu> q+
16:28:15 <brent> ack manu
16:28:21 <bigbluehat> manu: just to provide some input
16:28:32 <bigbluehat> ... ivan asked about posting the canonical hash
16:28:53 <bigbluehat> ... what we want is for people to retrieve something from the Web, and pass it through a library to get the hash
16:29:13 <bigbluehat> ... telling people to have something special on hand to tell if the doc is valid is not what we want
16:29:28 <bigbluehat> ... using a format they can read, SHA it, and compare would be better
16:29:48 <bigbluehat> ... we could add hashes for every serialization, but that feels like a bit much
16:30:11 <bigbluehat> ... we do want to update our ReSpec extension to generate these hashes at publication time
16:30:39 <bigbluehat> ivan: it was already clear back then that the hash is the representation of the JSON-LD of the vocabulary
16:30:44 <bigbluehat> manu: yes
16:30:45 <manu> q+
16:30:56 <bigbluehat> ivan: depending on conneg, you may get other formats
16:31:15 <brent> ack manu
16:31:19 <bigbluehat> ... it's not clear enough that the hash is specifically for the `application/ld+json` representation
16:31:30 <bigbluehat> manu: I thought we had examples of how to recreate the hashes
16:31:42 <bigbluehat> ivan: it's there, but it's still not clear
16:31:51 <bigbluehat> ... make it clear. should only be a few words
16:31:59 <bigbluehat> brent: currently this is assigned to you, ivan
16:32:05 <bigbluehat> ivan: I can make a PR
16:32:21 <brent> subtopic: https://github.com/w3c/vc-data-model/issues/1197
16:32:24 <bigbluehat> manu: thank you ivan!
16:32:34 <bigbluehat> brent: moving on to 1197
16:32:40 <manu> q+
16:32:46 <brent> ack manu
16:32:48 <bigbluehat> ... Nick Steele agreed to do the work, but he's not been on the calls
16:32:52 <bigbluehat> manu: I can take this one
16:33:05 <bigbluehat> brent: need any clarity from the group?
16:33:12 <bigbluehat> manu: nope. pretty straightforward
16:33:14 <brent> subtopic: https://github.com/w3c/vc-data-model/issues/1359
16:33:19 <bigbluehat> brent: 1359
16:33:28 <bigbluehat> ... decentralgabe this is assigned to you
16:33:46 <bigbluehat> decentralgabe: I still think it'd be helpful for this to be described in the spec
16:33:58 <manu> q+
16:34:06 <bigbluehat> ... when you're going to make a VP, how can you be sure that the entity presenting it is authorized to present it
16:34:09 <brent> ack manu
16:34:21 <bigbluehat> ... so we avoid anyone presenting it to anyone
16:34:37 <bigbluehat> manu: +1. I do think we can point to the confidence method spec
16:34:56 <bigbluehat> ... the only concern I have is that the spec hasn't been touched in awhile
16:35:03 <brent> q+
16:35:17 <bigbluehat> ... I do think we plan to revisit it in a future WG, but not sure we want to talk about it before then
16:35:43 <TallTed> having a VC property for "authorized presenters" seems a fine extension, but what to do with it feels like business logic
16:35:44 <decentralgabe> q+
16:35:47 <bigbluehat> ... we could talk about matching DIDs and comparing crypto related to those at each layer
16:36:07 <brent> ack brent
16:36:15 <bigbluehat> ... it's really when you want to connect it to a additional binding mechanisms that you'd want confidence method to come in
16:36:27 <bigbluehat> brent: a full treatment of this seems too much to handle right now
16:36:44 <manu> I agree with Brent's overall analysis. What can we do editorially for this?
16:36:53 <bigbluehat> ... what aspect of this would fit right now, is my question to decentralgabe
16:37:02 <TallTed> q+ to say having a VC property for "authorized presenters" seems a fine extension, but what to do with it feels like business logic
16:37:11 <brent> ack decentralgabe
16:37:17 <bigbluehat> ... we've got general interest in closing this, but we should narrow in on a specific recommendation
16:37:42 <bigbluehat> decentralgabe: I'd like to see non-normative text about it that could later be made normative
16:37:56 <bigbluehat> ... it would at least help nudge people toward the future
16:38:02 <bigbluehat> brent: is this something you can do?
16:38:09 <bigbluehat> decentralgabe: yes, but it's lower priority
16:38:20 <brent> ack TallTed
16:38:20 <Zakim> TallTed, you wanted to say having a VC property for "authorized presenters" seems a fine extension, but what to do with it feels like business logic
16:38:28 <bigbluehat> brent: I will note you assigned it to yourself in December, and it's still yours to do
16:38:42 <bigbluehat> TallTed: I'm still very unclear how this applies to who's presenting
16:39:01 <manu> I agree with Ted's analysis.
16:39:06 <decentralgabe> will attempt some language, looking forward to it being torn apart :)
16:39:09 <bigbluehat> ... it does feel reasonable to say "these are my authorized presenters", but how to enforce that feels like business logic to me
16:39:11 <TallTed> s/how this applies/how confidence method applies/
16:39:28 <bigbluehat> selfissued: how do you see this list interacting with proof of possession binding?
16:39:49 <bigbluehat> decentralgabe: that's one option, but there be situations where that's not present
16:39:57 <bigbluehat> selfissued: just wanted to note they were related
16:39:59 <brent> subtopic: https://github.com/w3c/vc-data-model/issues/1254
16:40:12 <bigbluehat> brent: 1254 is about complex language markup
16:40:16 <bigbluehat> ... this was pending close
16:40:35 <bigbluehat> ... we got a comment that if the title is adjusted, that would better apply or reflect the content
16:40:39 <manu> q+
16:40:43 <bigbluehat> ... sounds like a simple change
16:40:44 <brent> ack manu
16:40:47 <bigbluehat> manu: I'll take it
16:41:05 <bigbluehat> ... and just try to work with title, since Sebastien's no longer with us
16:41:19 <bigbluehat> ... I'll provide a PR and we can talk about it there
16:41:23 <brent> subtopic: https://github.com/w3c/vc-data-model/issues/1432
16:41:50 <bigbluehat> brent: 1432
16:42:05 <bigbluehat> ... this is assigned to decentralgabe. Do you need input?
16:42:21 <manu> q+
16:42:33 <ivan> q+
16:42:34 <manu> q+ pauld_gs1
16:42:35 <manu> q-
16:42:38 <brent> ack manu
16:42:42 <pauld_gs1> q+
16:42:44 <selfissued> q+
16:42:46 <dlongley> it might be a bad idea for "personal credentials" (credentials about people)
16:42:48 <bigbluehat> decentralgabe: could I state that public URLs for credentials is a Bad Thing, and suggest we recommend URNs would be better
16:43:06 <bigbluehat> manu: I think we should not do that, but state that it's nuanced
16:43:19 <bigbluehat> ... there are all sorts of credentials that should use the ID
16:43:36 <bigbluehat> ... and many that should not state an ID--when they're for private individuals, etc.
16:43:48 <ivan> q-
16:43:54 <bigbluehat> ... we may want to put this in the Privacy section--and it may already be covered
16:43:55 <dlongley> +1 to what the credential is about should be a strong consideration on what ID/what kinds of IDs you might use.
16:43:57 <decentralgabe> +1 Manu, understood
16:44:02 <brent> ack pauld_gs1
16:44:06 <brent> ack pauld_gs
16:44:18 <bigbluehat> pauld_gs1: we do use resolvable URIs for public credentials
16:45:00 <bigbluehat> ... if it's PII, then there are reasons not o
16:45:00 <bigbluehat> ... but there are certainly reasons to use public URIs
16:45:00 <brent> ack selfissued
16:45:00 <bigbluehat> ... and I do think it's already in the Privacy section
16:45:23 <bigbluehat> selfissued: there are cases where we use these, and without them key discovery breaks
16:45:28 <bigbluehat> brent: did that help?
16:45:43 <bigbluehat> decentralgabe: yes. I'll incorporate it into a PR
16:45:48 <brent> subtopic: https://github.com/w3c/vc-data-model/issues/1239
16:46:00 <bigbluehat> manu: yeah gopher!
16:46:15 <bigbluehat> brent: 1239...did we decide about this one? ivan ?
16:46:22 <bigbluehat> ivan: I proposed we delay this one
16:46:40 <bigbluehat> ... the transcript it inconclusive
16:46:55 <bigbluehat> brent: I think this one's OK to ignore for now
16:47:06 <bigbluehat> ... anyone object?
16:47:15 <brent> subtopic: https://github.com/w3c/vc-data-model/issues/1176
16:47:24 <bigbluehat> brent: 1176 define what credential validity means?
16:47:32 <bigbluehat> ... JoeAndrieu ?
16:47:42 <bigbluehat> JoeAndrieu: ...still need to get to it, sorry
16:48:02 <bigbluehat> brent: if there still isn't a PR in the next few weeks, we will need to close it
16:48:07 <brent> subtopic: https://github.com/w3c/vc-data-model/issues/1348
16:48:09 <bigbluehat> JoeAndrieu: understood
16:48:15 <bigbluehat> brent: 1348
16:48:31 <bigbluehat> manu: this ones mine. It'll take a few days, but I should be able to do it.
16:48:38 <brent> subtopic: https://github.com/w3c/vc-data-model/issues/1424
16:48:54 <bigbluehat> brent: 1424 unnecessary direction attribute
16:49:01 <bigbluehat> ivan: there's a PR for that one
16:49:10 <bigbluehat> ... and it's been merged. So lets close it
16:49:27 <brent> subtopic: https://github.com/w3c/vc-data-model/issues/1192
16:49:29 <bigbluehat> brent: excellent!
16:49:35 <bigbluehat> brent: 1192
16:49:37 <manu> q+
16:49:44 <brent> ack manu
16:49:45 <bigbluehat> ... has a PR, 1449...still open
16:49:56 <bigbluehat> manu: the rest of the list have PRs
16:50:04 <bigbluehat> brent: we'll go through them one by one
16:50:16 <bigbluehat> ... PR1449 looks ready for merging this week
16:50:28 <ivan> https://github.com/w3c/vc-data-model/pull/1449
16:50:39 <brent> subtopic: https://github.com/w3c/vc-data-model/issues/1291
16:50:43 <bigbluehat> brent: 1291
16:50:58 <ivan> https://github.com/w3c/vc-data-model/pull/1450
16:51:00 <bigbluehat> ... PR1450 covers this one. several approvals
16:51:05 <bigbluehat> ... can be merged this week
16:51:16 <bigbluehat> ... please take a look at it
16:51:32 <brent> subtopic: https://github.com/w3c/vc-data-model/issues/1388
16:51:37 <bigbluehat> brent: 1388
16:51:43 <ivan> https://github.com/w3c/vc-data-model/pull/1451
16:52:01 <bigbluehat> ... PR1451 covers this one. Has lots of conversation and approvals
16:52:05 <bigbluehat> ... please review
16:52:34 <brent> subtopic: https://github.com/w3c/vc-data-model/issues/1274
16:52:49 <ivan> https://github.com/w3c/vc-data-model/pull/1452
16:52:58 <bigbluehat> brent: 1274, PR1452 - large number of approvals, ready to be merged
16:53:23 <brent> subtopic: https://github.com/w3c/vc-data-model/issues/1431
16:53:35 <ivan> https://github.com/w3c/vc-data-model/pull/1453
16:53:50 <bigbluehat> brent: 1431, PR1453 which has approvals and on track to be merged
16:54:28 <bigbluehat> brent: we're headed toward wrapping this up
16:54:40 <bigbluehat> ... so expect to be bothered by us to get the work done...probably weely
16:54:45 <ivan> q+
16:54:47 <bigbluehat> s/weely/weekly
16:54:57 <bigbluehat> brent: many folks will be at IETF soon
16:55:13 <bigbluehat> ... 2 weeks from now
16:55:21 <brent> ack ivan
16:55:35 <bigbluehat> ivan: one warning, day light savings time 3 week nightmare approaches
16:55:55 <TallTed> let your calendar tell you the relevant local time that matters!
16:56:02 <bigbluehat> ... it's always a mess, because there's no way the US and EU will agree about this one...
16:56:17 <ivan> rrsagent, draft minutes
16:56:19 <RRSAgent> I have made the request to generate https://www.w3.org/2024/03/06-vcwg-minutes.html ivan
16:57:12 <ivan> rrsagent, bye
16:57:12 <RRSAgent> I see no action items