14:09:15 <RRSAgent> RRSAgent has joined #vcwg
14:09:19 <RRSAgent> logging to https://www.w3.org/2024/07/03-vcwg-irc
14:09:19 <Zakim> RRSAgent, make logs Public
14:09:20 <Zakim> please title this meeting ("meeting: ..."), ivan
14:09:41 <ivan> Meeting: Verifiable Credentials Working Group Telco
14:09:41 <ivan> Date: 2024-07-03
14:09:41 <ivan> Agenda: https://www.w3.org/events/meetings/c9d3c6dc-305d-4ab8-9c97-c3c3faf06240/20240703T110000/
14:09:41 <ivan> chair: brent
14:09:42 <ivan> ivan has changed the topic to: Meeting Agenda 2024-07-03: https://www.w3.org/events/meetings/c9d3c6dc-305d-4ab8-9c97-c3c3faf06240/20240703T110000/
14:57:36 <ivan> present+
14:59:09 <hsano> hsano has joined #vcwg
15:00:05 <ivan> present+ brent, hsano, manu
15:00:17 <brent> brent has joined #vcwg
15:00:27 <brent> present+
15:00:42 <DavidC> DavidC has joined #vcwg
15:00:45 <DavidC> present+
15:01:23 <TallTed> TallTed has joined #vcwg
15:01:53 <ivan> present+ TallTed
15:02:17 <ivan> present+ jennie
15:02:36 <ivan> present+ joe
15:02:55 <ivan> present+ gabe
15:03:03 <ivan> present+ dlongley
15:03:16 <ivan> present+ selfissued
15:03:24 <decentralgabe> decentralgabe has joined #vcwg
15:03:27 <decentralgabe> present+
15:04:08 <JoeAndrieu> JoeAndrieu has joined #vcwg
15:04:11 <decentralgabe> scribe+
15:04:36 <selfissued> selfissued has joined #vcwg
15:04:46 <selfissued> present+
15:04:56 <JennieM> JennieM has joined #vcwg
15:04:59 <decentralgabe> brent: Welcome to the VCWG weekly meeting. We were going to have a conversation with EBSI about Terms of Use. We will do VCDM issue processing and look at Controller Document PRs + Issues. Anything else?
15:05:14 <selfissued> (Stepping away to get more coffee for a couple of minutes)
15:05:20 <decentralgabe> selfissued: I would like to review Controller Document status and next steps
15:05:22 <JennieM> present+
15:05:22 <ivan> present+ dlehn
15:05:27 <decentralgabe> brent: we will go into it!
15:05:51 <brent> Topic: VCDM Issue Processing
15:05:58 <brent> https://github.com/w3c/vc-data-model/issues?q=is%3Aissue+is%3Aopen+-label%3Afuture+sort%3Aupdated-asc
15:06:02 <decentralgabe> ... let's hope EBSI folks will join later and jump into issue processing
15:06:27 <brent> subtopic: https://github.com/w3c/vc-data-model/issues/1437
15:06:32 <manu> q+
15:06:34 <decentralgabe> ... we have 10 open issues. many are addressed.  #1437 - Remove at risk issue markers for property extension points
15:07:06 <brent> ack manu
15:07:09 <decentralgabe> manu: We are waiting for the charter to up for AC vote for the PRs to go in. Waiting to hear from EBSI so that we can see their usage and cite it in the spec
15:07:24 <brent> brent has joined #vcwg
15:08:00 <brent> subtopic: https://github.com/w3c/vc-data-model/issues/1479
15:08:28 <decentralgabe> brent: next we have language maps. do not see Dmitri on the call today. he is working on a PR but we have not seen movement for a month. if it's not happening we need to close it.
15:08:45 <decentralgabe> manu: I can take it
15:08:45 <bigbluehat> bigbluehat has joined #vcwg
15:09:03 <decentralgabe> brent: please reach out first to see his progress
15:09:26 <brent> subtopic: https://github.com/w3c/vc-data-model/issues/1507
15:09:38 <decentralgabe> ... let's talk about AI! 1507 Add Security Considerations related to advances in Artificial Intelligence
15:10:03 <manu> q+
15:10:13 <brent> ack manu
15:10:19 <decentralgabe> ... there are vendors concerned about AI and interactions with VCs. we talked and said it could in validation/verification, or security considerations. getting some pushback from Mike -- let's see if we can find some consensus.
15:10:38 <ivan> https://github.com/w3c/vc-data-model/pull/1508
15:10:50 <decentralgabe> manu: I moved to the validation section as Gabe requested. I know Ted pushed back a bit. It's not out of place in either section. Pulled in all the WG's requests for changes.
15:10:58 <ivan> present+ bigbluehat
15:12:03 <TallTed> q+
15:12:05 <decentralgabe> selfissued: I have expressed in GitHub. as editors we need to make judgment calls on what is useful/actionable vs what makes the spec longer. This doesn't improve implementations. I don't want stuff in it that I'm embarrassed to see. Should we also have security considerations around cloud computing? I'm puzzled
15:12:09 <brent> ack TallTed
15:12:09 <decentralgabe> q+
15:12:13 <manu> q+
15:13:24 <decentralgabe> TallTed: Didn't get the joke. There's a difference between cloud computing and an 'active agent' - we know it's an independent actor that can be put to use now in new ways. I think it is a relevant caution. We should say 'be aware of this new thing, a moving target'
15:13:37 <decentralgabe> ... could be decades until things settle down. let's put in a brief warning and move on
15:13:44 <brent> ack decentralgabe
15:14:01 <manu> decentralgabe: What would make this more real to you, Mike? Is there language we could change?
15:14:15 <selfissued> q+
15:14:20 <brent> ack manu
15:14:32 <manu> decentralgabe: Concerns around AI and data legitimacy are real. If we could improve the text that would be good.
15:15:31 <decentralgabe> manu: I appreciate your opinion Mike. At this point just about everybody is disagreeing with your point. There are people working on some of the largest AI companies in the world working on research around AI and Verifiable Credentials. It quotes the work we're doing here directly.
15:17:02 <decentralgabe> ... it is possible for AI to pass tests today that were thought to only be passed by humans before (GRE, high school diploma, etc.). If people are building systems, and the security is built on VCs identifying certain capabilities and proof of personhood...we need to warn that may not be good enough anymore. Security researchers need to take that into accoutn.
15:17:40 <decentralgabe> ... captcha is broken now. AIs can solve it better than humans. it would be strange for us to not say something about this
15:17:44 <JoeAndrieu> JoeAndrieu has joined #vcwg
15:17:56 <dlongley> "VCs with claims that seem like they might only be acquirable by human persons might also become acquirable by artificial intelligence systems, be aware of this when validating / making decisions"
15:18:01 <brent> ack selfissued
15:18:05 <decentralgabe> ... see no reason to not put this into the spec
15:18:22 <dlongley> s/VCs with claims that seem/VCs that seem like/
15:18:41 <dlongley> q+
15:18:45 <ivan> present+ Phil_ASU
15:19:06 <manu> q+ to reject the philosophy that anything that isn't a normative statement shouldn't be written in the specification.
15:19:07 <decentralgabe> selfissued: Gabe used the word that is key. Is the guidance 'actionable'. Are there things we're recommending? Are there actions that can be taken? If there are actions -- cool. If I get overruled I would rather this be a security consideration. If there is not a validation consideration then it doesn't belong there
15:19:10 <brent> ack dlongley
15:19:21 <PL-T3> PL-T3 has joined #vcwg
15:19:25 <JoeAndrieu> q+ to say the language does give actionable advice
15:19:27 <PL-T3> present+
15:19:47 <decentralgabe> dlongley: Text should say something like 'VCs that seem like they may only be acquired by humans today may be acquired by AI systems' - don't assume only a human can do it
15:19:55 <brent> ack manu
15:19:55 <Zakim> manu, you wanted to reject the philosophy that anything that isn't a normative statement shouldn't be written in the specification.
15:20:41 <decentralgabe> manu: the philosophy that a spec should only contain normative actionable statements that end up in impls is a philosophy I do not believe we have ever - or should - employ. we have plenty of statements like this today, e.g. describing the ecosystem so implementers can make better decisions. -1 to a notion that everything we write needs to be actionable
15:20:56 <selfissued> q+
15:21:03 <decentralgabe> ... implementers need to be able to take guidance and apply it to their specific use case
15:21:11 <brent> ack JoeAndrieu
15:21:11 <Zakim> JoeAndrieu, you wanted to say the language does give actionable advice
15:22:01 <decentralgabe> JoeAndrieu: we do need to write something since people are asking this question and using this technology. 2 differences. 1 - confidence method is part of how we're trying to solve this problem; not figured out yet (still a reserved property). the text does have actionable advice, though we can improve it. need to say something
15:22:07 <brent> ack selfissued
15:22:56 <manu> q+
15:23:03 <decentralgabe> selfissued: I like what Dave Longley said - since it is actionable. Verifiers should not assume tests heretofore that were only passable by human beings are not achievable by machines at this point. don't make an assumption that passing a turing test = party is a human being
15:23:16 <brent> ack manu
15:23:20 <decentralgabe> brent: thanks Mike. seems like we have a path forward. language in chat
15:23:47 <decentralgabe> manu: the language is already in the PR. I would like to stop playing 'go fetch a rock' with this PR. I will integrate Dave's changes
15:23:54 <decentralgabe> selfissued: I will re-review after that, please ping me
15:24:13 <brent> subtopic: https://github.com/w3c/vc-data-model/issues/1509
15:24:59 <decentralgabe> brent: updated media types - 1509. don't want a big discussion. we are trying to register application/vc and /vp - we are still on that path. if it gets accepted we're done. if not, we will revisit and talk about other options. at this stage I do not think it is a fruitful topic to have a conversation about
15:25:12 <manu> q+
15:25:18 <brent> subtopic: https://github.com/w3c/vc-data-model/issues/1514
15:25:42 <decentralgabe> ... now we get to talk about 1514. Re-evaluate support for @vocab in base VCDM v2 context. coming out of a conversation in the Data Integrity spec. Some folks are suggesting there is a critical vulnerability. This could be a mitigation.
15:25:46 <brent> ack manu
15:26:39 <ivan> https://github.com/w3c/vc-data-integrity/issues/272
15:26:50 <decentralgabe> manu: the discussion in the DI spec asserts a number of things...one is a realization that some people do not understand how @vocab works. because of that it has been misinterpreted and misused in that security disclosure. this discussion has led some to change their position on adding @vocab to the base context.
15:28:18 <decentralgabe> ... the issue asserts we should remove @vocab from the base context. still up to us to decide how it could be used, if at all. the spec doesn't say 'don't use it in production' - folks in the thread think it must not be used in production (MUST vs SHOULD). how do we enforce that? should we? there are legitimate uses of @vocab/@base in production.
15:28:19 <ivan> q+
15:28:31 <decentralgabe> ... there is enough here to raise a PR after we discuss this a bit more on the call today
15:28:35 <brent> ack ivan
15:29:14 <manu> q+
15:29:24 <decentralgabe> ivan: if @vocab must not be used that would require all participant parties to check that. that means off-the-shelf LD checkers cannot do this, since it is valid LD.
15:29:25 <brent> ack manu
15:30:47 <dlongley> +1 that we consider some language changes but not add a MUST NOT; any verifier must understand the contexts it consumes information from anyway, and they can only allow list contexts that don't include `@vocab` (so long as `@vocab` is removed from the core context)
15:30:59 <dlongley> q+
15:31:01 <decentralgabe> manu: you are right. there are some LD processors considering putting in a feature around this. I don't know if there is support for pulling this into our spec. There are legitimate uses of @vocab in production. Example: if the last @vocab in a context array, and your application knows that, ... it could be fine to use @vocab if you order it properly and there are other similar scenarios
15:31:28 <ivan> q+
15:32:06 <brent> ack dlongley
15:32:07 <decentralgabe> ... feels like we're closing off a bunch of use cases for no real reason. the current security disclosure specifically did not do checks that we highlight in the spec. do not think we'll get consensus. most we'll see is a 'should not' or strongly discourage it unless you know what you're doing
15:32:48 <selfissued> q+
15:32:56 <decentralgabe> dlongley: I tend to agree. a MUST NOT is a bridge too far. I do think removing @vocab from the base context is a good idea. any context should be vetted, verifiers do not need to accept with @vocab if they vet the core context (and we remove it)
15:33:01 <brent> ack selfissued
15:33:54 <dlongley> q+
15:33:56 <decentralgabe> selfissued: I was talking with Orie about this. The statements he made...he has a slight preference for always getting to RDF even if as a result of @vocab terms. If it is removed, then removal should mean terms are interpreted as JSON not RDF.
15:33:57 <decentralgabe> q+
15:34:03 <brent> ack ivan
15:35:06 <decentralgabe> ivan: trying to make clear what I understand the proposal to be. 1 - remove from the core context. in parallel 2 - reinforce text to say 'don't use that if you can avoid it'. I agree with both proposals
15:35:06 <manu> yes, your understanding of the proposal is correct, Ivan.
15:35:31 <selfissued> q+
15:35:51 <decentralgabe> ... to Mike - I do not understand everything Orie is stating. I know he has this opinion that everything should be done on RDF only. I do not want to get into this, and not the right person to discuss this (RDF bias). His statement that we should treat it as JSON...I do not understand what he means
15:35:52 <brent> ack dlongley
15:36:33 <decentralgabe> dlongley: we decided a while ago that VC 2.0 uses LD compacted form. That requires that you understand the @context field. Not something you can just ignore. That makes things simple. We can clarify more if we need to do so. When you understand that...it prevents these problems from being raised
15:36:37 <brent> ack decentralgabe
15:37:26 <ivan> present+ aniltj
15:37:34 <manu> decentralgabe: My main concern was to reduce the complexity on implementers that are more LD-averse, and I'm afraid that removing vocab increases the burden on implementers. I can see the arguments for using LD and understanding what its doing, but like the convenience for @vocab provided for those that wanted the feature. Is there a middle ground here?
15:37:34 <bigbluehat> present+
15:37:34 <manu> q+
15:37:35 <brent> q to ask a dumb question
15:37:38 <ivan> present+ dmitriz
15:37:43 <manu> q+ brent
15:37:47 <brent> ack selfissued
15:37:49 <aniltj> aniltj has joined #vcwg
15:38:39 <aniltj> aniltj has joined #vcwg
15:38:40 <decentralgabe> selfissued: I understand what Orie is saying -- we get a mapping for all terms that do not appear in context entries. This is why we added it. As an engineering mechanism I still think it's valuable. I am prone to leaving it alone.
15:38:47 <brent> brent has joined #vcwg
15:38:58 <brent> ack manu
15:38:58 <aniltj> +q
15:39:07 <ivan> +1 to selfissued, I understand now what Orie meant. Thx
15:39:35 <JoeAndrieu5> JoeAndrieu5 has joined #vcwg
15:40:35 <decentralgabe> manu: We cannot leave it alone anymore - there is no support from the WG. We can figure out what to do about it. Gabe you asked - is there middle ground here? Yes - I think that's what's being proposed. The section we had said 'don't worry, just use the base context' - that section can be updated to say - use these two contexts: the base and examples context since it has @vocab. Can work until they're ready for 'production'.
15:40:35 <decentralgabe> IF they really want to use @vocab we can provide a template with an @vocab file..that is not a big ask.
15:40:38 <decentralgabe> q+
15:40:52 <ivan> s/IF/... IF/
15:41:13 <dlongley> +1 to that plan, but none of that changes the fact that everyone must check the `@context` field, you can't ignore it (and the spec already says this).
15:41:51 <decentralgabe> ... LD-averse people can continue to use the mechanism, we can continue to strongly recommend they don't do that. one of the negotiations around vocab ... we were concerned that people that were LD-averse would split the group and start competitive work at IETF and negatively impact both communities...that happened. So, that weakens the argument to have @vocab at all
15:41:53 <decentralgabe> q-
15:42:57 <decentralgabe> ... we have said you do not need to use an LD processor, use a simplified set of rules, said just check the context array and make sure you're OK with the contents, ... but there's only so much we can do. if developers are not going to use the spec since publishing a single context with an @vocab definition is too difficult, then I don't know we need to cater to those developers anymore.
15:43:03 <brent> ack brent
15:43:45 <selfissued> q+
15:43:57 <decentralgabe> brent: it sounds like we have a proposed path forward. remove @vocab from the core context. create an example/experimental context with @vocab for test purposes. did not hear anyone say no. a possible 3rd step - if you want to keep using undefined terms, then you can publish your own @vocab context
15:44:16 <decentralgabe> ... let's spend one more minute and then move on to controller document
15:44:19 <brent> q+ dmitriz
15:44:26 <brent> ack aniltj
15:45:53 <decentralgabe> aniltj: as someone implementing using DI and JOSE, using LD v2 using compact form is a credential for us. there will be no undefined terms in how we are creating credentials. all credentials we create will have clearly defined terms in the context..and can verify that the terms are coming from us.
15:46:57 <decentralgabe> ... I am sympathetic that @vocab provides value. I disagree with having it in the base context. Developers become blind to it. The position that splits the difference (@vocab is bad vs @vocab adds value), we can add a secondary context that developers can add to note there are undefined terms.
15:47:04 <dlongley> +1 to Anil, `@vocab` is useful in a closed setting like development, but it creates conflicts and problems in the general ecosystem.
15:47:15 <decentralgabe> q+
15:47:36 <brent> zakim, close the queue
15:47:36 <Zakim> ok, brent, the speaker queue is closed
15:47:44 <decentralgabe> ... we support removing @vocab from the base context. support in a 2nd context for development purposes...so developers have to be aware of it...that's fine.
15:47:50 <brent> ack selfissued
15:48:15 <decentralgabe> selfissued: is it the case now that conforming JSON-LD implementations will throw an error if there are undefined terms?
15:48:25 <decentralgabe> manu: yes...not all of them but we can force them to
15:48:37 <dlongley> *conforming* implementations will throw an error, yes
15:49:06 <decentralgabe> selfissued: thanks that is good data. responding to Brent's summary that no one has spoken against removal. I have spoken against removal. I would like to have this go out to some people - like Tobias - who are in different time zones, before making a decision.
15:49:07 <decentralgabe> q-
15:49:23 <decentralgabe> ... I would like more discussion before deciding on this call.
15:49:39 <brent> ack dmitriz
15:50:36 <decentralgabe> dmitriz: Responding to Manu's point about not worrying about LD-averse implementers. Not quite the case...I know of multiple implementers that are new to LD. any removal of friction, such as including an @vocab (though I understand the concern) -- let's not discount that audience
15:50:48 <manu> Agree that we want to remove as much friction as possible for people that are new to LD (and even people that regularly use LD)
15:50:52 <dlongley> +1 to not discount, but to move `@vocab` to examples and new developer space
15:51:01 <dlongley> +1 to Manu
15:51:16 <decentralgabe> ... we want to remove friction. we could recommend an inline @vocab, which is an option
15:51:24 <ivan> +1 to fall back on inline @vocab
15:51:39 <decentralgabe> +1 if we can inline @vocab I'm less opposed..
15:51:55 <brent> zakim, open the queue
15:51:55 <Zakim> ok, brent, the speaker queue is open
15:52:03 <decentralgabe> brent: I open to reaching out to MATTR and others. Not sure how much they should dictate group direction. Let's talk about controller document
15:52:03 <brent> Topic: Controller Document
15:52:15 <dlongley> yeah, i don't see why we can't inline it -- verifiers in production would reject it if they haven't allowlisted it.
15:52:22 <manu> q+
15:52:27 <PL-T3> +1 to in-line @vocab - which sounds like a good compromise.
15:52:59 <decentralgabe> ... we have 1 open pull request. we have 16 open issues.
15:53:00 <brent> ack manu
15:53:48 <ivan> q+
15:53:48 <decentralgabe> manu: I was able to open a PR on the Data Integrity spec. Removed every duplicated section, pointed to the Controller Document. Fairly minor surgery!
15:54:12 <selfissued> q+
15:54:30 <decentralgabe> ... some issues we need to address, but going well, we are on a good trajectory to go to CR
15:54:36 <brent> ack ivan
15:55:04 <decentralgabe> ivan: can I update the security vocabulary? all terms need to point to the controller document.
15:55:14 <decentralgabe> manu: in theory...yes...there may be some that fail and we can fix them
15:55:19 <decentralgabe> ivan: I will start the practical part
15:55:20 <brent> ack selfissued
15:56:03 <decentralgabe> selfissued: I will say, as an editor, I did page in all the issues a day or two ago. I agree it's in decent shape. As a VC JOSE COSE editor, I believe I should do the exercise Manu did with DI and see what it's like to remove the Controller Document stuff from VC JOSE COSE.
15:56:36 <decentralgabe> ... one thing in the VC JOSE COSE profile is restrictions on syntaxes to be used. That work is on me (and then Gabe and the WG to validate)
15:56:43 <manu> decentralgabe: I agree
15:57:15 <decentralgabe> brent: only a couple of those bigg(er) issues we're trying to work through. shaping up to be in a good place. looking forward to seeing those changes and reviewing them.
15:57:20 <decentralgabe> ... fantastic working with you all!
15:57:34 <ivan> rrsagent, draft minutes
15:57:35 <RRSAgent> I have made the request to generate https://www.w3.org/2024/07/03-vcwg-minutes.html ivan
15:58:43 <ivan> rrsagent, bye
15:58:43 <RRSAgent> I see no action items