14:22:59 <RRSAgent> RRSAgent has joined #vcwg
14:23:04 <RRSAgent> logging to https://www.w3.org/2024/07/17-vcwg-irc
14:23:04 <Zakim> RRSAgent, make logs Public
14:23:05 <Zakim> please title this meeting ("meeting: ..."), ivan
14:23:09 <ivan> Meeting: Verifiable Credentials Working Group Telco
14:23:09 <ivan> Date: 2024-07-17
14:23:09 <ivan> Agenda: https://www.w3.org/events/meetings/9bfb4063-230b-4f59-b14c-fbf670b8a51b/20240717T110000/
14:23:09 <ivan> chair: brent
14:23:10 <ivan> ivan has changed the topic to: Meeting Agenda 2024-07-17: https://www.w3.org/events/meetings/9bfb4063-230b-4f59-b14c-fbf670b8a51b/20240717T110000/
14:30:46 <gkellogg> gkellogg has joined #vcwg
14:50:04 <gkellogg> gkellogg has joined #vcwg
14:59:05 <hsano> hsano has joined #vcwg
15:00:45 <ivan> present+
15:00:52 <ivan> present+ davidc
15:01:11 <ivan> present+ brent
15:01:30 <ivan> present+ Wesley
15:01:39 <ivan> present+ manu
15:01:44 <brent> brent has joined #vcwg
15:02:20 <ivan> present+ hsano, joe, kevin
15:02:24 <ivan> present+ dmitriz
15:02:29 <dmitriz> dmitriz has joined #vcwg
15:02:34 <dmitriz> present+
15:02:51 <JoeAndrieu> JoeAndrieu has joined #vcwg
15:02:52 <hsano> present+
15:03:26 <KevinDean> KevinDean has joined #vcwg
15:03:30 <KevinDean> present+
15:03:39 <DavidC> DavidC has joined #vcwg
15:03:45 <wes-smith> wes-smith has joined #vcwg
15:03:45 <DavidC> present+
15:03:47 <ivan> present+ selfissued
15:03:52 <ivan> present+ dlongley
15:04:15 <JoeAndrieu> present+
15:04:19 <ivan> scribe+ JoeAndrieu
15:04:22 <JoeAndrieu> scribe+
15:04:28 <ivan> present+ jennie
15:04:48 <ivan> present+ dlehn
15:05:16 <JoeAndrieu> brent: agenda: TPAC, EBSI, Issue processing on VCDM and PRs, controller document
15:05:27 <JoeAndrieu> ... any suggestions?
15:05:40 <brent> Topic: Masking at TPAC
15:06:14 <JoeAndrieu> ... W3C is feeling they don't have the authority to enforce strict masking in the common spaces at TPAC
15:06:15 <ivan> present+ bigbluehat
15:06:15 <smccown> smccown has joined #vcwg
15:06:23 <ivan> present+ smccown
15:06:29 <JoeAndrieu> ... however, they are encouraging groups to establish masking rules for their meetings
15:06:37 <bigbluehat> bigbluehat has joined #vcwg
15:06:48 <JoeAndrieu> ... We as a group have the authority to decide our own masking policy
15:07:11 <JennieM> JennieM has joined #vcwg
15:07:14 <JennieM> present+
15:07:24 <JoeAndrieu> ... The route I feel is best, but please speak up... this group would be willing to mask if there is anyone in the group attending TPAC who would be uncomfortable if people are masked
15:07:32 <dmitriz> heh do you know if they're still asking to test at the registration desk, like they did last year? (which I'm very glad they did, it caught a bunch of covid cases)
15:07:44 <JoeAndrieu> a/are masked/aren't masked/
15:07:51 <JoeAndrieu> s/are masked/aren't masked/
15:08:11 <JoeAndrieu> ... Please reach out to me or Ivan if you disagree.
15:08:13 <manu> +1 to be willing to mask if others feel strongly (but would prefer not to given how things have been operating) -- I say this as one of the few who got COVID at W3C TPAC last year (and was the only time I've had it). :)
15:08:23 <gkellogg> gkellogg has joined #vcwg
15:08:34 <bigbluehat> present+
15:08:35 <JoeAndrieu> ... Moving forward on that hypothesis: if you are planning to attend but feel like you can only do so if people are masked in their room, please reach out to chairs.
15:08:52 <selfissued> selfissued has joined #vcwg
15:08:57 <selfissued> present+
15:08:59 <selfissued> q+
15:09:01 <JoeAndrieu> ... Chairs will take that input in confidence and make a decision. Basically, let us know and we will use actual information to set policy.
15:09:16 <brent> ack selfissued
15:09:27 <ivan> q+
15:09:29 <JoeAndrieu> selfissued: I would prefer to defer to local health care rules
15:09:48 <JoeAndrieu> brent: I do not disagree, but this is the route the W3C has taken.
15:09:54 <brent> ack ivan
15:10:05 <smccown> +1 for deferring to local health care rules
15:10:10 <JoeAndrieu> ivan: To make it clear, the "house rules" is that the W3C will not impose masking as it did in the last few years.
15:10:26 <JoeAndrieu> ... that being said, there are groups which have members who have asked ror masking.
15:10:43 <JoeAndrieu> brent: so W3C isn't enforcing masking, but groups are allowed to do so, should they choose to do so.
15:11:06 <JoeAndrieu> ... Our default is "no. wear a mask if you want." but Let's get some feedback
15:11:10 <brent> Topic: EBSI and termsOfUse
15:11:25 <JoeAndrieu> brent: anyone from EBSI here?
15:11:37 <JoeAndrieu> ... I thought they were going to come talk to us.
15:11:52 <manu> q+ to send an email :)
15:12:14 <JoeAndrieu> ... Seems like they are not. Which is fine, but in absence of them showing up and telling us they are using Terms of Use, then we should probably keep it as a reserved term, but not an extension point.
15:12:18 <brent> ack manu
15:12:18 <Zakim> manu, you wanted to send an email :)
15:12:37 <DavidC> q+
15:12:41 <ivan> q+
15:12:44 <JoeAndrieu> manu: I would be fine with that (as editor), can we send them an email asking for details that would let us include it if appropriate.
15:12:55 <JoeAndrieu> brent: and you're taking that action
15:12:58 <JoeAndrieu> manu: sure.
15:13:01 <brent> ack DavidC
15:13:20 <JoeAndrieu> DavidC: I agree. I'm amazed. These guys replied they are using it, they do want it, and they were going to come give us a demo.
15:13:31 <JoeAndrieu> ... but if they can't be bothered...
15:13:43 <brent> ack ivan
15:14:19 <JoeAndrieu> ivan: because it is a reserved term, it is one of the terms that the new charter would give us the right to incorporate it into a spec. So, if we decide now it is reserved and do no more, that does not mean the door is closed forever.
15:14:46 <JoeAndrieu> brent: do we still want to send an email?
15:15:05 <JoeAndrieu> manu: sure. It's not a big deal either way. Let's give them a heads up.
15:15:35 <brent> Topic: VCDM Issue Processing
15:15:38 <JoeAndrieu> DavidC: Manu's edit removes it, which works for me, so we can likely close mine and take Manu's.
15:15:39 <manu> +1 to agree with DavidC ^
15:15:50 <brent> https://github.com/w3c/vc-data-model/pulls
15:15:57 <JoeAndrieu> brent: Pull requests
15:16:17 <dlehn> dlehn has joined #vcwg
15:16:28 <JoeAndrieu> manu: can we start with 1508?
15:16:29 <brent> subtopic: https://github.com/w3c/vc-data-model/pull/1508
15:16:54 <manu> q+
15:17:02 <JoeAndrieu> brent: add AI section. lots of approvals. One request for changes that seems editorial. And one request from Mike Jones to not include it at all.
15:17:02 <brent> ack manu
15:17:21 <JoeAndrieu> manu: I have applied Ted's suggested changes.
15:17:43 <selfissued> q+
15:17:48 <JoeAndrieu> brent: anyone (other than Mike) on the call that would object to merging PR 1508?
15:17:50 <brent> ack selfissued
15:17:56 <JoeAndrieu> ... Mike you can comment too.
15:18:11 <JoeAndrieu> selfissued: What was the update that was going to be made?
15:18:41 <JoeAndrieu> manu: Dave's changes. Something like "VCs that seem like they might be only attained by humans... might be used by AI."
15:18:59 <JoeAndrieu> selfissued: Let me re-review it during the call.
15:19:36 <JoeAndrieu> brent: pinging Mike may not have happened, so thanks Mike for looking at it.
15:20:04 <brent> subtopic: https://github.com/w3c/vc-data-model/pull/1520
15:20:05 <tzviya> tzviya has joined #vcwg
15:20:21 <JoeAndrieu> ... 1520 and 1525 exist as a pair, really.
15:20:22 <ivan> https://github.com/w3c/vc-data-model/pull/1525
15:20:41 <JoeAndrieu> ... One of them 1520 takes vocab out of base context. 1525 adds optional new context with vocab in it.
15:21:02 <dmitriz> q+
15:21:05 <JoeAndrieu> ... which allows people to test/develop
15:21:23 <brent> ack dmitriz
15:21:37 <manu> q+
15:21:48 <JoeAndrieu> dmitriz: quick question. about adding vocab to undefined terms context. Is that an option in addition to the examples context?
15:21:54 <brent> also talking about https://github.com/w3c/vc-data-model/pull/1525 simultaneously
15:21:58 <JoeAndrieu> ... we already have @vocab in the examples.
15:22:11 <JoeAndrieu> ... I am a fan of taking it out of core.
15:22:12 <brent> ack manu
15:22:37 <selfissued> q+
15:22:39 <JoeAndrieu> manu: You're right, Dmitri. 1525 would add a separate @vocab in the undefined terms context.
15:23:06 <JoeAndrieu> ... that one would be able to be used in production for thoes who want to use it. We recommend not to use @vocab in production unless you know what you're doing.
15:23:33 <JoeAndrieu> ... the compromise we got to was that Gabe wanted something other than the examples contexts that leverages issuer-defined terms.
15:24:00 <JoeAndrieu> ... Gabe liked this approach, so it met his concerns.
15:24:19 <JoeAndrieu> ... The main difference is that the examples context is not for production.
15:24:26 <brent> ack selfissued
15:24:27 <JoeAndrieu> ... The new one is.
15:24:40 <TallTed> TallTed has joined #vcwg
15:25:08 <ivan> present+ TallTed
15:25:16 <JoeAndrieu> selfissued: I take exception that the working group has decided to remove @vocab.
15:25:37 <JoeAndrieu> brent: I did not see it that way, so I didn't call it out as chair.
15:26:10 <JoeAndrieu> brent: ok. two PRs. anyone other than Mike who objects, please speak up.
15:26:14 <PL-ASU> PL-ASU has joined #vcwg
15:26:35 <PL-ASU> present+
15:26:44 <JoeAndrieu> brent: as the only objector, is this is merged in, do you expect to formally object if this goes in.
15:26:49 <dmitriz> q+
15:26:57 <JoeAndrieu> selfissued: I hope we'll never get there.
15:27:01 <ivan> q+
15:27:09 <JoeAndrieu> ... We should have stability. This is destabilizing.
15:27:11 <gkellogg> gkellogg has joined #vcwg
15:27:23 <ivan> q-
15:27:24 <JoeAndrieu> ... The reason we put this in is so that all terms are processed as RDF. This is a security problem.
15:27:36 <JoeAndrieu> brent: I felt there was additional information that justified reopening the discussion.
15:27:48 <JoeAndrieu> ... I agree it is destabilizing, but I felt it was necessary.
15:27:55 <JoeAndrieu> selfissued: this is a security degradation.
15:27:59 <brent> ack dmitriz
15:28:19 <selfissued> q+
15:28:25 <ivan> +1 to dmitriz
15:28:31 <manu> +1 to dmitriz
15:28:32 <JoeAndrieu> dmitriz: Just taking out @vocab is destablizing, but adding it back to undefined terms to restore stability.
15:28:44 <bigbluehat> +1 to dmitriz; definitely makes things clearer for everyone
15:28:45 <brent> ack selfissued
15:28:46 <JoeAndrieu> ... we are offering the same security options, we're just adding a flag for it.
15:28:55 <ivan> q+
15:28:59 <JoeAndrieu> selfissued: it's still a security degradation because its still optional.
15:29:04 <JoeAndrieu> ... developers are lazy.
15:29:05 <manu> q+ to note we are repeating conversations that have happened in the issue already.
15:29:05 <brent> q+ to ask about must
15:29:11 <brent> ack ivan
15:29:19 <JoeAndrieu> ... deployments will occur where they forget to add the additional context.
15:29:41 <JoeAndrieu> ivan: I'm suprised by "security degradation". But the current situation has a security problem as well.
15:29:54 <JoeAndrieu> ... so the question is which of these are worse?
15:30:03 <brent> ack manu
15:30:03 <Zakim> manu, you wanted to note we are repeating conversations that have happened in the issue already.
15:30:03 <selfissued> q+
15:30:14 <JoeAndrieu> manu: I also take exception to the concept that there is a security degradation
15:30:25 <JoeAndrieu> ... we are repeating things that have been discussed in the issues multiple times
15:30:55 <JoeAndrieu> ... If a term is undefined, the processor thows an error. That's what happens. I don't see how a processor throwing an error is a security degradation.
15:31:02 <JoeAndrieu> ... This is a security enhancement.
15:31:20 <JoeAndrieu> ... You seem to be arguing from a position from a year ago that we have already addressed.
15:31:25 <brent> ack brent
15:31:25 <Zakim> brent, you wanted to ask about must
15:31:58 <dmitriz> +1 I like that suggestion
15:32:01 <JoeAndrieu> brent: I believe I have a suggestion for addressing Mike's concern. How about "If you define terms that are not in the default context, you must you the undefined terms context"
15:32:05 <brent> ack selfissued
15:32:10 <JoeAndrieu> q+
15:32:17 <brent> ack JoeAndrieu
15:32:21 <dlongley> scribe+
15:32:43 <dlongley> JoeAndrieu: The only concern I have with what you said, Brent, is that you should still be able to define terms in our own context and not use the undefined terms context.
15:32:53 <JoeAndrieu> +1
15:33:00 <dlongley> brent: You must either define terms in your own context or use the undefined terms context.
15:33:06 <ivan> +1 to brent's option
15:33:06 <dlongley> +1 to say that you must do either of these things.
15:33:06 <JoeAndrieu> brent: does this sound like a viable path forward?
15:33:18 <dlongley> scribe-
15:33:19 <JoeAndrieu> ... I'm seeing +1s
15:33:21 <DavidC> you must you -> you must use
15:33:33 <JoeAndrieu> brent: anyone who can't live with this moving forward, speak now.
15:33:45 <JoeAndrieu> ... This feels like consensus emerging.
15:34:06 <JoeAndrieu> ... Manu, these are your PRs, will you make those mods?
15:34:11 <JoeAndrieu> manu: yes.
15:34:16 <JoeAndrieu> ... can we merge it once we do that?
15:34:18 <selfissued> q+
15:34:19 <JoeAndrieu> brent: Mike?
15:34:34 <JoeAndrieu> selfissued: I'd like to get a few people's eyes on the new semantics before we merge it.
15:35:07 <JoeAndrieu> brent: Manu, thanks for the willingness to make the changes. Ping me or Mike once you have the changes in.
15:35:30 <JoeAndrieu> ... If those changes go in this afternoon, can you re-review by the end of the week?
15:35:36 <JoeAndrieu> selfissued: Yes.
15:35:58 <ivan> q+
15:35:58 <brent> ack selfissued
15:36:02 <JoeAndrieu> brent: So we'll have feedback by Friday, which if cleared, means you can merge.
15:36:12 <ivan> q-
15:36:29 <selfissued> I still think this is a waste of spec space, but I've withdrawn my objection https://github.com/w3c/vc-data-model/pull/1508#pullrequestreview-2183294339
15:36:46 <JoeAndrieu> ... one last thing on charter. We don't need to hold off on a bunch of PRs as the charter explicitly includes the details we need.
15:37:06 <JoeAndrieu> ... next up: Issues
15:37:23 <brent> https://github.com/w3c/vc-data-model/issues?q=is%3Aissue+is%3Aopen+-label%3Afuture+sort%3Aupdated-asc
15:37:53 <brent> subtopic: https://github.com/w3c/vc-data-model/issues/1479
15:38:09 <JoeAndrieu> ... Dmitri, the time is come. We need a PR or we need to pull it. How are we doing?
15:38:25 <JoeAndrieu> ... Looks like we lost Dmitri.
15:38:33 <JoeAndrieu> manu: I'll raise a PR
15:38:34 <TallTed> s/time is come/time has come/
15:38:54 <brent> subtopic: https://github.com/w3c/vc-data-model/issues/1517
15:39:19 <manu> q+
15:39:23 <JoeAndrieu> brent: Part of our edits over the last year were to refine the algorithm for verification. This is further iteration on that.
15:39:43 <brent> ack manu
15:39:43 <JoeAndrieu> ... PR 1522 is response to the issue.
15:39:58 <JoeAndrieu> manu: it's really just editorial.
15:40:10 <JoeAndrieu> ... I just need to figure out how to do what he wants us to do.
15:40:29 <JoeAndrieu> brent: where's the PR that puts it somewhere else?
15:40:36 <JoeAndrieu> manu: 1523. We merged that.
15:40:56 <JoeAndrieu> ... I need to check with Jeffrey about closing.
15:41:21 <JoeAndrieu> manu: he raised two issues, but maybe we addressed it with 1523
15:41:38 <brent> subtopic: https://github.com/w3c/vc-data-model/issues/1239
15:41:43 <JoeAndrieu> brent: What is the reason we shouldn't just do this now?
15:41:56 <manu> q+
15:41:58 <JoeAndrieu> ... any reason to wait?
15:42:00 <brent> ack manu
15:42:26 <JoeAndrieu> manu: The group decided to do it later. I don't see why not to do it now.
15:42:33 <ivan> q+
15:42:34 <JoeAndrieu> ... It'd be nice to close the issue.
15:42:47 <JoeAndrieu> ... We also looked into it and there is some kind of caching bug problem. Ivan?
15:42:47 <brent> ack ivan
15:43:00 <JoeAndrieu> ivan: The problem is we are in an area I'm not familiar with.
15:43:29 <gkellogg> gkellogg has joined #vcwg
15:43:33 <manu> q+
15:43:35 <JoeAndrieu> ... there was a caching problem I don't fully grasp, but the original problem is that the files we are talking about may still be subject to change that would create potential problems. E.g., taking vocab out.
15:43:43 <manu> q+ to note that this is for the /v1 file.
15:43:44 <dlehn> q+
15:43:47 <JoeAndrieu> ... so I proposed doing it after we're stable. but not opposed to doing it now.
15:43:49 <manu> q- later
15:44:02 <brent> ack dlehn
15:44:09 <JoeAndrieu> dlehn: what was the propose change?
15:44:28 <JoeAndrieu> ... the caching thing is a proxy issue. not sure how that gets fixed.
15:44:52 <JoeAndrieu> ivan: at some point in the future, the files we are talking about will migrant to W3C website and won't be redirected to github.
15:45:09 <JoeAndrieu> ... It seems the problem with github will go away eventually.
15:45:30 <brent> ack manu
15:45:30 <Zakim> manu, you wanted to note that this is for the /v1 file.
15:45:35 <JoeAndrieu> dlehn: while still under development, maybe we shouldn't move them over.
15:46:04 <ivan> q+
15:46:08 <JoeAndrieu> manu: the issue is about the credentials v1 context. That should be fixed. For v2 context, that is still up in the air, we don't have to address those at this point.
15:46:23 <JoeAndrieu> ... Let's just take care of V1 context.
15:46:29 <JoeAndrieu> ... We can talk about v2 later.
15:46:34 <brent> ack ivan
15:47:15 <JoeAndrieu> ivan: I was not remembering that point, so thanks. I think what I hit as a problem is that we cannot set expiration data on a specific file. We can set it on all the files that are given to IPNET directly. I don't remember how the system is organized.
15:47:25 <manu> q+q+
15:47:26 <manu> q+
15:47:29 <manu> q- q+
15:47:30 <JoeAndrieu> ... If they are in the same directory, we can't set the expiry different for one than the other.
15:47:42 <brent> ack manu
15:48:00 <manu> heres one way to set expires on specific URLs: https://stackoverflow.com/questions/1600831/setting-expires-header-for-a-specific-uri
15:48:01 <JoeAndrieu> manu: we can set expires on specific URLs in apache. Here's how to do that.
15:48:27 <JoeAndrieu> ivan: I'm happy to look at it again either this week or next.
15:48:42 <JoeAndrieu> ... I could use someone to look over my shoulder.
15:48:52 <JoeAndrieu> manu: cc Lehn and myself and we'll help out
15:48:57 <brent> subtopic: https://github.com/w3c/vc-data-model/issues/1529
15:49:09 <JoeAndrieu> brent: enhanced context validation.
15:49:31 <JoeAndrieu> manu: Gave made a proposal that we add normative language to data integrity spec, but it might be good to put in VCDM.
15:49:52 <JoeAndrieu> ... some sort of normative language to say you are checking issuers
15:50:13 <JoeAndrieu> ... Ted also suggested some detail on how you can use compaction algorithms to get rid of untrusted contexts
15:50:22 <JoeAndrieu> ... This PR is creating new normative language to doing that.
15:50:43 <JoeAndrieu> ... We would be testing for that at the application layer, which we haven't done before.
15:50:56 <JoeAndrieu> ... But it seems that the group is willing to go there.
15:51:08 <JoeAndrieu> ... action is to raise a PR that does that.
15:51:13 <JoeAndrieu> brent: any concerns, speak up now
15:51:13 <manu> q+
15:51:20 <brent> ack manu
15:51:46 <JoeAndrieu> manu: I do have a question to the group. The specs we are creating have architectural layers, e.g., the securing layer is lower on the stack and validation is higher.
15:52:12 <JoeAndrieu> ... I'm trying to figure out if it is worth using this language in the data integrity specification
15:52:23 <JoeAndrieu> ... Note that data integrity can work on things without @context
15:52:33 <JoeAndrieu> ... we describe the challenges with that.
15:52:59 <ivan> q+
15:53:01 <JoeAndrieu> ... Would people object to duplication that language? If we put it in Data Integrity, that's likely a layer violation.
15:53:05 <brent> ack ivan
15:53:13 <manu> q+
15:53:27 <manu> q+ to explain the layering problem.
15:53:31 <JoeAndrieu> ivan: I sort of understand the layering problem. But for me, the language seems more natural in the DI spec than VCDM. Just my instinct.
15:53:33 <brent> ack manu
15:53:33 <Zakim> manu, you wanted to explain the layering problem.
15:53:51 <JoeAndrieu> manu: If we only put the language in the DI spec, VC-JOSE-COSE would have no language in it to ensure they understand the context.
15:54:05 <ivan> q+
15:54:20 <JoeAndrieu> ... the layering here is that "these statements are things the application layer should be doing" they don't have much to do with data integrity. They have more to do with VCDM.
15:54:34 <JoeAndrieu> ... The root issue was ignoring contexts.
15:54:48 <JoeAndrieu> ... So we had to tell people, "When you process an incoming document, you have to understand what it means".
15:55:04 <JoeAndrieu> ... One way to do that, with @context is to make sure you understand and trust the @contexts.
15:55:20 <JoeAndrieu> ... That is an application-layer instruction. At the validation layer.
15:55:24 <dlongley> i.e., don't just guess what JSON keys refer to
15:55:38 <JoeAndrieu> ... That's why it would be a layer violation
15:55:41 <brent> ack ivan
15:56:04 <JoeAndrieu> ivan: that makes sense. My first instinct then is that something needs to be added to VC-JOSE-COSE
15:56:09 <JoeAndrieu> q+
15:56:12 <dlongley> the string "cats" could refer to many different things.
15:56:26 <JoeAndrieu> q-
15:56:37 <JoeAndrieu> brent: next week's meeting is canceled.
15:56:47 <dlongley> scribe+
15:57:02 <dlongley> JoeAndrieu: The validation of the issues definitely doesn't seem like it's about securing, I am convinced of the layering violation.
15:57:07 <dlongley> q-
15:57:19 <gkellogg> gkellogg has joined #vcwg
15:57:20 <ivan> rrsagent, draft minutes
15:57:21 <RRSAgent> I have made the request to generate https://www.w3.org/2024/07/17-vcwg-minutes.html ivan
15:58:25 <ivan> rrsagent, bye
15:58:25 <RRSAgent> I see no action items