15:37:16 <RRSAgent> RRSAgent has joined #vcwg
15:37:20 <RRSAgent> logging to https://www.w3.org/2025/01/22-vcwg-irc
15:37:20 <Zakim> RRSAgent, make logs Public
15:37:21 <Zakim> please title this meeting ("meeting: ..."), ivan
15:37:34 <ivan> Meeting: Verifiable Credentials Working Group Telco
15:37:34 <ivan> Date: 2025-01-22
15:37:34 <ivan> Agenda: https://www.w3.org/events/meetings/e133b24e-8245-4ee7-8550-ac14d0334974/20250122T110000/
15:37:34 <ivan> chair: ivan
15:37:35 <ivan> ivan has changed the topic to: Meeting Agenda 2025-01-22: https://www.w3.org/events/meetings/e133b24e-8245-4ee7-8550-ac14d0334974/20250122T110000/
15:49:47 <ivan> regrets+ brent
15:53:46 <ivan> Topic: agenda review, introductions
15:56:57 <dlehn1> dlehn1 has joined #vcwg
15:58:15 <ivan> present+
15:58:30 <hsano> hsano has joined #vcwg
16:00:17 <hsano> present+
16:00:31 <ivan> present+ mahmoud
16:01:03 <bigbluehat> bigbluehat has joined #vcwg
16:01:18 <KevinDean> KevinDean has joined #vcwg
16:01:27 <ivan> present+ rêne
16:01:33 <KevinDean> present+
16:01:36 <bigbluehat> present+
16:01:40 <mandyv> mandyv has joined #vcwg
16:01:41 <ivan> present+ rene
16:01:57 <mandyv> present+
16:01:57 <manu> present+
16:02:11 <ivan> present+ selfissued
16:02:13 <dlongley> present+
16:02:16 <TallTed> present+
16:02:28 <ivan> present+ will
16:02:47 <ivan> present+ dlongley
16:03:11 <JoeAndrieu> JoeAndrieu has joined #vcwg
16:03:15 <Wip> Wip has joined #vcwg
16:03:26 <manu> rene: Hi, Rene from 1Password, recently joined W3C and been sitting in a few WGs. Been involved in FIDO for past few years.
16:03:30 <ivan> present+ joe
16:03:36 <Wip> present+
16:04:00 <bigbluehat> scribe+
16:04:25 <bigbluehat> ivan: anything we need to add to the agend?
16:04:33 <ivan> Topic: pending issues
16:04:34 <bigbluehat> s/agend/agenda
16:04:44 <bigbluehat> ivan: there are a few to be discussed issues
16:04:54 <ivan> subtopic: https://github.com/w3c/vc-data-model/issues/1583
16:04:55 <manu> q+
16:05:10 <bigbluehat> ivan: this is about structuring the security considerations section
16:05:25 <bigbluehat> manu: if folks remember for the VCDM, the new security group did a review on it
16:05:34 <bigbluehat> ... and mentioned there were no blocking issues
16:05:42 <bigbluehat> ... but said they may raise non-blocking issues
16:05:51 <bigbluehat> ... we have asked for a final horizontal review
16:05:58 <bigbluehat> ... we made that request a few weeks ago
16:06:02 <ivan> ack manu
16:06:17 <bigbluehat> ... just last week we heard from the security group and they requested we match a new structure
16:06:28 <bigbluehat> ... which is planned for all W3C specs.
16:06:33 <PDL-ASU> PDL-ASU has joined #vcwg
16:06:41 <ivan> present+ PDL-ASU
16:06:46 <bigbluehat> ... The vibration API and the Digital Credentials API groups would also be using this sort of structure.
16:06:47 <PDL-ASU> present+
16:06:53 <ivan> present+ jennie
16:07:17 <bigbluehat> ... we said we'd be happy to participate over time, but I don't think we said we would restructure all our documents at this stage
16:07:33 <JennieM> JennieM has joined #vcwg
16:07:34 <bigbluehat> ... if you look through what was provided, there are a number of ways we could restructure this section
16:08:01 <JennieM> present+
16:08:06 <bigbluehat> ... some of these suggestions require massive amounts of editorial work
16:08:24 <ivan> q+
16:08:28 <bigbluehat> ... we're trying to figure out what amount of this is reasonable at this stage
16:08:52 <bigbluehat> ivan: I agree with brent, this is simply too late
16:09:00 <bigbluehat> ... we're planning to go to PR in February
16:09:06 <dlongley> +1 it's too late in the process, it can be something we do in 2.1/x.1 specs going forward that clean up and revise the spec editorially
16:09:12 <manu> q+ to suggest we could do this in v2.1
16:09:21 <dlongley> +1 to do it for maintenance
16:09:21 <ivan> ack ivan
16:09:31 <bigbluehat> ... I'd propose that we put on record that we're happy to do this as maintenance work that we are already chartered to do post recommendation stage
16:09:36 <bigbluehat> ... so the issue would stay open
16:09:45 <PDL-ASU> +1 for doing the security work as maintenance
16:09:46 <bigbluehat> ... and we'd just label it for maintenance phase work
16:09:48 <ivan> ack manu
16:09:48 <Zakim> manu, you wanted to suggest we could do this in v2.1
16:10:05 <bigbluehat> manu: we do have a label 'future'
16:10:11 <bigbluehat> ... so we could mark it for that
16:10:42 <bigbluehat> ... the stuff they're requesting is interesting, but it also is early stage ideas, so this approach would give the security group more time to test out this approach
16:11:06 <bigbluehat> ... it would be good for us to do this and we have done this in the past--as seen in our current security considerations section
16:11:16 <dlongley> q+
16:11:19 <bigbluehat> ... but it would be best to take our time and do it right in the maintenance stage
16:11:28 <ivan> ack dlongley
16:11:33 <bigbluehat> dlongley: do we need a proposal for this one?
16:11:53 <bigbluehat> ivan: if manu can add this info to issue, I think we will be fine
16:11:58 <TallTed> +1 push this section revision to 2.1
16:12:10 <bigbluehat> +1
16:12:18 <bigbluehat> manu: I'm writing that now.
16:13:11 <bigbluehat> ... the group decided doing this work would be good in time, but doing this much editorial work this close to recommendation would be disruptive especially
16:13:35 <bigbluehat> ... the group agreed to mark this as editorial and address as future work during maintenance mode work cycles
16:13:44 <ivan> subtopic: https://github.com/w3c/cid/issues/141
16:13:49 <bigbluehat> ivan: that's the only issue brent identified for the data model
16:13:54 <bigbluehat> ... the next is on CID
16:14:03 <bigbluehat> ... manu, this is probably another one for you
16:14:35 <selfissued> selfissued has joined #vcwg
16:14:43 <selfissued> present+
16:14:58 <bigbluehat> manu: this issue is related to fediverse and ActivityPub use
16:15:12 <bigbluehat> ... JoeAndrieu you added something about base identifier and canonical identifier
16:15:40 <bigbluehat> ... when you get a CID value back it has an `id` value. That is supposed to match the URL you got the document from.
16:15:53 <bigbluehat> ... we say that if that is not the case, then the document should be treated as invalid
16:16:02 <bigbluehat> ... the request is to make that a MUST
16:16:26 <bigbluehat> ... we did not do that earlier because there may be cases where it is valid for them not to match
16:16:29 <selfissued> q+
16:16:37 <bigbluehat> ... such as the document being retrieved from cache even when the document is gone
16:16:46 <bigbluehat> ... or if query parameters, etc.
16:16:59 <bigbluehat> ... so we avoided MUST language and used SHOULD language
16:17:13 <bigbluehat> ... so a further suggestion was to describe those cases
16:17:25 <bigbluehat> ... for the group: do we want to make this a MUST?
16:17:39 <bigbluehat> ... if not, do we want to describe cases where these may not match?
16:17:43 <ivan> ack selfissued
16:17:53 <bigbluehat> selfissued: this is a security validation feature, so those should be MUSTs
16:18:17 <bigbluehat> ... we could informatively describe where that MUST would not be enforced
16:18:27 <dlongley> q+
16:18:28 <bigbluehat> ... or we could say MUST...UNLESS...
16:18:35 <ivan> ack dlongley
16:18:54 <bigbluehat> dlongley: I think that MUST...UNLESS... construct is what is in there now, actually...just with different words
16:18:59 <bigbluehat> ... it is conditional
16:19:11 <bigbluehat> ... in the unless case we say you should treat it as invalid
16:19:16 <ivan> q?
16:19:18 <manu> q+
16:19:24 <ivan> ack manu
16:19:26 <bigbluehat> selfissued: that sounds like it's already addressed then
16:19:42 <bigbluehat> manu: I agree, this is already addressed
16:19:55 <bigbluehat> ... do we want to describe the scenarios where it might be OK for them not to match?
16:20:01 <ivan> q+
16:20:03 <bigbluehat> ... like trusting a cache?
16:20:08 <ivan> ack ivan
16:20:13 <bigbluehat> ivan: is it a major amount of work?
16:20:21 <bigbluehat> manu: it's about a paragraph
16:20:29 <bigbluehat> ivan: well in that case!!
16:20:38 <bigbluehat> manu: I'll raise that PR
16:20:49 <bigbluehat> ivan: and everyone will be absolutely happy
16:20:52 <ivan> subtopic: https://github.com/w3c/vc-data-integrity/issues/323
16:21:02 <bigbluehat> ivan: this one is on data integrity
16:21:07 <manu> q+
16:21:38 <bigbluehat> manu: this issue was about what happens when URLs which are linked to which later disappear
16:21:47 <bigbluehat> ... the concern is mostly about archival systems
16:22:24 <bigbluehat> ... there are specifications that define how you fully encapsulate things for archival
16:22:45 <bigbluehat> ... and I think the hope is that we deal with some of those scenarios in our spec vs. downstream in archival specs
16:23:41 <bigbluehat> ... there are scenarios like extensions or the loss of the document being linked to from all systems
16:23:54 <bigbluehat> ... such as an issuer shutting down and no archives being made for the issuers documents
16:24:18 <bigbluehat> ... if there is nothing anywhere that one could get the context, then what do archives need to do?
16:24:25 <dlongley> -1 to make any of our specs create and provide a process that everyone has to follow to fetch and cache URLs
16:24:25 <dlongley> q+
16:24:26 <bigbluehat> ... one idea is to expand it inline for archival
16:24:44 <bigbluehat> ... or they could download it into the archival record
16:24:51 <bigbluehat> ... there are several ways to address it
16:25:05 <bigbluehat> ... do we want to explain that in the spec? or do we want to differ that to other specs?
16:25:10 <ivan> ack dlongley
16:25:15 <ivan> q+
16:25:33 <ivan> ack manu
16:25:41 <bigbluehat> dlongley: I'd not be opposed to stating you could store any URL and it's value for archival purposes, etc.
16:25:50 <selfissued> q+
16:25:57 <ivan> ack ivan
16:25:59 <bigbluehat> ... this would apply to any URL, so we'd also need to update JOSE/COSE to reflect that
16:26:10 <bigbluehat> ivan: is there anything here that is VC specific?
16:26:33 <ivan> ack selfissued
16:26:34 <manu> q+ to note it's not VC specific, but we could add some text to explain archival.
16:26:35 <dlongley> +1 to Ivan, if you are fetching URLs and you want to be able to "replay what happened" you need to do this
16:26:37 <bigbluehat> ... this is a 404 problem which happens all the time
16:27:00 <ivan> q?
16:27:02 <dlongley> +1 to selfissued that we don't need to say anything here
16:27:06 <ivan> ack manu
16:27:06 <Zakim> manu, you wanted to note it's not VC specific, but we could add some text to explain archival.
16:27:19 <bigbluehat> selfissued: it's not useful to describe something informatively if that text could result in normative changes
16:27:52 <bigbluehat> manu: agreed with selfissued. I don't think there's much more to say here beyond what we already say
16:28:04 <ivan> q?
16:28:08 <bigbluehat> ... we could perhaps add something to the long term security considerations section
16:28:27 <bigbluehat> ... maybe we just ask for language this person would like to see
16:28:30 <dlongley> "if your system fetches URLs at time X, you'll want to save that content from that time if you want to replay exactly what happened."
16:28:32 <bigbluehat> ... and then consider that
16:28:55 <bigbluehat> ivan: sounds good. can someone help manu with that?
16:29:07 <ivan> subtopic: https://github.com/w3c/vc-di-eddsa/issues/100
16:29:16 <bigbluehat> ivan: this one is on EDDSA
16:29:24 <bigbluehat> ... but is likely beyond just that spec
16:29:51 <bigbluehat> manu: this issue came up because Jeffrey Yaskin was doing a review on behalf of the TAG
16:30:20 <bigbluehat> ... he'd spoken to Gregg Kellogg who'd suggested the use of the JSON-LD API and options
16:30:31 <bigbluehat> ... that's Gregg's preference
16:30:44 <dlongley> q+ to also say that the WebIDL in the JSON-LD spec is optional and different APIs are acceptable -- we wouldn't want to exclude JSON-LD implementations that implement the JSON-LD algorithms from being used here
16:30:48 <bigbluehat> ... it would technically be a normative change if we changed the reference
16:31:08 <KevinDean> KevinDean has joined #vcwg
16:31:08 <ivan> q+
16:31:10 <bigbluehat> ... the reality is that we didn't have this reference previously, and we have 20 or so implementers
16:31:11 <KevinDean> present+
16:31:26 <bigbluehat> ... there's also a request to use WebIDL which only browsers care about
16:31:36 <ivan> ack dlongley
16:31:36 <Zakim> dlongley, you wanted to also say that the WebIDL in the JSON-LD spec is optional and different APIs are acceptable -- we wouldn't want to exclude JSON-LD implementations that
16:31:39 <Zakim> ... implement the JSON-LD algorithms from being used here
16:31:42 <bigbluehat> ... and we should reference that implementer feedback has shown this is implementable as described
16:31:58 <bigbluehat> dlongley: I'd also add that the WebIDL stuff in the JSON-LD API spec is optional
16:32:08 <ivan> ack ivan
16:32:23 <bigbluehat> ... so at most we might say you could do it the way we describe or the way that was requested
16:32:41 <manu> q+
16:32:55 <bigbluehat> ivan: if we describe something in WebIDL it may present a false requirement that browsers MUST implement it
16:33:02 <bigbluehat> ... this has caused confusion in past groups
16:33:17 <ivan> ack manu
16:33:19 <bigbluehat> ... that's a danger we should avoid
16:33:45 <bigbluehat> manu: yeah. true. If you invoke WebIDL, that can result in opposition and certainly causes confusion
16:34:21 <bigbluehat> ... I think the response here is that we discussed it, that it lacked support from the group, because we do not want to mandate WebIDL even though that's fine
16:34:29 <PDL-ASU> If 20 implementers are fine without this clarification there's nothing that really must be done at this time sounds good
16:34:40 <dlongley> and we have plenty of implementations already, +1.
16:34:45 <bigbluehat> ... and we did not want to suggest we intended to force browser implementers to implement the described WebIDL
16:34:48 <ivan> Topic: PRs
16:34:54 <bigbluehat> ivan: great. please then mark it as closed
16:35:07 <ivan> DI PRs: https://github.com/w3c/vc-data-integrity/pulls
16:35:24 <bigbluehat> ivan: there are 2 PRs which are pending
16:35:32 <bigbluehat> ... one of these is probably a left over
16:35:38 <bigbluehat> manu: yes, that one can be merged
16:35:45 <ivan> subtopic: https://github.com/w3c/vc-data-integrity/pull/330
16:36:04 <bigbluehat> ivan: does this one need discussion?
16:36:11 <bigbluehat> manu: I think the PR is clear
16:36:32 <ivan> Topic: VCDM PRs
16:36:38 <bigbluehat> ivan: so there is nothing really to discuss here. 5 more days to review on GitHub
16:36:42 <ivan> https://github.com/w3c/vc-data-model/pulls
16:36:47 <bigbluehat> ivan: VCDM has a few more PRs
16:36:57 <bigbluehat> ... manu, which ones of these would you like to discuss
16:37:09 <bigbluehat> manu: let's do the abstract one--1560
16:37:13 <ivan> subtopic: https://github.com/w3c/vc-data-model/pull/1560
16:37:26 <bigbluehat> ivan: this has been dragging on since September
16:37:32 <dlongley> q+
16:37:58 <bigbluehat> manu: during last call, I agreed to try to use David's language or propose alternate language that would get closer to getting consensus
16:38:21 <bigbluehat> ... DavidC did a rewrite and then I did another revision, ivan and dlongley gave feedback
16:38:30 <bigbluehat> ... I think we have consensus and I was waiting on TallTed
16:38:31 <dlongley> https://github.com/w3c/vc-data-model/pull/1560#discussion_r1923432170 <-- just one more editorial change from DavidC and I think we're good.
16:38:43 <TallTed> q+
16:38:46 <bigbluehat> ... and DavidC had one more change request
16:38:53 <ivan> ack dlongley
16:38:56 <dlongley> q-
16:39:02 <ivan> ack dlongley
16:39:05 <ivan> ack TallTed
16:39:11 <bigbluehat> TallTed: I just haven't had a chance to look at it yet. I'll do that today.
16:39:25 <bigbluehat> manu: k. then based on that review, we can hopefully get it merged
16:39:39 <ivan> subtopic: https://github.com/w3c/vc-data-model/pull/1585
16:39:42 <bigbluehat> ivan: can we try to resolve the editors list?
16:39:57 <bigbluehat> manu: DavidC said he preferred the other one, but with no details
16:40:05 <bigbluehat> ... and it's showing that he did not approve
16:40:20 <bigbluehat> ... so, some context, we had a discussion about this last week
16:40:23 <bigbluehat> ... we merged it
16:40:42 <bigbluehat> ... brent reviewed the merge and noted that we said we would use data to add editors to the list
16:40:49 <bigbluehat> ... it had not say we would remove editors
16:40:54 <bigbluehat> ... so brent reverted the changes
16:41:02 <bigbluehat> ... and this new PR puts the editor list back
16:41:15 <bigbluehat> ... so now the question is is the group OK with that
16:41:31 <ivan> q+
16:41:46 <bigbluehat> ... practically that means, if you volunteered to do work but did not make sufficient changes, you would stay on the list
16:41:57 <bigbluehat> ... this differs from how we've handled this in the past
16:42:12 <bigbluehat> ... there's also a question around GitHub handles in the Acknowledgements section
16:42:21 <selfissued> q+
16:42:24 <bigbluehat> ... and how to alphabetize those
16:42:25 <dlongley> +1 seems fine to include GitHub handles that way
16:42:30 <ivan> ack selfissued
16:42:50 <bigbluehat> selfissued: you didn't mention that I put in a change request to add Gabe
16:42:53 <manu> q+
16:43:18 <bigbluehat> ... I cited two examples of authoring and obtaining consensus for the Miami resolution which gave us a big tent scenario for awhile
16:43:31 <bigbluehat> ... he also worked out getting our media types straightened out
16:43:43 <bigbluehat> ... so I think both of those merit
16:43:54 <bigbluehat> ... I see an editors job as leaders not editors
16:44:02 <ivan> ack ivan
16:44:08 <bigbluehat> ... so I don't think doing the editorial work should be required to be an editor
16:44:39 <bigbluehat> ivan: to be more precise, as described, we do not take people off the list based on data, but do take them off if they request it
16:44:42 <mkhraisha> mkhraisha has joined #vcwg
16:44:47 <mkhraisha> q?
16:44:50 <mkhraisha> q+
16:45:03 <bigbluehat> ... the another comment on  GitHub handles in other groups they just use the GitHub handles
16:45:11 <selfissued> q+
16:45:14 <ivan> ack manu
16:45:24 <bigbluehat> ... it allows for privacy for the GitHub contributors
16:45:29 <dlongley> i think future iterations of the group should be more clear upfront on editor responsibilities and expectations so that everyone in the group is on the same page and what attribution will be based on, etc.
16:45:41 <bigbluehat> manu: I'm also OK adding Gabe, but the question then is where does he appear in the list
16:45:55 <bigbluehat> ... we currently sort by the amount of contributions
16:45:59 <mkhraisha> q-
16:46:07 <bigbluehat> ... so these contributions would put him on the bottom of the list
16:46:10 <JoeAndrieu> +1
16:46:11 <ivan> ack mkhraisha
16:46:18 <dlongley> +1 to adding Gabe
16:46:21 <ivan> ack selfissued
16:46:23 <bigbluehat> mkhraisha: I was going to suggest the same thing
16:46:54 <manu> q+
16:47:06 <bigbluehat> selfissued: manu and I discussed the GitHub acknowledgement and we say we sort it by first name
16:47:17 <ivan> q+
16:47:18 <bigbluehat> ... but these aren't first names
16:47:24 <bigbluehat> ... so i want to see a separate list
16:47:29 <bigbluehat> ... and prefer we sort by last name
16:47:46 <bigbluehat> ... and then for extra credit we could link to their GitHub handles
16:47:55 <ivan> ack manu
16:47:57 <bigbluehat> ... I shouldn't have to guess how things are sorted
16:48:27 <bigbluehat> manu: I don't want tow separate lists
16:48:33 <bigbluehat> ... but we can explain how things are sorted
16:48:37 <ivan> +1 to manu on keep one list
16:48:46 <bigbluehat> ... and that we're using GitHub handles
16:48:52 <bigbluehat> ... we do normally do last name
16:49:00 <ivan> q+
16:49:17 <bigbluehat> ... but brent has done a great deal of work and brent's last name starts with a Z
16:49:30 <selfissued> q+
16:49:34 <bigbluehat> ... also many cultures don't have last names
16:49:39 <bigbluehat> ... really we just need to decide
16:49:42 <ivan> ack ivan
16:49:48 <dlongley> first name is fine to be kind to those people who are often listed last
16:50:09 <bigbluehat> ivan: also just a reminder that "first" and "last" names are culturally subjective
16:50:21 <bigbluehat> ... Hungarian it is reversed from English
16:50:24 <ivan> ack selfissued
16:50:44 <bigbluehat> selfissued: ivan I have a question for people contributing without personal identification
16:51:04 <bigbluehat> ... the W3C has IPR requirements, how does that fit with a world where people have contributed but were not identified?
16:51:09 <manu> q+ to speak to what "contributions" the Acknowledement list identifies.
16:51:10 <bigbluehat> ivan: it depends on the contribution
16:51:26 <bigbluehat> ... non-substantial changes do not require IPR's to be signed
16:51:26 <TallTed> "given name", "family name", "patronymic", etc. For discussion of *some* of these, see https://github.com/kdeldycke/awesome-falsehood?tab=readme-ov-file#human-identity
16:52:04 <bigbluehat> ... if there are substantive changes, then they would be required to sign an IPR
16:52:20 <bigbluehat> selfissued: then why are we acknowledging these people?
16:52:28 <bigbluehat> ivan: because non-substantive changes are still valuable
16:52:35 <bigbluehat> selfissued: that's a fine answer. thank you
16:52:42 <bigbluehat> ivan: anything else?
16:52:58 <bigbluehat> manu: we have to sort out if DavidC is opposed to this change or not
16:53:05 <ivan> subtopic: https://github.com/w3c/vc-data-model/pull/1587
16:53:07 <bigbluehat> ivan: k. we have time for one more
16:53:24 <bigbluehat> manu: we have a section on error conditions
16:53:30 <bigbluehat> ... it's optional to implement
16:53:54 <bigbluehat> ... but if they do implement it, we have some strong requirements around how they implement those errors
16:54:21 <ivan> q+
16:54:21 <bigbluehat> ... this change would not effect our current test suites since these aren't tested now because they are optional
16:54:26 <ivan> ack manu
16:54:26 <Zakim> manu, you wanted to speak to what "contributions" the Acknowledement list identifies.
16:54:41 <ivan> ack ivan
16:54:55 <bigbluehat> ... so, if we reduce this from a MUST to a SHOULD to match the upstream RFC, this would not effect any implementers currently passing the test suite
16:55:12 <bigbluehat> ivan: so...apparently we have a mixed approach across the specifications that use this text
16:55:24 <dlongley> +1 for consistency
16:55:28 <bigbluehat> ... so this PR actually makes things sync up
16:55:37 <bigbluehat> ... whatever else we do, we need to be consistent
16:55:40 <PDL-ASU> +1 for  this PR
16:55:47 <bigbluehat> ... comment on the PR if you'd like
16:55:51 <bigbluehat> ... any final comments?
16:56:00 <bigbluehat> ivan: k. I think we can close the meeting
16:56:08 <bigbluehat> ... brent should be back next time
16:56:11 <bigbluehat> ... bye all
16:56:29 <ivan> rrsagent, draft minutes
16:56:31 <RRSAgent> I have made the request to generate https://www.w3.org/2025/01/22-vcwg-minutes.html ivan
17:10:09 <ivan> rrsagent, bye
17:10:09 <RRSAgent> I see no action items